ТЗ для макета: как описать структуру, слои и экспорт, чтобы файл приняли с первого раза

Дизайнер сдал макет: визуально всё красиво, цвета на месте, композиция собрана. Но при передаче в производство начинается хаос: текст «залип» в картинке, слои не названы, шрифты не приложены, поля не соблюдены, версия для печати отличается от веб-варианта, а правка одного элемента ломает всю сетку. Знакомо? В большинстве случаев проблема не в дизайнере, а в том, что ТЗ описывало «как должно выглядеть», но не описывало «как должен быть устроен файл».

Макет — это не просто красивая страница. Это производственный документ, из которого делают печать, сайт, презентацию, упаковку, карточку товара или полиграфический тираж. Разбираем, как составить ТЗ для макета так, чтобы файл можно было открыть, отредактировать, экспортировать и принять без бесконечных «а давайте переделаем».

Что такое ТЗ для макета и когда оно спасает

ТЗ для макета — это документ, который описывает не только визуальный результат, но и техническую структуру файла: сетку, отступы, слои, стили текста, компоненты, форматы экспорта, цветовые профили, размеры, безопасные зоны и правила передачи правок. Это мост между дизайном и производством.

Такое ТЗ спасает в четырёх ситуациях:

• Когда макет уходит в печать. Типографии важны не «красивые поля», а вылеты, формат PDF, цветовая модель CMYK, разрешение изображений, отсутствие шрифтов в кривых или их корректная встройка, размер листа и порядок полос.
• Когда макет передаётся разработчику или верстальщику. Ему нужны не только PNG-превью, а сетка, отступы, состояния кнопок, типографическая шкала, адаптивные брейкпоинты, компоненты и экспорт ассетов.
• Когда макет многостраничный или вариативный. Буклет, каталог, презентация, упаковка, карточки товаров — всё это системы, где одна правка должна распространяться на десятки элементов. Без ТЗ каждая страница будет собрана «по-своему».
• Когда нужно сохранить редактируемость. Если через полгода заказчик захочет поменять телефон, цену или логотип, файл должен быть устроен так, чтобы это можно было сделать без пересборки макета с нуля.

Хорошее ТЗ отвечает на вопрос: кто будет использовать макет после сдачи и какие действия с ним должен выполнять? Если ответ — «печатать», «верстать», «показывать на конференции», «тиражировать в разных форматах», — значит, ТЗ должно описывать не только внешний вид, но и инженерную часть файла.

Макет принимают не глазами, а производством: типография, браузер, проектор, станок или CMS. Если файл не проходит проверку на этих этапах, визуальная красота не спасает.

Специфика ниши макета: 5 особенностей, которые влияют на ТЗ

Макет отличается от логотипа, иллюстрации, сайта или презентации. Он находится на стыке дизайна и технической подготовки. Эти особенности нужно закладывать в ТЗ заранее.

1. Макет — это система, а не одна страница

Даже одностраничный макет содержит систему: сетку, стили заголовков, отступы, иерархию, кнопки, поля форм, подвалы, водяные знаки, колонтитулы. Если в ТЗ описать только «сделайте красиво», исполнитель выберет свою логику, и при правках начнётся разрушение структуры.

В ТЗ нужно указать, какие элементы являются базовыми: модульная сетка, типографическая шкала, отступы кратные 4/8 px, компоненты кнопок, правила выравнивания, максимальная ширина текста. Для многостраничных макетов — мастер-страницы, стили абзацев, нумерация, колонтитулы, порядок полос.

2. Слои и названия важнее, чем кажется

Для дизайнера слой «Rectangle 47» — нормально. Для того, кто будет принимать макет в печать или дорабатывать его через месяц, это катастрофа. ТЗ должно требовать понятной структуры файлов: группы по блокам, названные слои, отдельно фон, текст, изображения, кнопки, служебные элементы.

Хороший принцип: любой новый специалист должен за 5 минут открыть файл и понять, где менять текст, где картинка, где фон, где безопасная зона. Если в ТЗ нет требования к структуре слоёв, исполнитель не обязан угадывать.

3. Формат вывода меняет технические требования

Один и тот же дизайн для экрана и печати — разные макеты. Для веба важны RGB, sRGB, вес файла, адаптивность, состояния hover/focus, экспорт SVG/PNG/WebP. Для печати — CMYK, вылеты, разрешение 300 dpi, профиль типографии, чёрный текст в 100% K, запрет на прозрачности для некоторых процессов.

Если в ТЗ не указано, куда пойдёт макет, исполнитель сделает универсальный вариант, который часто не подходит ни туда, ни туда. Поэтому в задании нужно перечислить все каналы использования: печать, сайт, соцсети, презентация, упаковка, маркетплейс, наружная реклама.

4. Правки в макете дороже, чем правки в идее

Пока это концепт, поменять композицию легко. Когда макет собран в производство, каждая правка тянет за собой пересборку сетки, обновление стилей, экспорт новых файлов, проверку полей и согласование. ТЗ должно разграничивать: что считается правкой, а что — новой задачей.

Например: замена текста в существующих стилях — правка. Добавление новой страницы, смена формата, перенос в другой размер, изменение сетки, новая фотосъёмка — новая задача. Без такого разделения заказчик будет требовать «быстро поправить», а исполнитель будет чувствовать, что работает бесплатно.

5. AI ускоряет сборку, но не заменяет preflight

В 2026 году нейросети и AI-инструменты помогают быстро собрать варианты макетов, очистить фон, предложить сетку, сгенерировать тексты-заглушки, адаптировать размер. Но AI не отвечает за производственную корректность: он может оставить шрифты без лицензий, нарушить contrast, собрать слои в кашу, экспортировать в неправильный профиль или обрезать важные элементы.

Если в работе используются AI-инструменты, в ТЗ нужно прописать: на каком этапе они допустимы, кто проверяет финальный файл, какие элементы нельзя генерировать автоматически, нужны ли исходники и как передаются права на сгенерированные изображения. Финальный макет всё равно должен проходить ручную проверку по чек-листу.

Структура ТЗ для макета

1. Цель и назначение макета

Начните с бизнес-задачи. Макет нужен, чтобы напечатать тираж, запустить лендинг, собрать презентацию для инвесторов, оформить карточку товара, сделать упаковку или подготовить серию постов. Цель определяет технические требования.

Плохая формулировка: «Нужен макет буклета». Хорошая: «Макет буклета А5, 8 полос, для печати на мелованной бумаге 150 г/м², с последующей передачей в типографию и адаптацией под PDF для сайта».

Укажите, кто конечный пользователь файла: типография, разработчик, маркетолог, дизайнер, менеджер, спикер. Для каждого своя приёмка. Типография проверит вылеты, разработчик — сетку и состояния, спикер — читаемость слайдов с проектора.

2. Требования к структуре и сетке

Это основа производственного макета. В ТЗ нужно зафиксировать:

• формат страницы или экрана: А4, А5, 1080×1920, 1920×1080, 3000×3000, mobile-first;
• поля, margins, колоночную сетку, gutter;
• базовую единицу отступов, например 4 px, 8 px или 5 мм;
• правила выравнивания по сетке;
• безопасные зоны для текста и важных элементов;
• для печати — вылеты, формат блока, порядок полос;
• для веба — брейкпоинты, максимальная ширина контента, адаптивные состояния.

Если макет многостраничный, отдельно укажите мастер-страницы, стили заголовков, подписей, сносок, колонтитулов, нумерации. Для презентаций — правила для титульного, содержательного, секционного и финального слайдов.

3. Требования к слоям, стилям и редактируемости

Макет должен быть не только красивым, но и живым. В ТЗ пропишите, как организовывать файл:

• слои и группы названы по смыслу: «фон», «заголовок», «фото», «CTA», «служебное»;
• текстовые блоки не растрированы, если требуется редактирование;
• используются абзацные и символьные стили, а не ручное форматирование;
• повторяющиеся элементы вынесены в компоненты/символы/мастер-объекты;
• изображения связаны или встроены в зависимости от формата передачи;
• служебные линии, сетки и заметки вынесены в отдельный слой и не попадают в экспорт;
• файл структурирован так, чтобы правка текста не ломала вёрстку.

Если исполнитель работает в Figma, Sketch, Photoshop, Illustrator, InDesign, PowerPoint или Canva, укажите желаемый инструмент или хотя бы требуемый формат исходников. Разные программы по-разному передают слои, стили и шрифты.

4. Объём работ: страницы, экраны, состояния, форматы

Чётко зафиксируйте, что входит в задачу. Иначе «сделать макет» может означать одну страницу, а заказчик будет ждать десять форматов и три версии.

В объём обычно включают:

• количество полос, страниц, слайдов, экранов;
• количество вариантов: мобильный, десктопный, печатный, для соцсетей;
• состояния элементов: обычное, hover, active, disabled, error;
• шаблоны: титульный, контентный, секционный, финальный;
• экспортные форматы: PDF, PNG, JPG, SVG, WebP, PPTX, INDD, AI, PSD, FIG;
• дополнительно: мокапы, превью, спецификация для разработчика, чек-лист preflight.

Для карточек маркетплейсов отдельно укажите количество слайдов, требования площадки, формат изображений, наличие инфографики, запрет на определённые элементы. Для упаковки — развёртка, клапаны, биговка, перфорация, зона склейки.

5. Технические требования: файлы, профили, разрешение, шрифты

Это раздел, который чаще всего забывают, но именно он определяет, примут макет или вернут.

Для печати укажите:

• цветовую модель CMYK и профиль, например ISO Coated v2 300% или профиль типографии;
• вылеты 2–5 мм с каждой стороны;
• разрешение растровых изображений не ниже 300 dpi в масштабе 1:1;
• минимальную толщину линий и размер шрифта;
• требования к чёрному: текст — 100% K, насыщенный фон — rich black по согласованию;
• формат PDF/X или PDF Print с сохранением меток реза;
• шрифты в кривых или с приложением лицензионных файлов;
• запрет на RGB-изображения в финальном печатном файле, если этого требует типография.

Для веба и мобильных интерфейсов укажите:

• цветовую модель sRGB;
• разрешение и плотность пикселей: 1x, 2x, 3x;
• форматы экспорта: SVG для иконок, PNG/WebP для изображений;
• максимальный вес файлов, если это важно;
• именование ассетов по системе;
• доступ к прототипу или спекам для разработчика;
• требования к контрастности и доступности, например WCAG AA для текста.

Для презентаций и экранов укажите разрешение 16:9 или 16:10, безопасные поля, минимальный размер шрифта, проверку читаемости с проектора, экспорт в PPTX и PDF, наличие заметок спикера.

6. Контент, тексты и плейсхолдеры

Макет нельзя собирать на «Lorem ipsum», если финальный текст изменит вёрстку. В ТЗ нужно указать, кто предоставляет контент и в каком виде.

Варианты:

• заказчик даёт финальные тексты до старта;
• исполнитель использует согласованные плейсхолдеры с реальной длиной;
• тексты будут заменены после сдачи, но макет должен выдерживать диапазон длины;
• нужна адаптация под разные языки, если текст может вырасти на 20–40%.

Отдельно пропишите правила для цифр, дат, названий, контактов, юридических сносок. Для карточек товара — максимальная длина заголовка, количество характеристик, объём описания. Для презентаций — лимит слов на слайде, формат списков, правила для цитат и источников.

7. Сроки и этапы

Макет редко делается за один шаг. Разбейте работу на этапы, чтобы контролировать процесс и не получить финальный файл, который нельзя принять.

Типовые этапы:

• подготовка ТЗ, референсов, контента;
• черновая структура или вайрфрейм;
• дизайн-концепт первой страницы/слайда/экрана;
• масштабирование системы на остальные полосы или экраны;
• техническая доводка и preflight;
• экспорт и передача файлов;
• согласование и правки.

Укажите дедлайны для каждого этапа. Если макет нужен к выставке, печати тиража или релизу сайта, пропишите резервное время на типографскую проверку, вёрстку, загрузку в CMS или модерацию площадки.

8. Критерии приёмки

Критерии приёмки макета должны быть проверяемыми. Не «понравилось», а «соответствует ТЗ и техническим требованиям».

Примеры критериев:

• файл открывается в согласованной программе или формате;
• все слои и группы названы;
• текст не растрирован там, где требуется редактирование;
• вылеты, поля и безопасные зоны соблюдены;
• цвета соответствуют согласованной модели и профилю;
• изображения имеют нужное разрешение;
• шрифты лицензионны или переведены в кривые;
• экспортные файлы совпадают по содержанию с исходником;
• макет проходит проверку целевым получателем: типографией, разработчиком, площадкой.

Если в ТЗ есть ссылка на ТЗ для типографии, требования печати нужно перенести в критерии приёмки. Если макет идёт в сайт — сверяться со спецификацией для верстки. Если это презентация — проверить читаемость на проекторе и экспорт в PDF.

9. Формат передачи

Опишите, что именно заказчик получает на выходе. Это защищает от ситуации «я думал, что исходники входят».

В формат передачи могут входить:

• исходный файл: Figma, Sketch, Adobe Illustrator, InDesign, Photoshop, PowerPoint, Canva;
• экспорт для печати: PDF/X, PDF Print, TIFF при необходимости;
• экспорт для веба: PNG, JPG, SVG, WebP, HTML-превью;
• архив с ассетами и именованием по системе;
• мини-гайд по слоям, стилям и правилам замены текста;
• доступ к файлу или ссылка на проект с правами на просмотр/редактирование;
• спецификация для разработчика: отступы, размеры, цвета, состояния;
• превью или мокапы для согласования.

Отдельно укажите, передаются ли шрифты, пресеты, стили, библиотеки компонентов. Если исполнитель использует подписные сервисы, нужно прописать, кто оплачивает доступ и как заказчик получит файл после окончания подписки.

10. Правки и версионирование

Макет — объект частых правок. В ТЗ нужно зафиксировать, сколько кругов правок входит, как они подаются и что считается новой задачей.

Хорошая практика:

• правки собираются одним списком, а не по одному сообщению в чате;
• каждая правка привязана к странице, слою или элементу;
• версии文件名 содержат дату и номер: layout_v03_2026-09-25.pdf;
• изменение сетки, формата, количества страниц, добавление новых состояний — новая задача;
• после финальной версии дополнительные правки оцениваются отдельно.

На Workink такие договорённости удобно фиксировать в чате заказа: переписка имеет силу ТЗ, а доработки идут бесплатно до соответствия согласованным требованиям. Это снижает риск спора «мы же не это обсуждали».

Критерии приёмки результата макета

Чтобы принять макет без эмоций и догадок, проверьте его по измеримым пунктам:

• Файл открывается и соответствует согласованному формату. Если в ТЗ указан Figma, InDesign, Illustrator, PDF/X или PPTX, исполнитель передал именно этот формат, а не «почти то же самое».
• Структура слоёв понятна. Группы и слои названы по смыслу, служебные элементы отделены, текст не лежит внутри картинок, если требуется редактирование.
• Сетка и отступы соблюдены. Элементы выровнены по заданной системе, поля одинаковые, безопасные зоны не нарушены, многостраничные макеты совпадают по структуре.
• Технические параметры соответствуют назначению. Для печати: CMYK, вылеты, 300 dpi, профиль, шрифты. Для веба: sRGB, нужные разрешения, экспорт ассетов, состояния. Для презентации: читаемый шрифт, экспорт PDF/PPTX, безопасные поля.
• Шрифты легальны и переносимы. Использованы лицензионные шрифты, открытые лицензии или перевод в кривые. Если шрифты не в кривых, заказчик получил файлы или ссылки на установку.
• Экспортные файлы совпадают с исходником. PDF не отличается от макета по цветам, обрезке и порядку полос; PNG/SVG не имеют лишних фонов; веб-ассеты названы по согласованной схеме.
• Правки не ломают систему. Замена текста, цены, телефона или логотипа не требует пересборки всего макета. Стили и компоненты позволяют обновить элементы централизованно.
• Макет прошёл целевую проверку. Типография подтвердила пригодность к печати, разработчик — возможность вёрстки, площадка — отсутствие нарушений по форматам, спикер — читаемость с экрана.
• Переданы все договорённые материалы. Исходники, экспорты, гайд по слоям, спецификация, доступы, архив — всё в объёме, указанном в ТЗ.
• Версии зафиксированы. Финальный файл имеет понятное имя и дату, предыдущие версии не смешаны с рабочими, в чате или архиве есть след согласования.

Вопросы для уточнения до старта

Эти вопросы лучше задать до того, как дизайнер начнёт собирать файл. Они снимают большинство технических возвратов:

• Где будет использоваться макет: печать, сайт, приложение, презентация, маркетплейс, упаковка, наружная реклама?
• Кто конечный получатель файла: типография, разработчик, CMS, дизайнер, менеджер, спикер?
• Какой формат страницы или экрана: А4, А5, 1080×1920, 1920×1080, mobile, desktop, custom?
• Сколько полос, страниц, слайдов, экранов и состояний нужно сделать?
• Нужны ли адаптации под несколько форматов: печать + веб, desktop + mobile, горизонталь + вертикаль?
• Какие требования к цветовой модели: RGB, CMYK, Pantone, профиль типографии?
• Нужны ли вылеты, метки реза, безопасные зоны, порядок полос, нумерация?
• Какой инструмент и формат исходников ожидаются: Figma, Illustrator, InDesign, Photoshop, PowerPoint, Canva?
• Требуются ли редактируемые тексты, названные слои, компоненты, стили абзацев?
• Кто предоставляет финальные тексты, изображения, логотипы, шрифты и брендбук?
• Есть ли ограничения площадки: размер файла, формат, запрет на определённые элементы, требования модерации?
• Нужны ли исходники, ассеты, спецификация для разработчика, гайд по правкам?
• Сколько кругов правок входит и что считается новой задачей?
• Какие критерии приёмки будут проверять: preflight, открытие в программе, тестовая печать, вёрстка, показ на проекторе?

Чек-лист готовности ТЗ

Прежде чем отправлять задачу исполнителю, проверьте ТЗ по короткому списку:

• Указано назначение макета и каналы использования: печать, веб, презентация, упаковка, соцсети.
• Зафиксирован объём: количество страниц, экранов, состояний, форматов и версий.
• Описаны сетка, поля, безопасные зоны, порядок полос или брейкпоинты.
• Прописаны требования к слоям, стилям, компонентам и редактируемости.
• Указаны технические параметры: цветовая модель, разрешение, профили, форматы экспорта, шрифты.
• Определён источник контента: финальные тексты, плейсхолдеры, изображения, логотипы, брендбук.
• Согласованы сроки, этапы, формат передачи и список файлов на выходе.
• Зафиксированы критерии приёмки, число правок и разграничение правки/новой задачи.

Если хотя бы два пункта пустуют, ТЗ лучше дописать. В макете ошибка в teknisческой части стоит дороже, чем ошибка во вкусе: переделывать нужно не «красивее», а заново собирать файл, экспорт и согласование.

Как заказать подготовку макета на Workink

На Workink задача оформляется в категории «Техническое задание (ТЗ)»: вы описываете цель, объём, технические требования и критерии приёмки, получаете отклики и выбираете исполнителя под конкретный формат файла. Это особенно полезно, когда нужен не просто дизайн, а производственно готовый макет.

Платформа снижает типовые риски работы с макетами:

• Безопасная сделка: деньги находятся в резерве до приёмки работы. Вы платите за файл, который можно использовать, а не за красивую картинку.
• Комиссия 11% за заказ и 0% за вывод: прозрачные условия без дополнительного удержания при выводе средств.
• Доработки бесплатно до соответствия ТЗ: если макет не соответствует согласованным техническим требованиям, исполнитель дорабатывает результат.
• Договорённости в чате имеют силу ТЗ: все обсуждения по слоям, форматам, шрифтам, экспорту, правкам и передаче файлов фиксируются в переписке и защищают обе стороны.

Если вы заказчик, начните с чёткого ТЗ: назначение, объём, сетка, технические параметры, формат передачи и критерии приёмки. Если вы исполнитель, просите эти пункты до старта — они защищают вас от бесконечных «поправьте только тут» и помогают сдать макет с первого-второго круга.

Найти исполнителя Разместить заказ Защита покупателей

Полезные материалы по теме

• ТЗ для логотипа — если в макет входит фирменный знак и нужны векторные версии.
• ТЗ для типографии — если макет готовится под печатный тираж.
• ТЗ для презентации — если макет существует в формате слайдов и выступления.
• ТЗ для дизайнера — базовый бриф для визуальных задач, включая макеты.
• Шаблоны ТЗ — готовые структуры, которые можно адаптировать под подготовку макета.