Как оформить бриф перед стартом дизайна, чтобы не переделывать половину проекта

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

Почему без брифа согласование растягивается на недели

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

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

Что обязательно включить в бриф перед стартом

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

Бизнес и задача проекта

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

Целевая аудитория и сценарии использования

Кто приходит на страницу и с каким вопросом, с какого устройства, в каком состоянии — сравнивает варианты или уже готов оставить заявку. Разная аудитория требует разной структуры и разного тона текста, и угадать это без вводных почти невозможно.

Конкуренты и референсы

Ссылки на 2-3 сайта конкурентов и 2-3 референса «нравится по стилю» — с пояснением, что именно нравится: композиция, цвет, шрифт, подача. Референс без объяснения («вот это красиво») бесполезен: дизайнер не узнает, что именно скопировать в подход, а что отбросить.

Визуальные ограничения (брендбук, цвета, шрифты)

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

Технические требования (устройства, форматы, интеграции)

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

Чем бриф отличается от технического задания?

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

Ошибки в брифе, которые всплывают только на этапе правок

Часть проблем с брифом незаметна на старте и проявляется только тогда, когда макет уже отправлен на согласование.

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

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

Как понять, что бриф готов к передаче в работу

Бриф можно считать достаточным, если выполнены три условия. Во-первых, на каждый из пяти блоков выше есть ответ — пусть короткий, но конкретный, а не «на усмотрение дизайнера». Во-вторых, назначен один ответственный со стороны клиента, который принимает решения по фидбеку и не перекладывает их на коллег в последний момент. В-третьих, зафиксирован формат и срок первой итерации — когда дизайнер покажет первый вариант и в каком виде команда будет его смотреть. Если все три условия закрыты, можно передавать бриф в работу: дальше дизайнер опирается на документ, а не на устные договорённости, которые легко забыть или переиначить. Подробный разбор самого процесса согласования — в материале о том, как построить workflow согласования дизайна с нуля.

Практика структурированного брифинга перед началом дизайн-работы — не изобретение отдельных студий: формализованный сбор вводных перед проектированием интерфейса описан и в общих разборах UX-процесса, например в материалах Nielsen Norman Group про фазу discovery.