Бриф на дизайн сайта: как согласовать бизнес-задачу до макетов

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

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

Бриф на дизайн сайта начинается с проблемы, а не стиля

Фраза «нужен современный сайт» не объясняет, что изменится для покупателя. Вместо неё опишите наблюдаемое препятствие: посетитель не понимает, какие проекты выполняет компания, отправляет неполное обращение или ожидает услугу, которой нет. Добавьте источник: запросы в отдел продаж, поисковые логи, аналитику или интервью. Если доказательств пока нет, прямо обозначьте проблему как гипотезу.

Отдельно запишите желаемый результат для человека и для компании. Например, посетитель может определить, подходит ли услуга для его задачи, а менеджер получает достаточно контекста для предметного ответа. Так вы не подменяете бизнес-цель цветом кнопки. Показатель обращений имеет смысл только вместе с определением их качества и способа учёта.

Design Council в модели Double Diamond разделяет понимание проблемы, её определение и поиск решений. Для брифа полезен принцип: сначала согласуйте проблему, затем обсуждайте способ. Это не требование внедрять методологию и не обещание улучшения продаж.

Разделите ответственность и право окончательного решения

Владелец определяет бизнес-приоритет и допустимые компромиссы. Маркетинг объясняет аудитории, каналы привлечения и сообщения. Продажи и операционная команда проверяют обещания: какие обращения могут обработать, какие сведения нужны и кто будет обновлять контент. Технический представитель называет ограничения действующего сайта и систем. Один человек может выполнять несколько ролей, но ни одна важная функция не должна остаться без ответственного.

Один координатор не означает одного источника истины

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

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

Соберите доказательства об аудитории и её главном действии

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

Для каждой аудитории определите основное действие и нужную перед ним информацию. Для запроса оценки это могут быть границы услуги, примеры работ и объяснение дальнейшего контакта. Не смешивайте поддержку действующих клиентов с новыми продажами. Приоритетное действие не требует убрать все остальные маршруты.

Храните факты, предположения и неизвестное отдельно

Бизнес-требования к сайту становятся понятнее, когда у каждого есть статус доказательства. «Менеджеры регулярно уточняют тип задачи» — наблюдение, которое следует подтвердить обращениями. «Обязательное поле решит проблему» — уже гипотеза решения. «Клиент согласится сразу указать бюджет» — предположение, которое стоит проверить. Так дизайнер получает пространство для поиска, а не приказ реализовать непроверенную идею.

Руководство GOV.UK по изучению потребностей пользователей рекомендует анализировать имеющиеся данные, разговаривать с людьми и наблюдать за ними. Оно касается государственных сервисов: адаптируйте методы к своему бизнесу, а не переносите чужие результаты как прогноз.

Превратите пожелания в границы первой версии

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

Поясняйте визуальные референсы: понятная иерархия, сдержанный тон, выразительная демонстрация продукта. Назовите и то, что не подходит. «Сделайте как у них» не даёт разрешения копировать дизайн. Отдельно передайте бренд-материалы и права на их использование.

Не смешивайте этот документ с подробным описанием поведения элементов. После согласования задачи понадобится спецификация состояний интерфейса перед разработкой, но это следующий уровень детализации. Если же нужно организовать закупку, вопрос формата запроса рассмотрен в материале про RFI, RFP и RFQ для выбора подрядчика. Внутреннее согласие по задаче они не заменяют.

Условный пример: компания принимает запросы на оснащение офисов

Это гипотетическая ситуация, а не кейс GL.ua. Поставщик мебели комплектует офисы. Владелец хочет показать комплексную услугу, маркетинг — ассортимент, менеджерам не хватает сведений о помещении. Вместо того чтобы сразу «добавить большую форму», сначала согласуют, какой запрос бизнес готов обрабатывать.

В согласованной версии приоритет — обращения по комплексному оснащению. Аудитория — ответственный за обустройство офиса, у которого ещё нет готовой спецификации. Главное действие — отправить описание задачи и контакт для уточнения. До этого сайт объясняет, что входит в услугу, какие материалы помогут обсуждению и что произойдёт после обращения. Розничный каталог остаётся отдельным маршрутом, а не исчезает из-за нового приоритета.

Как разрешить противоречие без голосования за макет

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

Проверка примера тоже условная: покажите описание услуги представителям нужной аудитории и попросите объяснить, что компания сделает и с чем к ней можно обратиться. Отдельно дайте менеджеру пробный запрос. Если посетитель ждёт бесплатного полного проекта, а менеджер не понимает предмета разговора, нужно уточнить предложение и необходимый контекст, а не только изменить оформление.

Проверьте согласование до макетов и до запуска

Согласование дизайн-брифа должно завершаться проверкой одинакового понимания. Не спрашивайте только, все ли прочитали документ. Попросите участников своими словами объяснить главную задачу, приоритетную аудиторию и границы первой версии. Разные ответы покажут, где согласование пока формальное.

1. Сопоставьте формулировку проблемы с доказательствами; для неподтверждённого назначьте проверку и ответственного.
2. Пройдите главный сценарий словами: что человек должен понять, сделать и получить от компании.
3. Сверьте обещания с продажами и операционной командой, включая дальнейший контакт и поддержку.
4. Проверьте готовность контента, права на материалы и список открытых вопросов, блокирующих проектирование.
5. Зафиксируйте согласованную версию, решения по отложенному и условия повторного пересмотра перед запуском.

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

Что влияет на сроки, стоимость и риски

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

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

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

Когда можно передавать задачу в дизайн

К макетам переходите после согласования проблемы, аудитории, основного действия, границ версии и ответственных. Для неизвестного определите способ проверки и зависимые решения. Тогда обсуждение дизайна опирается на общие критерии, а не на соревнование вкусов.

Если готовите новый сайт, передайте GL.ua (Глянец) этот согласованный контекст для обсуждения проектирования и разработки сайта под бизнес-задачу. Практический следующий шаг — определить, какие вопросы нужно закрыть до прототипа и какой объём первой версии можно обоснованно оценить.