Требования к UI/UX-дизайну: что включить в ТЗ дизайнеру

Почему ТЗ «на глаз» превращается в бесконечные правки

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

ТЗ решает эту проблему не потому, что в нём больше слов, а потому что оно переводит субъективные ощущения в проверяемые пункты: не «современный дизайн», а «шрифтовая пара из двух гарнитур, без засечек, поддержка кириллицы»; не «удобная форма», а «не больше 4 полей на первом шаге, автозаполнение города по IP». Правки после такого ТЗ тоже становятся конкретными — либо пункт выполнен, либо нет.

Блок 1: карта экранов и состояний

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

• Список страниц — не просто «главная, каталог, карточка товара», а с пометкой, сколько итераций макета предусмотрено на каждую (обычно 1-2 на типовую страницу, 2-3 на ключевую посадочную);
• Состояния интерфейса — пустой каталог (ничего не найдено), форма с ошибкой, состояние загрузки, успешная отправка заявки. Забытое состояние — самая частая причина, почему в проде появляется «дыра» в дизайне, которую верстальщик закрывает системным шрифтом браузера;
• Адаптивные версии — конкретные брейкпоинты: например, 1440 / 768 / 375 px, а не абстрактное «должно быть адаптивно». Без чисел дизайнер и верстальщик почти гарантированно разойдутся в трактовке того, что происходит между десктопом и мобильным.

Блок 2: целевое действие на каждом экране

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

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

Блок 3: референсы — что взять, а чего избегать

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

Хороший референс-блок в ТЗ — это не подборка вдохновляющих картинок, а набор точечных пометок «этот элемент» + «эта причина». Так дизайнер получает не общее направление, а конкретное решение конкретной задачи интерфейса.

Блок 4: технические ограничения и формат сдачи

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

• Инструмент и формат файла — Figma со ссылкой на рабочий файл (не PDF-экспорт), сохранённая сетка 12 колонок, именованные слои и компоненты;
• UI-кит / дизайн-система — если сайт больше 5-7 страниц, отдельная страница с цветами, шрифтами, кнопками в состояниях (обычный, hover, disabled) экономит на вёрстке ощутимо: верстальщик один раз собирает компоненты вместо того, чтобы искать различия между визуально похожими, но разными кнопками на каждой странице;
• Плотность контента — реальные тексты и фото или явно оговорённый рыбный текст (lorem ipsum). Макет под реальный контент и макет «под красивую картинку» — это разные по сложности вёрстки задачи, и заказчик должен понимать, что получит.

Блок 5: критерии приёмки

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

Рабочий вариант: 2-3 раунда правок включены в стоимость, каждый раунд — это список замечаний одним сообщением, а не правки по одному пункту в час. Правки, выходящие за рамки исходного ТЗ (новая страница, смена концепции после утверждённого макета), оплачиваются отдельно. Это не бюрократия ради бюрократии — без такого условия любой проект рискует зависнуть в состоянии «почти готово» на месяцы.

Что можно не включать в ТЗ дизайнеру

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

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

Частые вопросы