Всё для рекламы
и про рекламу
Навигация по статье
Какую задачу должен решить посетительЧто именно вы предлагаетеКакие материалы можно использоватьЧто происходит после отправки формыЧто вы будете проверять в прототипеКороткая заготовка брифа
О сайтах

Что подготовить для разработки сайта до первого прототипа

154

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

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

Какую задачу должен решить посетитель

Выберите главное действие для первой версии сайта. Это может быть заявка на расчёт, запись на консультацию, заказ конкретного товара или запрос документов. Опишите, что посетитель получает после этого действия и кто в компании продолжает с ним работу.

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

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

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

Что именно вы предлагаете

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

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

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

Какие материалы можно использовать

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

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

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

Сложите материалы в общую папку и подпишите файлы по содержанию. В брифе оставьте ссылки на нужные документы. Пометка «описание продукта согласовано, фотографии ещё готовим» полезнее набора файлов с одинаковыми названиями.

Что происходит после отправки формы

Опишите маршрут обращения до конкретного сотрудника. Где оно должно появиться, какие поля нужны для первого ответа, кто получает уведомление и что увидит сам посетитель после отправки?

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

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

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

Что вы будете проверять в прототипе

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

Проверьте эти действия с телефона, если ожидаете мобильных посетителей. Важно увидеть весь путь: длинное название услуги, клавиатуру при вводе телефона, выбор файла, сообщение после отправки. Каждый из этих элементов может влиять на удобство обращения.

Обсуждение прототипа станет предметнее, если замечания будут привязаны к задаче посетителя. Вместо общего пожелания изменить экран можно записать: «Я выбираю услугу, но не вижу, какие материалы нужно отправить для расчёта». Такое замечание даёт разработчику понятную задачу для следующей версии.

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

Короткая заготовка брифа

Для первого обсуждения заполните эти строки:

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

Такой документ можно составить самостоятельно. Если по какому-то пункту пока нет ответа, оставьте вопрос открытым и обсудите его на встрече. Уже по этому черновику будет видно, какие части сайта можно показывать в прототипе, а какие зависят от недостающих материалов или решений.

Максим Самусь, основатель ClaudeLab. Занимаюсь созданием сайтов и автоматизацией бизнес-процессов. В работе начинаю с аудита задачи и показываю прототип до договора.

Команды YAGLA и Kokoc Group ведут несколько телеграм-каналов, где публикуются мнения экспертов и авторские лонгриды о бизнесе и маркетинге, многие из которых не попадают на этот сайт. Обязательно подписывайтесь по ссылке: https://t.me/addlist/EhE5LANnrBphMjUy
Максим Самусь, ClaudeLabОснователь ClaudeLab. Создаю сайты и автоматизирую бизнес-процессы: CRM, боты и приложения под задачу компании. Начинаю с аудита и показываю рабочий прототип до договора.
154
0
Написать комментарий