Техническое задание на дизайн сайта: структура, пример и чек-лист

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

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

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

Что такое ТЗ на дизайн и чем оно отличается от брифа

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

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

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

Кто составляет ТЗ на дизайн

Идеальный автор — не одиночка, а пара: заказчик и исполнитель. У каждого своя зона.

• Заказчик знает бизнес: цели, аудиторию, продукт, конкурентов, ограничения по срокам и бюджету, юридические требования, фирменный стиль.
• Дизайнер или UX-специалист знает, какие требования нужны, чтобы макет был полным: состояния, адаптив, доступность, сетка, формат сдачи.
• Разработчик подключается, когда речь о технических рамках: какая CMS, есть ли готовая дизайн-система или UI-библиотека, какие компоненты уже существуют.

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

Если команда уже работает по дизайн-системе, часть требований можно не описывать, а сослаться на неё: «кнопки, поля и карточки — из библиотеки компонентов версии 3.2». Это сокращает ТЗ вдвое и снимает споры о мелочах.

Как составить ТЗ на дизайн: порядок работы

Документ удобнее всего собирать в семь шагов. На небольшом сайте они укладываются в два–три рабочих дня, на сервисе с личным кабинетом — в одну–две недели.

1. Соберите бриф. Цели, аудитория, продукт, конкуренты, сроки, бюджет, фирменные материалы. Это вход для всего остального.
2. Изучите текущий сайт и данные. Аналитика покажет устройства, популярные страницы и места, где люди уходят. Записи сессий и обращения в поддержку подскажут, что непонятно в интерфейсе сейчас.
3. Посмотрите конкурентов. Не ради копирования, а чтобы понять ожидания аудитории: какие блоки на страницах услуг стали стандартом, как устроены формы, что показывают на первом экране.
4. Опишите сценарии. Три–пять задач, ради которых приходят пользователи. Каждый сценарий — цепочка экранов, которые нужно нарисовать.
5. Составьте список шаблонов. Из сценариев и структуры выведите уникальные шаблоны и служебные страницы.
6. Пропишите требования. Блоки и контент для каждого шаблона, требования к интерфейсу, стиль, формат сдачи, приёмку.
7. Вычитайте документ втроём. Заказчик проверяет, что учтены цели бизнеса, дизайнер — что требований хватает для полного макета, разработчик — что макеты лягут на выбранную платформу.

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

Из каких разделов состоит ТЗ

Набор разделов почти не зависит от типа сайта, меняется только глубина. Ниже — базовая структура.

1. Общие сведения. Название проекта, ссылки на текущий сайт, контакты ответственных с обеих сторон, сроки этапов, кто принимает работу.
2. Цели и метрики. Чего сайт должен добиться: заявки, продажи, регистрации, снижение нагрузки на поддержку. Как будем измерять.
3. Аудитория и сценарии. Кто приходит на сайт, с какой задачей, с каких устройств. Три–пять ключевых сценариев: «найти услугу и оставить заявку», «сравнить тарифы», «найти контакты».
4. Структура сайта. Карта разделов и список уникальных шаблонов, которые нужно нарисовать.
5. Описание шаблонов. Для каждого шаблона — назначение, блоки, контент, обязательные элементы.
6. Требования к интерфейсу. Состояния компонентов, формы, адаптив, доступность, микроанимация.
7. Визуальный стиль. Фирменные материалы, референсы с пояснением, ограничения.
8. Контент. Кто и когда готовит тексты и изображения, на каком контенте рисуются макеты.
9. Формат сдачи. Инструмент, организация файла, компоненты и токены, что передаётся разработке.
10. Приёмка. Критерии, порядок согласования, число итераций правок.

Для лендинга разделы 4 и 5 сливаются в один, для интернет-магазина или сервиса с личным кабинетом раздел 5 становится самым объёмным. Пустых разделов быть не должно: если что-то не нужно, напишите это явно — «анимация не требуется», «тёмная тема не входит в объём».

Как описать страницы и блоки

Главная ошибка — перечислить страницы сайта вместо шаблонов. На сайте может быть 200 страниц услуг, но шаблон у них один. Дизайнеру нужен список уникальных шаблонов, а не карта всех URL.

Для каждого шаблона опишите четыре вещи:

• назначение — какую задачу пользователя решает страница и какое целевое действие на ней главное;
• блоки по порядку — от первого экрана до подвала, с пометкой, какие обязательны, а какие опциональны;
• контент — реальные тексты или хотя бы их объём: «заголовок до 60 символов, описание 2–3 предложения»;
• особые элементы — калькулятор, фильтр, карта, видео, форма с загрузкой файла.

Отдельно отметьте служебные страницы. Их почти всегда забывают, а потом верстальщик сам придумывает страницу 404 и письмо подтверждения. Если дизайнер о них знает с первого дня, они будут в одном стиле с остальным сайтом.

Какие требования к интерфейсу нельзя забыть

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

Состояния компонентов

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

Формы

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

Адаптив

Задайте ширины, на которых нужны макеты, и минимальную поддерживаемую ширину. Типичный набор — 360, 768, 1280 и 1440 пикселей, но точные значения лучше взять из аналитики текущего сайта. Укажите, нужны ли полноценные макеты для каждой ширины или достаточно мобильной и десктопной версии с правилами промежуточных состояний.

Доступность

Зафиксируйте уровень соответствия, например WCAG 2.2 уровня AA, и перечислите, что это значит для макетов: контраст текста не ниже 4,5:1, у крупного текста и элементов интерфейса — не ниже 3:1, видимый фокус, цель нажатия не меньше 24 на 24 пикселя, информация не передаётся только цветом. Формулировки критериев есть в официальном тексте WCAG 2.2 на сайте W3C, а практический разбор — в нашей статье о контрасте, фокусе и размере целей. Для государственных и социальных сайтов в России дополнительно стоит сверяться с ГОСТ Р 52872.

Анимация и тёмная тема

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

Как задать визуальный стиль без «сделайте красиво»

Пожелания к стилю — самая субъективная часть ТЗ. Её не получится сделать полностью проверяемой, но можно сильно сузить поле для разночтений.

1. Перечислите фирменные материалы. Логотип, брендбук, цвета, шрифты с лицензиями. Если чего-то нет, так и напишите — это значит, что элементы фирменного стиля придётся создавать.
2. Дайте референсы с пояснением. Ссылка без комментария бесполезна: дизайнер не знает, что вам понравилось — цвет, типографика или подача фотографий. Формат: «сайт X — нравится крупная типографика и много воздуха, не нравится тёмный фон».
3. Добавьте антиреференсы. Что точно не подходит: «не хотим стоковые фото с рукопожатиями», «не хотим неоновые градиенты». Это экономит итерацию.
4. Опишите характер через пары прилагательных. «Строгий, но не холодный», «дружелюбный, но не детский». Пары работают лучше одиночных слов, потому что задают границы.
5. Укажите технические рамки. Если сайт собирается на готовой UI-библиотеке или существующей дизайн-системе, стиль должен в неё укладываться. Цвета и отступы стоит сразу оформить токенами — подробнее в статье о дизайн-токенах от палитры до продакшена.

Хорошая практика — просить на первом этапе два–три стилевых направления на одном ключевом экране, а не сразу весь сайт. Согласовать стиль на одной странице проще и дешевле, чем переделывать двадцать.

Как принимать макеты

Раздел приёмки защищает обе стороны. Заказчик понимает, за что платит, дизайнер — когда работа закончена.

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

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

Пример ТЗ на дизайн страницы

Ниже — сокращённый пример описания одного шаблона для корпоративного сайта. Так стоит описывать каждый шаблон из списка.

• Шаблон: страница услуги.
• Назначение: объяснить, что входит в услугу, снять основные возражения и получить заявку. Главное действие — отправка формы.
• Аудитория: руководители отделов в компаниях среднего размера, около 60 % заходов с мобильных.
• Блоки: первый экран с заголовком, подзаголовком и кнопкой заявки; что входит в услугу (4–6 пунктов); этапы работ; кейсы (2–3 карточки); стоимость или факторы цены; вопросы и ответы; форма заявки; подвал.
• Контент: заголовок до 60 символов, тексты блоков предоставляет заказчик до начала работ, фото — из фотосессии команды.
• Форма: имя, телефон, комментарий (необязательный), согласие на обработку данных; показать ошибки, отправку и экран успеха.
• Адаптив: 360 и 1440 пикселей, правила для промежуточных ширин — комментариями в файле.
• Доступность: WCAG 2.2 AA, видимый фокус у всех интерактивных элементов.
• Приёмка: все блоки нарисованы на реальном тексте, форма показана во всех состояниях, две итерации правок.

Обратите внимание: в примере нет слов «красиво», «современно», «стильно». Каждый пункт можно проверить при приёмке.

Как учитывать ИИ-инструменты в ТЗ

В 2026 году многие команды генерируют первые варианты экранов, иконки и иллюстрации с помощью нейросетей и агентов внутри редакторов макетов. Это ускоряет работу, но добавляет в ТЗ несколько пунктов, о которых раньше не думали.

• Где ИИ допустим. Например, для поиска стилевых направлений и черновых вариантов — да, для финальных иллюстраций и фото людей — только с согласования заказчика.
• Права на материалы. Кто отвечает за то, что сгенерированные изображения можно использовать в коммерческом проекте, и в каком виде передаются исходные запросы.
• Соответствие дизайн-системе. Сгенерированные экраны часто выглядят убедительно, но используют случайные цвета и отступы. В приёмку стоит добавить требование: финальные макеты собраны из компонентов и токенов, а не из картинок.
• Проверка доступности. ИИ-варианты не гарантируют контраст и видимый фокус — эти критерии проверяются так же, как у ручных макетов.

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

Частые ошибки

• Список желаний вместо требований. «Хочется, чтобы сайт вызывал доверие» — это цель, её нужно разложить на конкретные элементы: отзывы, кейсы, реквизиты, сертификаты.
• Перечень всех URL вместо шаблонов. Документ раздувается, а дизайнер всё равно рисует шаблоны.
• Нет служебных страниц и состояний. Ошибки, пустые списки и 404 потом придумывает разработчик.
• Макеты на «рыбе». Реальные тексты длиннее или короче, и сетка разваливается после наполнения.
• Референсы без пояснений. Дизайнер угадывает, что именно понравилось.
• Нет критериев приёмки и лимита правок. Проект превращается в бесконечную доработку.
• ТЗ на дизайн написано отдельно от разработки. Макеты не укладываются в выбранную платформу или библиотеку компонентов, и их приходится перерисовывать.

Многие из этих проблем ловятся быстрым UX-аудитом текущего сайта ещё до написания ТЗ — схема описана в статье об UX-аудите за 30 минут. А Nielsen Norman Group в материале о методах UX-исследований на разных этапах проекта показывает, какие данные стоит собрать до старта дизайна.

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

Пройдитесь по списку перед отправкой документа дизайнеру. Если хотя бы на один пункт ответ «нет», ТЗ стоит доработать.

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

Редакция Флагштока

Пишем об UX/UI-дизайне: исследования, интерфейсы, дизайн-системы и доступность.