Дизайнер прислал схему будущего сайта: заголовки, серые прямоугольники, кнопки. На ней ещё нет фотографий и фирменных цветов. Что здесь проверять — и достаточно ли ответа «в целом нравится», чтобы двигаться дальше?
На этапе прототипа нужно договориться, какую задачу посетитель решит на сайте, какая информация ему поможет и что произойдёт после каждого важного действия. Для этого понадобятся понятные экраны, переходы между ними и список решений. Красивое оформление появится позже.
Разберём, как подготовить такой прототип, пройти по нему путь клиента и зафиксировать согласованную версию. Примером будет условный сайт компании, которая обслуживает офисную технику. По тому же порядку можно проверить страницу другой услуги, каталог или форму заказа.
Что такое прототип сайта и что вы согласовываете
Прототип сайта — модель будущего интерфейса для проверки идеи. Он может выглядеть как рисунок на бумаге, набор экранов или интерактивная демонстрация. Выбор зависит от того, что требуется выяснить. Бумажного наброска достаточно, чтобы обсудить расположение блоков. Если нужно проверить переходы между экранами, подготовьте кликабельную модель.
У ранней схемы экрана есть название — вайрфрейм, то есть каркас. Он показывает расположение текста, изображений и элементов управления. К этому каркасу можно добавить переходы и получить кликабельную модель. Figma описывает вайрфреймы как способ проработать устройство интерфейса до его детального оформления.
Чтобы не спорить о названиях, заранее определите результат этапа. В этой статье под прототипом понимается каркас страниц с содержанием, важными состояниями и объяснёнными переходами. «До дизайна» означает до визуального оформления: проектирование самого взаимодействия уже относится к работе дизайнера.
Разные материалы отвечают на разные вопросы:
- Структура сайта — какие разделы и страницы нужны и как они связаны.
- Техническое задание — что система должна делать и при каких условиях.
- Прототип — как человек увидит информацию и выполнит действие.
- Визуальный макет — как будут выглядеть экраны: композиция, типографика, цвета, изображения.
Прототип дополняет ТЗ. Нарисованная кнопка «Отправить» ещё не определяет, куда попадёт обращение, кто получит уведомление и как система обработает сбой. Эти условия нужно записать отдельно и связать с экраном. Для подробного описания требований пригодится руководство по подготовке ТЗ на сайт.
Начните с задачи, а не с набора блоков
До первого рисунка соберите информацию о том, кто придёт на страницу. Поговорите с сотрудником, который принимает обращения: что клиент спрашивает первым, каких данных не хватает для ответа, из-за чего разговор обрывается. Посмотрите типовые запросы, переписку и материалы о продукте. Для действующего сайта добавьте наблюдения из аналитики. Необязательно иметь всё сразу — пробелы тоже нужно увидеть до рисования.
Затем запишите короткое задание на прототип. Для нашего условного примера оно может выглядеть так:
| Что определить | Заполненный пример |
|---|---|
| Посетитель | Офис-менеджер, которому нужно организовать обслуживание принтеров |
| Задача посетителя | Понять, подходит ли компания, и передать сведения для обсуждения обслуживания |
| Вопросы до обращения | С какой техникой работают, что входит в услугу, как начинается сотрудничество |
| Целевое действие | Отправить запрос на обслуживание |
| Данные для первого разговора | Рабочая почта, компания, краткое описание техники и задачи |
| Ограничение первой версии | Без личного кабинета и расчёта цены на сайте; детали обсуждает менеджер |
Эта запись уже помогает принимать решения. Если посетителю нужно узнать, обслуживают ли его технику, ответ должен быть доступен до формы. Если стоимость зависит от состава оборудования, кнопка «Узнать точную цену» обещает больше, чем выбранный сценарий. Для нашего примера точнее «Обсудить обслуживание».
Подберите материалы для каждого обещанного блока: описание услуги, перечень поддерживаемой техники, порядок обращения. Если факта пока нет, отметьте, кто его уточнит. Заглушка «Работаем со всеми моделями» может незаметно превратиться в неподтверждённое обещание на готовом сайте.
Назначьте одного человека, который принимает итоговое решение со стороны заказчика. Проектировщик собирает экраны, сотрудники продаж проверяют содержание, разработчик — выполнимость функций. Замечания могут оставлять все участники, но противоречия должен разрешать определённый ответственный. Иначе один попросит убрать поле, другой — вернуть, а дизайнеру придётся выбирать за бизнес.
Для многостраничного сайта сначала составьте перечень типов страниц: услуга, категория, карточка, контакты. Отдельный прототип каждого похожего товара обычно не нужен; покажите типовой экран и варианты, которые меняют его устройство. Например, товар с выбором комплектации и товар без наличия. Если перечень разделов ещё не определён, начните со структуры сайта.
Выберите достаточную детализацию
Простой странице не всегда нужна сложная интерактивная модель. Начните с вопроса, который предстоит проверить.
| Что нужно проверить | С чего начать | Когда усложнить |
|---|---|---|
| Понятны ли предложение и порядок информации | Бумажная схема с заголовками и текстом | Когда расположение блоков согласовано и нужны состояния элементов |
| Удобно ли читать страницу и находить нужные разделы | Экранный каркас для компьютера и телефона | Когда нужно проверить меню, раскрытие блоков или переход к форме |
| Можно ли пройти оформление заказа, поиск или запись | Связанные кликабельные экраны | Когда результат зависит от ввода данных, условий или сложных взаимодействий |
Бумага подходит для первой версии: лист легко перерисовать и обсудить рядом с коллегой. Цифровой каркас удобнее, когда участники работают удалённо и нужно точно указать место замечания. Для сценария с несколькими экранами полезны клики: человеку не придётся угадывать переход по нарисованной стрелке.
Выбирайте инструмент, который команда сможет открыть и отредактировать. Не переносите уже понятный каркас в новый сервис только ради презентации. Сначала убедитесь, что исполнителю доступно редактирование, а согласующим — просмотр нужного сценария.
Есть и обратная ситуация: сайт собирается из готового шаблона, а новая задача ограничена одной формой. Тогда можно показать существующий экран и отдельно спроектировать форму с её состояниями. Полная перерисовка сайта не поможет проверить этот конкретный вопрос.
Как собрать первый прототип страницы
Вернёмся к обслуживанию офисной техники. Нам нужен путь от вопроса «Подходит ли мне эта компания?» до понятного обращения. Сначала разложите этот путь словами:
Посетитель узнаёт услугу → проверяет подходящую технику → понимает порядок работы → оставляет запрос → получает подтверждение.
Теперь превратите каждую часть в экранный блок.
Нарисуйте каркас и сразу добавьте содержание
Возьмите лист вертикально. Сверху обозначьте шапку с названием компании и навигацией. Ниже нарисуйте область первого экрана: заголовок, короткое пояснение, кнопку. Под ней разместите блоки, отвечающие на вопросы посетителя, а затем форму.
Внутри прямоугольников пишите рабочие формулировки. Вместо «Здесь оффер» — «Обслуживание принтеров для офисов». Вместо «Преимущества» — вопрос, на который блок должен ответить: «Какую технику принимаем на обслуживание?». Затем добавьте черновое содержание ответа. Такой набросок уже можно обсуждать, даже если он нарисован неровно.
Для нашего примера порядок будет следующим:
- Первый экран. Какую услугу предлагает компания и как начать разговор.
- Подходящая техника. Перечень видов оборудования и ограничения, подтверждённые бизнесом.
- Порядок работы. Какие сведения передать и что произойдёт после обращения.
- Форма. Данные, необходимые для первого разговора, и понятное действие отправки.
Не считайте этот порядок универсальным. Если клиенту для выбора сначала нужны условия выезда, поднимите соответствующий ответ. Если услуга незнакомая, потребуется объяснение. Проверяйте связь блока с вопросом покупателя, а не наличие привычной секции на сайтах конкурентов.
Показывайте близкий к будущему объём текста. Короткая заглушка не обнаружит, что реальное название услуги занимает несколько строк, а описание условий раздвигает соседние блоки. Для изображения достаточно рамки с пояснением: например, «Фото процесса обслуживания». Если фотография должна доказывать конкретное преимущество, запишите, что именно на ней потребуется показать.
Проверьте вход на страницу и мобильный вариант
Посетитель может прийти из поиска сразу на страницу услуги, минуя главную. Поэтому на ней должны быть понятны предложение, исполнитель и следующий шаг. Не прячьте обязательное пояснение только на главной странице. Здесь же можно отметить рабочий H1 и ссылки на связанные разделы; полный сбор семантики остаётся отдельной задачей.
Рядом нарисуйте узкий вариант страницы для телефона. Решите, как открывается меню, в каком порядке идут блоки, где находится кнопка и как выглядит форма. Если на компьютере содержание стоит в две колонки, на телефоне нужно выбрать последовательность. Простое уменьшение всего рисунка не показывает этого решения.
На раннем этапе не требуется согласовывать каждый отступ. Нужно понять, сохраняется ли путь к обращению и не исчезает ли важная информация. Поведение на реальных устройствах и доступность интерфейса дополнительно проверяются при реализации.
Добавьте переходы и состояния
Статичный рисунок объясняет расположение информации. Чтобы проверить действие, подпишите, куда ведёт каждая важная кнопка и что увидит человек после неё.
В нашем примере кнопка первого экрана переводит к форме на этой же странице. После попытки отправки возможен не только успех. Нужны ответы на ошибки ввода и технический сбой.
| Ситуация | Что показать в прототипе |
|---|---|
| Человек открыл форму | Понятные названия полей, обязательность заполнения, пояснение следующего шага |
| Не заполнена рабочая почта | Ошибка рядом с полем, остальные введённые сведения остаются |
| Данные отправляются | Состояние «Отправляем…», исключающее повторное нажатие во время отправки |
| Получен ответ об успешном приёме | Сообщение «Запрос получен» и объяснение дальнейшего контакта |
| Отправка завершилась ошибкой | Сообщение о проблеме и способ продолжить; успешный приём не показывается |
Это требования к поведению будущей формы. В прототипе можно переключать заранее нарисованные состояния: само переключение ещё не отправляет письмо и не проверяет данные на сервере. Разработчик отдельно определит, как сохранять введённое, обрабатывать повторные обращения и проверять доставку запроса.
Если в реальном сервисе нет подтверждённого срока ответа, не вписывайте его в экран успеха. Формулировку «Ответим за несколько минут» нельзя согласовать только потому, что она хорошо помещается рядом с кнопкой.
Как связать экраны в Figma
Для цифровой демонстрации соберите экран страницы, состояние формы с ошибкой и подтверждение. В Figma отдельная область экрана называется фреймом. По официальной инструкции по прототипированию порядок такой:
- Выделите элемент, с которого начинается действие, например кнопку.
- В режиме Prototype соедините его с целевым фреймом и задайте действие по нажатию.
- Назначьте начальный экран сценария и откройте просмотр, чтобы пройти переходы.
Для проверки ошибки сделайте отдельную ветку демонстрации и обозначьте её проверяющему. Не выдавайте ручное переключение за работающую проверку формы. Прототип с настоящим вводом данных потребует дополнительной настройки.
Поделиться можно ссылкой на начало сценария. Перед встречей проверьте её под правами согласующего: возможность редактировать файл и возможность просматривать прототип — разные уровни доступа. В справке Figma указано, что для воспроизведения прототипа достаточно права просмотра.
Проверьте маршрут без подсказок
Сначала пройдите модель внутри команды. Проектировщик проверяет связь экранов, представитель бизнеса — содержание, разработчик — спорную логику. Если форма обещает мгновенный расчёт, а стоимость определяет менеджер, это нужно исправить до согласования.
После этого покажите прототип человеку, похожему на будущего посетителя. Для нашего примера нужен тот, кто сталкивается с организацией обслуживания офисной техники. Коллега, уже знающий проект, может проверить ссылки, но будет угадывать решения там, где новый клиент остановится.
Дайте задачу с понятной целью: «В офисе нужна компания для обслуживания принтеров. Выясните, подходит ли это предложение, и передайте запрос на обсуждение». Не добавляйте «нажмите верхнюю кнопку и заполните форму»: такая подсказка скрывает проблему навигации.
Попросите участника проговаривать, что он ищет и чего ожидает. Записывайте конкретные моменты: не понял назначение кнопки, искал условия обслуживания, принял обязательное поле за необязательное. Если пришлось помочь, отметьте где и чем — самостоятельно пройденным этот участок уже не считается.
После проверки уточните непонятное: «Что вы ожидали увидеть после нажатия?» полезнее, чем «Вам понравилась форма?». Если обнаружилась проблема, измените экран и снова проверьте именно этот участок. Не нужно каждый раз перерисовывать весь сайт.
Такой проход помогает обнаружить затруднения, но не измеряет будущую конверсию сайта. Он также не проверяет скорость, отправку заявок и устойчивость к нагрузке.
Превратите замечания в решения
Обсуждение «нравится — не нравится» трудно завершить. Просите связывать замечание с экраном, задачей пользователя и наблюдением. Ниже — учебные образцы, а не результаты проведённого исследования.
| Замечание | Как сделать его рабочим | Что проверить после изменения |
|---|---|---|
| «Первый экран непонятный» | «Из заголовка неясно, что услуга для офисов. Уточнить аудиторию» | Можно ли определить назначение услуги без пояснений ведущего |
| «Уберите лишние поля» | «Для первого разговора не нужен инвентарный номер устройства. Перенести его сбор на следующий этап» | Достаточно ли менеджеру оставшихся данных для начала работы |
| «Нужна другая кнопка» | «Надпись обещает готовую цену, но после неё открывается запрос на обсуждение. Уточнить действие» | Совпадает ли ожидание от кнопки с открывшимся экраном |
В общий журнал добавьте ответственного, принятое решение и статус: исправить, требуется уточнение, решено. Комментарий не становится решённым только потому, что дизайнер передвинул блок. Нужно проверить, исчезла ли указанная проблема.
Если участники спорят, вернитесь к исходной задаче. Например, отдел продаж хочет обязательный телефон, а маркетолог предлагает оставить почту. Сначала выясните, как команда действительно начинает обработку запроса и может ли связаться выбранным способом. Это решение о процессе работы, которое затем отражается в форме.
Правки визуального оформления можно отложить до соответствующего этапа. Но замечание «текст не читается» нельзя автоматически отнести к выбору шрифта: возможно, в одном блоке собраны разные мысли или потерян порядок чтения. Исправьте структуру сейчас, если именно она мешает понять предложение.
Когда прототип можно передать на дизайн
Перед согласованием откройте ту версию, которую получит дизайнер, и проверьте её по списку:
- На каждом типовом экране понятны его задача и следующее действие.
- Ключевые тексты отражают реальные условия; неподтверждённые места отмечены и имеют ответственного.
- Основной маршрут проходится от точки входа до результата; важные ошибки и возвраты показаны или описаны.
- Для мобильного варианта определены порядок блоков, навигация и работа формы.
- Содержание проверено заказчиком, спорные функции — разработчиком.
- Замечания, меняющие сценарий или состав страницы, разобраны. Отложенные вопросы перечислены отдельно.
Если открытый вопрос может изменить интерфейс, рано передавать затронутый экран в детальный дизайн. В нашем примере это решение, будет ли цена рассчитываться автоматически. А выбор итоговой фотографии можно оставить на следующий этап, если уже определены её смысл и место.
Зафиксируйте результат письмом или записью в системе задач. Учебный образец согласования:
«Согласована версия прототипа 0.3 — “Обслуживание офисной техники”. В комплект входят страница услуги для компьютера и телефона, состояния формы и описание переходов. Проверяемый сценарий: ознакомиться с услугой и отправить запрос на обсуждение. Автоматический расчёт цены и личный кабинет в эту версию не входят. До визуального оформления ответственный со стороны заказчика уточняет перечень обслуживаемой техники. Остальные замечания к структуре закрыты. Визуальное оформление этим согласованием не утверждается».
В рабочей записи добавьте ссылку на конкретную сохранённую версию, дату и имена согласующих. Если перечень техники потребует нового способа выбора, сначала исправьте прототип; простое уточнение текста может не менять структуру. Изменяемая ссылка без обозначения версии не позволяет понять, какой именно вариант обсуждался.
Передайте дизайнеру сам редактируемый файл, ссылку на просмотр, описание сценариев, список решений и материалы для контента. Если прототип сделан на бумаге, сохраните читаемые фотографии с номерами экранов и пояснениями переходов. Убедитесь, что получатель понимает, какая версия актуальна и где смотреть нерешённые вопросы.
Новые идеи после согласования оформляйте отдельными изменениями: что добавляется, зачем и какие экраны затрагивает. Например, переход от запроса менеджеру к самостоятельной записи на время меняет сценарий и требует возврата к прототипу. Исправление экрана, который не соответствует уже согласованному поведению, обсуждается как исправление этой ошибки. Так сохраняется связь между исходной задачей и тем, что команда делает дальше.
Начать можно с одной страницы: запишите задачу посетителя, нарисуйте путь к обращению и покажите его человеку, который не участвовал в подготовке. После этого у вас появится предметный список вопросов для проектировщика. Если нужен сайт под задачи бизнеса, обсудите разработку с Profitkit — приложите описание продукта, набросок и вопросы, которые пока не удалось решить.
Больше материалов о разработке и работе с сайтом — в Telegram-канале Profitkit.
