В прошлом году у нас был редизайн для B2B-сервиса, где стартовая задача звучала так: «нужен современный дизайн в Figma». Через 9 дней команда уже спорила не о бизнесе, а о «дороже», «чище» и «как у конкурента». Мы не меняли дизайнера - мы переписали бриф, и правки по первому экрану упали с 17 до 6.
Конфликт с дизайнером начинается не на ревью, а в тот момент, когда задача описана как вкус, а не как сценарий. Короткий бриф экономит 1-3 недели согласований и деньги команды.
Проблема почти всегда в постановке, а не в макете
Фраза «сделайте как у конкурентов» не дает дизайнеру почти ничего, кроме необходимости угадывать. Дальше появляется совет вкусов: маркетинг хочет одно, продажи - другое, руководитель - третье. У проекта нет критерия, по которому можно принять макет.
У нас был клиент из промышленного B2B. На созвоне команда говорила про «солидность» и «имидж», но не могла ответить, что именно должен сделать человек на странице. Оказалось, цель - заявка на аудит с мобильного трафика, потому что 62% посещений уже шло со смартфонов. После этого мы перестроили первый экран, сократили форму и убрали блоки, которые отнимали внимание.
Если после стартового созвона команда не может назвать одно ключевое действие, бриф еще сырой.
Мини-диалог обычно выглядит так:
- Нам нужен современный сайт.
- Что должен сделать пользователь?
- Понять, что мы серьезная компания.
Это не действие. Действие - оставить заявку, скачать КП, записаться на демо, зарегистрироваться.
Дизайнеру нужны опоры, а не папка референсов без подписей
Рабочий бриф почти всегда помещается в 1-2 страницы. Этого хватает, если в документе зафиксированы цель, аудитория, ключевое действие, контент, ограничения и приемка.
Референсы без пояснений почти бесполезны. Если прислать 5 сайтов и написать «нравится все», дизайнер будет гадать: вам нравится сетка, типографика, длина первого экрана или подача кейсов. На практике это быстро превращается в лишние итерации.
Плохая постановка звучит так: «Нужен стильный сайт как у Apple». Рабочая - так: «Цель - увеличить заявки на аудит. Аудитория - собственники компаний 20-100 сотрудников. Главное действие - отправка формы. В этом референсе нравится структура, но не подходит длинный первый экран». Один такой абзац часто снимает 5-10 комментариев на каждом раунде.
Мы сами когда-то собирали вводные «на доверии» и в одном проекте потеряли 2 недели, потому что начали обсуждать визуал раньше, чем договорились о сценарии. Это была наша ошибка, и после нее мы стали жестче фиксировать логику задачи до первого макета.
Короткий шаблон брифа, который экономит недели
Я обычно прошу команду ответить на несколько вопросов до первого макета.
# Бриф на дизайн
1. Продукт / компания
2. Какую бизнес-задачу решаем
3. Кто пользователь
4. Какое действие считаем главным
5. Какие страницы или экраны нужны
6. Какой контент уже готов
7. Ограничения по бренду и разработке
8. Референсы - что нравится и почему
9. Что точно не делаем
10. Кто принимает макет
11. Критерии приемки
12. Сроки и этапы
Блок «что точно не делаем» часто полезнее длинного списка пожеланий. Для лендинга это может быть запрет на две равные кнопки в первом экране, тяжелую анимацию или форму из 8 полей. Для интерфейса - отказ от скрытой навигации, если пользователь работает в системе по 6-7 часов в день.
| Инструмент | Для чего подходит | Где чаще ломается |
|---|---|---|
| Google Docs / Notion | бриф, решения, роли | теряются версии и комментарии |
| FigJam | карта экранов и сценарий | команда уходит в абстракцию |
| Figma | макеты и комментарии | слишком рано начинают спорить о красоте |
Если команда пишет бизнес-требования сразу в Figma, почти всегда растет шум.
Самая дорогая ошибка - обсуждать UI раньше, чем понятен UX
UX отвечает за логику: что человек видит первым, как понимает предложение, где принимает решение. UI отвечает за форму: акценты, читаемость, визуальную иерархию.
На SaaS-лендинге под NDA команда 3 недели спорила про кнопки, карточки и отступы. Реальная проблема была в тарифах: люди не понимали разницу между планами. Мы упростили сравнение, вынесли подсказки, убрали лишние параметры - и клики по CTA выросли на 31% без радикальной смены визуала. Переделка после согласования обычно стоит уже в 2 раза дороже.
Был и обратный пример. Для простой промостраницы мы согласились сразу идти в визуал, потому что казалось, что там и так все понятно. Через 9 дней пришлось вернуться назад: оффер был размыт, форма стояла не там, блоки спорили друг с другом. По бюджету потеряли примерно 80-120 тыс. ₽ работы команды.
Как понять, что UX еще не собран?
Если на странице больше одного сценария, а команда не может расставить приоритеты, в макет идти рано.
Правок становится меньше, когда приемка считается по чек-листу
Бесконечные правки начинаются там, где нет одного согласующего и нет правил приемки. Для одного интернет-сервиса мы ввели простое правило: дизайн согласуют 2 человека, и оба смотрят на один список. За 5 секунд должно быть понятно, что это за продукт, виден ли CTA, не разваливается ли мобильная версия, можно ли собрать экран без дорогой кастомной разработки на текущем стеке - у нас это был Laravel 11 + Blade. После этого мелкие правки сократились на 34% уже в первом спринте.
Что должно быть в критериях приемки?
Не «нравится ли экран», а проверяемые вещи: читается ли оффер, виден ли следующий шаг, собирается ли экран без лишней разработки. Если критерий нельзя проверить, на встрече он почти наверняка превратится в спор о вкусе.
В ближайшие 3 дня соберите бриф на 1 страницу, подпишите 3-5 референсов и позовите на 30 минут только тех, кто реально принимает решение. Самая дорогая правка в дизайне - та, которую можно было убрать одним вопросом до первого пикселя.
