ТЗ на дизайн: как составить + шаблон для фрилансера | Докси

Маша — дизайнер из Казани. Взяла заказ на лендинг за 60 000 рублей. Созвонились с клиентом, обсудили «в общих чертах», договорились на «современный, стильный дизайн». Маша нарисовала три варианта главного экрана. Клиент сказал: «Нет, это вообще не то, я имел в виду другое». Маша переделала. «Нет, тоже не то. Давайте попробуем ещё раз». После пятой итерации Маша поняла: они с клиентом говорят на разных языках и представляют разный результат.

Если бы Маша потратила час на составление технического задания — она бы сэкономила три недели нервов и сохранила бы маржу проекта.

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

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

Зачем дизайнеру техническое задание

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

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

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

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

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

Чем ТЗ отличается от брифа

Новички часто путают бриф и техническое задание. Это разные документы с разными целями.

Бриф — это анкета для заказчика. Вы отправляете список вопросов, он отвечает. Бриф помогает собрать исходную информацию: чем занимается компания, кто целевая аудитория, какие есть предпочтения по стилю. Бриф заполняет заказчик.

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

Идеальный процесс выглядит так: заказчик заполняет бриф → дизайнер на основе брифа составляет ТЗ → обе стороны согласовывают ТЗ → ТЗ становится приложением к договору → работа начинается.

Что должно быть в техническом задании на дизайн

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

1. Описание проекта и цели

Начните с контекста: что за компания, чем занимается, кто клиенты. Затем — конкретная цель проекта.

❌ Плохо: «Нужен дизайн сайта».

✅ Хорошо: «Дизайн лендинга для онлайн-школы английского языка. Цель — конвертировать посетителей в заявки на бесплатный пробный урок. Целевая аудитория — взрослые 25–40 лет, которые хотят подтянуть разговорный английский для работы».

2. Состав работ (что именно делаем)

Перечислите всё, что входит в проект. Максимально конкретно.

Для дизайна сайта:

• Главная страница (десктоп + мобильная адаптация)

• Страница «О компании» (десктоп + мобильная адаптация)

• Страница каталога (десктоп + мобильная адаптация)

• UI-кит: кнопки, формы, типографика

Для логотипа:

• 3 концепции логотипа

• Доработка выбранной концепции (до 2 итераций)

• Финальные файлы: AI, SVG, PNG (на белом и тёмном фоне)

Всё, что не указано в этом списке, — не входит в проект. Это ваша защита от «а иконки? а фавикон? а баннер для соцсетей?».

3. Требования к дизайну

Это самая важная часть. Здесь вы убираете субъективность и заменяете её конкретикой.

Цветовая палитра. Укажите конкретные цвета в HEX или сошлитесь на брендбук. Если брендбука нет — согласуйте палитру до начала работы.

Шрифты. Какие шрифты использовать (или какие нельзя). Если заказчику всё равно — напишите «на усмотрение дизайнера, согласование до начала отрисовки макетов».

Стиль и настроение. Вместо «красиво» и «стильно» — конкретные характеристики: минималистичный, с акцентными иллюстрациями, в стиле flat design. Приложите 3–5 референсов с пояснениями, что именно в них нравится.

Технические параметры. Разрешение, формат файлов, сетка (12-колоночная, 8px grid), размеры экранов для адаптивного дизайна (1440px, 768px, 375px).

4. Референсы

Референсы — обязательная часть ТЗ. Но важно правильно с ними работать.

Не просто «вот сайт, сделайте похоже». А: «Нравится структура главного экрана на сайте X, типографика на сайте Y, цветовые решения на сайте Z». Разбейте референсы по аспектам — так дизайнер поймёт, что именно вы хотите взять из каждого примера.

Полезно добавить и антиреференсы — примеры того, как делать не надо. «Не хотим перегруженный дизайн как на сайте W, не хотим кислотные цвета».

5. Порядок сдачи и правки

Пропишите, как происходит приёмка работы и сколько итераций правок включено.

Пример формулировки: «В стоимость входит до 2 (двух) раундов правок на каждом этапе. Правки сверх указанного количества оплачиваются дополнительно по ставке 2 000 рублей/час. Правкой считается изменение, не противоречащее утверждённому ТЗ».

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

6. Сроки

Укажите сроки по этапам, а не только финальный дедлайн.

Пример:

• Концепция: 5 рабочих дней с момента получения предоплаты

• Правки по концепции: 3 рабочих дня после получения обратной связи

• Внутренние страницы: 7 рабочих дней

• Финальные файлы: 2 рабочих дня после утверждения

Отдельно пропишите: «Сроки приостанавливаются на период ожидания обратной связи от Заказчика». Иначе вы будете виноваты в срыве дедлайна, пока заказчик две недели «думает».

7. Передача прав и файлов

Какие файлы получает заказчик? В каких форматах? Передаются ли исходники? Передаются ли права на использование?

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

Шаблон ТЗ на дизайн (для копипаста)

Вот структура, которую вы можете скопировать и адаптировать под свой проект.

ТЗ для разных типов дизайн-проектов

Базовая структура одинаковая, но акценты меняются в зависимости от типа задачи.

ТЗ на логотип

Главное — зафиксировать количество концепций, количество правок и форматы финальных файлов. Обязательно пропишите, что делаем с концепциями, которые не были выбраны (они остаются у дизайнера, если в договоре не указано иное).

Добавьте: где будет использоваться логотип (веб, печать, сувенирка) — это влияет на форматы и цветовые модели (RGB/CMYK/Pantone).

ТЗ на дизайн сайта

Акцент на постраничном списке экранов и адаптивных брейкпоинтах. Укажите, какие состояния нужно отрисовать: hover-эффекты, состояния форм (пустое, заполненное, ошибка), модальные окна, пустые состояния.

Если будет передача в разработку — пропишите формат передачи (Figma с auto layout, отдельные спецификации, готовый UI-кит).

ТЗ на фирменный стиль

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

Типичные ошибки в техническом задании

«Сделать красиво». Красиво — это не критерий. Для кого-то красиво — это минимализм Apple, для кого-то — сайт с блёстками и анимированными гифками. Замените на конкретные характеристики и референсы.

Нет лимита правок. Если не прописать количество итераций, вы попадёте в бесконечный цикл «а давайте ещё попробуем». Всегда фиксируйте: 2 раунда правок включены, дальше — за дополнительную оплату.

ТЗ без привязки к договору. Само по себе ТЗ — не юридический документ. Оно работает, только если является приложением к договору ГПХ. Без договора заказчик может сказать «ну это мы так, для себя писали, это не обязательство».

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

Референсы без пояснений. «Сделайте как вот этот сайт» — не работает. Что именно нравится? Типографика? Сетка? Цвета? Анимация? Без пояснений дизайнер возьмёт не тот аспект.

Как привязать ТЗ к договору

Техническое задание становится юридически значимым, когда оно оформлено как приложение к договору. В договоре прописывается: «Требования к Работам определены в Приложении №1 к настоящему Договору (Техническое задание)». ТЗ подписывается обеими сторонами как приложение.

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

В Докси при создании договора на дизайн техническое задание автоматически формируется как приложение — с правильными ссылками и юридическими формулировками. Вам остаётся только заполнить содержание.

Чек-лист: всё ли есть в вашем ТЗ

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

• Описание компании и целевой аудитории

• Конкретная цель проекта (не «сделать дизайн», а зачем)

• Полный список deliverables (что именно делаем)

• Что НЕ входит в проект (явные исключения)

• Требования к цветам, шрифтам, стилю

• Референсы с пояснениями + антиреференсы

• Технические параметры (размеры, форматы, сетка)

• Количество правок и стоимость дополнительных

• Сроки по этапам + приостановка при ожидании ОС

• Список финальных файлов и форматов

• Условия передачи прав

• Привязка к договору (ТЗ = приложение)

Если все пункты на месте — ваш проект защищён от 90% типичных конфликтов.

Часто задаваемые вопросы

Создайте договор с ТЗ в Докси

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