Бриф дизайнеру: что дать, чтобы не было 10 кругов правок
В пятницу в 18:40 вы пишете дизайнеру: “Надо чуть освежить страницу”. В понедельник получаете макет. И дальше начинается то, что знакомо всем: “поиграйте со шрифтами”, “сделайте более премиально”, “как-то не цепляет”, “слишком пусто”, “слишком перегружено”. В итоге вы правите не дизайн — вы правите собственные мысли, но уже постфактум и за чужое время.
Хороший бриф нужен не для бюрократии. Он нужен, чтобы дизайнер не угадывал, а решал задачу. Бриф фиксирует три вещи: цель, аудиторию и рамки. Когда они есть, обсуждение становится предметным: не “нравится/не нравится”, а “работает/не работает”.
Бриф дизайнеру ≠ ТЗ на разработку
ТЗ отвечает: как должно работать (сценарии, требования, интеграции, критерии “готово”).
Бриф отвечает: как должно выглядеть и ощущаться, чтобы работало на цель (иерархия, визуальные акценты, стиль, ограничения бренда).
Если смешать документы, получится двойная боль: дизайнер тонет в технических деталях, разработчик — в референсах “как у Apple”.
Что дизайнеру нужно почти всегда (8 пунктов)
- Что делаем: страница / экран / блок / набор компонентов.
- Цель: что пользователь должен сделать или понять.
- Аудитория и сценарий: кто эти люди, с какого устройства, в каком контексте приходят.
- Контент и структура: что на экране обязательно, что вторично.
- Референсы “нравится” и “не нравится” (обязательно оба типа).
- Ограничения: бренд, платформа, сроки, запреты (“без редизайна шапки/футера”).
- Адаптив и состояния: мобайл/десктоп, ошибки форм, hover/active, пустые состояния (если нужно).
- Критерии приёмки дизайна: по каким признакам принимаем результат.
Если в брифе есть эти 8 пунктов, количество “кругов ада” резко падает.
Рекомендуем почитать:
Про фирменный стиль
Фирменный стиль — это не “про красоту”, а про стандарты визуальной коммуникации: какие цвета и типографика допустимы, как работают отступы, сетка, иконки, иллюстрации, тональность графики, правила для логотипа и примеры применения.
Для дизайнера это один из ключевых документов, потому что он снимает половину спорных вопросов ещё до первого макета: что можно, что нельзя и как выглядит “по-нашему”.
Поэтому в брифе стоит прямо указать, что фирменный стиль есть (и приложить ссылку), а также проверить простую вещь: дизайнер умеет с ним работать и соблюдать гайдлайны. Подробно разбирать фирстиль и как его внедрять в дизайн — это уже отдельная история и отдельная статья.
Как давать референсы так, чтобы они помогали
Референс — это не “сделай так же”. Это “вот какой визуальный язык нам подходит”.
Чтобы референсы работали, делайте просто:
- Дайте 2–4 примера “нравится” и 1–2 “не нравится”.
К каждому — 1–2 строки “почему”: сетка, плотность, акценты, тип иллюстраций, настроение, читаемость.
Отдельно отметьте, что критично: “должно читаться с телефона”, “акцент на CTA”, “выглядит надёжно/технологично”, “без кислотных цветов”. - Самая частая ошибка — прислать ссылку без комментария. Это как сказать “сделай вкусно” и уйти.
Мини-бриф (пример, как это должно выглядеть)
Нужен дизайн блока “Тарифы” и “FAQ” на странице продукта.
- Цель: увеличить клики по кнопке “Оставить заявку”.
- Аудитория: владельцы малого бизнеса, чаще мобайл, времени мало.
- Обязательно: 3 тарифа, сравнение по 5 пунктам, FAQ (6 вопросов), CTA-кнопка.
- Ограничения: текущие цвета/шрифты, без редизайна шапки и футера.
- Референсы: 2 “нравится” (почему), 1 “не нравится” (почему).
- Готово: читаемо на мобайле, акценты на CTA и различиях тарифов, макет аккуратно собран в Figma.
Критерии приёмки дизайна (чтобы правки были не “на вкус”)
Если критериев нет, правки превращаются в бесконечное “ещё чуть-чуть”.
Примеры нормальных критериев:
– на мобайле текст читается без зума, ключевые блоки не “проваливаются” вниз;
– иерархия ясна: понятно, где главное действие и чем тарифы отличаются;
– состояния продуманы: hover/active (если это веб), ошибки формы, пустые состояния (если применимо);
– сетка и отступы стабильные, нет “пляски” между блоками;
– компоненты в Figma оформлены аккуратно (названия/варианты/стили), чтобы разработчик не гадал.
Как организовать правки, чтобы не убить проект
Сразу договоритесь о процессе:
– сколько итераций делаем (обычно 2–3 достаточно);
– как вы принимаете промежуточный результат (комментарии в Figma, одним пакетом);
– кто финально утверждает (один человек, иначе будет “синод правок”);
– что считается “готово” (критерии выше).
Это звучит скучно, но экономит дни.
Скачать пример в docx формате - скачать!
Хороший бриф — это короткая договорённость о главном: цель, аудитория, обязательный контент, ограничения и критерии “готово”. Один раз нормально забрифовали — и правки перестают быть спором о вкусах, превращаясь в конкретные улучшения по делу. А чтобы всё работало без сюрпризов, опирайтесь на чётко сформулированную задачу и границы работ — тогда дизайнеру не придётся гадать, а вам не придётся “вспоминать, что вы имели в виду”.
