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

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

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

Главная польза брифа — в цене и сроках. Одна форма заявки или пять, готовые тексты или копирайтер, шаблонный дизайн или разработка с нуля — всё это разные строки сметы. Purrweb оценивает подробное заполнение в 1,5–2 часа и отмечает, что после этого обсуждение проекта идёт быстрее и не приходится созваниваться с разными подрядчиками. Magnetto называет похожую цифру — 1–2 часа.

Формат не так важен, как содержание. Бриф может быть анкетой с полями и чекбоксами, как пишет Web-aim, а Kodstudio отмечает, что скачивать отдельный файл не обязательно: вопросы можно скопировать в любой документ или форму.

Мы собрали вопросы из брифов Workspace, Weblium, Kokoc, Facecom, Iaab и других и разложили их по пяти блокам. Число 25 — наша структура, а не стандарт: у Weblium, например, 13 элементов, «которых не избежать». Важнее порядок — от бизнеса к технике, потому что ответы на первые вопросы определяют ответы на последние.

Если времени мало, начните с короткой версии из восьми вопросов: № 1, 2, 5, 7, 9, 12, 23 и 24. Это компания, цель, клиенты, текущий сайт, список страниц, интеграции, сроки и бюджет. Обычно этого хватает, чтобы подрядчик назвал предварительную вилку и задал уточняющие вопросы.

Часть вопросов можно смело оставить с пометкой «не знаю»: метрики успеха (№ 3), второстепенные цели (№ 4), скорость (№ 20), доступность (№ 21) и аналитику (№ 22). Здесь хороший подрядчик предложит варианты сам. А вот цель, аудиторию и бюджет за вас не заполнит никто.

Бриф не обязательно заполнять целиком за один раз. Обязательно — ответить на вопросы, ответы на которые знаете только вы.

Начните с того, что вы знаете лучше любого подрядчика, — со своего бизнеса. Этот блок задаёт тип сайта: лендинг, корпоративный сайт или магазин. А тип сайта задаёт порядок цены. Пишите так, как объясняли бы человеку не из вашей отрасли.

• № 1. Чем занимается компания и что продаёт. Меняет объём структуры и текстов. Если сформулировать трудно — опишите один типичный заказ: кто пришёл, что купил, сколько заплатил.
• № 2. Главная цель сайта. Меняет тип сайта и число сценариев. Если цели нет — напишите, что посетитель должен сделать перед уходом: позвонить, оставить заявку, купить.
• № 3. Как вы поймёте, что сайт работает. Меняет настройку аналитики и форм. Если KPI нет — укажите, что считаете сейчас: заявки, звонки, продажи.
• № 4. Есть ли второстепенные цели. Меняет формы, подписки и интеграции. Если их нет, так и напишите: «нет» — тоже ответ.
• № 5. Кто ваши клиенты. Меняет тон текстов, визуальный язык и порядок блоков. Если портрета нет — опишите трёх последних клиентов.
• № 6. Какие 2–3 сценария важнее всего. Меняет число экранов в прототипе. Если не уверены — возьмите базовые: первый визит, сравнение, заявка или покупка.
• № 7. Какой сайт есть сейчас и что в нём не так. Меняет выбор между редизайном и разработкой с нуля. Если сайта нет — дайте ссылки на соцсети, логотип и брендбук.
• № 8. Кто конкуренты. Меняет глубину анализа перед дизайном. Если не знаете — введите в поиск свой главный запрос и возьмите 2–3 сайта прямых конкурентов.

Хорошие ответы и первый плохой взяты из примеров Bpadevelop, Kokoc и Iaab, остальные плохие — типичные расплывчатые формулировки. Разница не в длине, а в том, что из хорошего ответа можно что-то посчитать: регион, тип клиента, средний чек, цифру цели. Плохой оставляет подрядчику угадывать, а угаданное в смете — риск для обеих сторон.

Что получится: абзац о компании, цель с цифрой, портрет клиента и 2–3 ссылки на конкурентов. YuSMP Group советует давать ссылки и на текущий сайт, и на конкурентов: по ним подрядчику проще понять рынок, чем по описанию.

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

• № 9. Какие страницы и разделы нужны. Меняет число уникальных шаблонов. Перечислите по типам — услуги, отрасли, кейсы, статьи, документы, вакансии — и отметьте, сколько примерно будет каждого.
• № 10. Что должно быть на главной. Меняет объём дизайна первой страницы. Если не знаете — перечислите, что посетитель должен понять сразу после входа.
• № 11. Какие формы нужны и куда уходят заявки. Меняет логику форм и уведомлений. Если пока неважно — напишите, кто и где сейчас обрабатывает заявки.
• № 12. С какими системами сайт должен быть связан: CRM, оплата, учётная система, рассылки. Меняет объём разработки и тестирования. Если не знаете — перечислите программы, которыми компания пользуется каждый день.
• № 13. Кто будет обновлять сайт. Меняет выбор CMS и устройство админки. Если не решили — напишите, как часто и что именно планируете менять.
• № 14. Есть ли готовые тексты. Меняет, нужен ли копирайтер. Если тексты есть частично — отметьте, какие разделы уже закрыты.
• № 15. Есть ли фото и видео. Меняет, нужна ли съёмка или хватит стоковых изображений. Если материалы есть, но устарели, — так и напишите.
• № 16. Кто отвечает за информацию. Меняет скорость согласований. Назовите человека для каждого раздела: услуги, цены, вакансии.
• № 17. Нужны ли SEO и перенос старых адресов. Меняет объём работ при запуске. Если старый сайт приносит трафик, этот пункт обязателен: сохранение URL и редиректы.

Facecom перечисляет, что должно быть в брифе корпоративного сайта: цели, структура, контент, SEO, сохранение URL, CMS, интеграции и аналитика. Там же советуют отдельно отметить готовые тексты, фото, видео и владельцев информации. Совет простой, но, по нашим наблюдениям, именно нехватка контента часто затягивает проект: сайт готов, а наполнять его нечем.

Цену двигает не число страниц, а то, что происходит после клика. Десять страниц, собранных из двух шаблонов, — это в основном вёрстка. Одна форма, которая передаёт заявку в CRM, создаёт сделку и уведомляет менеджера, — это разработка, связка двух систем и тестирование. Поэтому на вопрос № 12 стоит ответить честно, даже если ответ — «пока ни с чем, но через год понадобится».

Что получится: список страниц с примерным количеством, список интеграций и честная отметка, какой контент есть, а какого нет.

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

• № 18. Есть ли фирменный стиль и какой характер нужен сайту. Меняет, начинается ли проект с айдентики. Если есть только логотип — приложите исходник и опишите характер тремя-четырьмя словами: строгий, тёплый, технологичный.
• № 19. Какие сайты нравятся и почему. Меняет число итераций дизайна. Дайте 3–5 ссылок с комментарием «нравится / не нравится и почему».
• № 20. Есть ли требования к скорости и адаптивности. Меняет объём оптимизации. Если цифр нет — напишите, с каких устройств чаще заходят ваши клиенты.
• № 21. Нужна ли доступность. Меняет проверку контраста, фокуса и навигации с клавиатуры. Если не знаете — напишите «ориентироваться на WCAG», подрядчик предложит уровень.
• № 22. Какие действия считать в аналитике. Меняет настройку счётчиков. Пример: отправка формы, клик по телефону, добавление в корзину, оформление заказа.
• № 23. К какой дате нужен сайт и почему. Меняет состав команды и график. Если жёсткой даты нет — укажите желаемую и событие, к которому она привязана.
• № 24. Какой бюджет. Меняет выбор между конструктором и разработкой с нуля. Если точной суммы нет — назовите потолок, выше которого точно не пойдёте.
• № 25. Как будете принимать работу и что после запуска. Меняет объём тестирования и договор поддержки. Если не думали — перечислите, что должно работать в день запуска.

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

Технических требований в большинстве брифов из выдачи нет. Kokoc предлагает вписывать метрики скорости, требования доступности (контраст, фокус, клавиатура) и список событий аналитики — например, form_submit и click_to_call. Контраст текста и фона можно проверить заранее в нашем инструменте проверки по WCAG.

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

Приёмку в бриф вписывают редко. Iaab включает в шаблон блок «Приёмка и поддержка»: критерии приёмки, SLA на поддержку и порядок правок. Facecom перед публикацией предлагает проверять адаптивность, формы и интеграции, скорость, метаданные, канонические адреса, sitemap, robots, редиректы и аналитику. Этот список можно почти целиком перенести в ответ на вопрос № 25.

Что получится: 3–5 референсов с комментариями, базовые технические ожидания, дата, вилка бюджета и критерии, по которым вы примете работу.

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

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

Плохой бриф — не короткий, а такой, после которого подрядчику приходится угадывать.

Нужен ли бриф для сайта на Тильде? Да. Kodstudio отмечает, что вопросы те же: цель, аудитория, структура, контент и сроки от конструктора не зависят.

Можно ли заполнить бриф частично? Можно. Начните с короткой версии из восьми вопросов, а метрики, доступность и аналитику оставьте с пометкой «не знаю» — их обсудите с подрядчиком.

Сколько времени занимает заполнение? Подробный бриф — 1–2 часа по оценке Magnetto и 1,5–2 часа по оценке Purrweb. Короткая версия занимает заметно меньше.

Чем бриф отличается от ТЗ? Бриф заполняют до оценки проекта, чтобы её получить. ТЗ появляется позже и закрепляет договорённости о том, что именно и как будет сделано.

Что делать, если не знаете ответа? Написать то, что знаете: вместо портрета аудитории — трёх последних клиентов, вместо KPI — то, что считаете сейчас, вместо бюджета — потолок. Пустое поле хуже честного «не знаю, но вот что известно».

Обязательно ли скачивать шаблон? Нет. Вопросы можно скопировать в любой документ или форму — это отмечает и Kodstudio.

Бриф принято считать документом для подрядчика: заполнил, отправил, получил цену. Но, разбирая 25 вопросов, мы снова приходим к обратному. Бриф нужен прежде всего самому заказчику. Он заставляет ответить на вопросы, которые иначе всплывут в середине проекта, когда любое изменение стоит дороже всего: зачем сайт, кто на него придёт, что должно случиться после клика.

Если не хочется возиться с файлом в Word, у студии есть онлайн-конструктор брифа. А как мы работаем над сайтами, рассказываем на странице сайты и digital.

Хороший бриф не обещает идеального сайта. Он даёт другое: вы начнёте тратить деньги после того, как примете решения, а не до.

• Workspace, бриф на разработку сайта
• Kodstudio, бриф на разработку сайта: что это, чем отличается от ТЗ
• Purrweb, бриф на разработку сайта
• Magnetto, бриф на разработку сайта: лендинг, Тильда, редизайн
• Weblium, пример хорошего брифа
• Bpadevelop, бриф на разработку сайта
• Kokoc, бриф на разработку дизайна сайта
• Facecom, как заполнить бриф на сайт
• YuSMP Group, шаблон вопросов
• Iaab, шаблон брифа
• Gendalf, бриф на разработку сайта
• Web-aim, бриф на разработку сайта