Дизайн-макет может выглядеть согласованным на ревью — и при этом не отвечать на простой вопрос: как клиент найдёт услугу, уточнит условия и оставит обращение. На практике проблема появляется раньше визуальной части. Прототип рисуют как набор страниц, не проверив путь посетителя и данные, которые потом понадобятся продажам. В итоге после утверждения дизайна вспоминают про калькулятор, дилерский кабинет, форму подбора, загрузку документов и разные маршруты для новых и действующих клиентов.
Прототип нужен не для выбора оттенка кнопки. Он фиксирует состав экранов, переходы, состояния и условия, при которых человек получает следующий шаг. Чем раньше этот разговор проводят с продажами и поддержкой, тем меньше дорогостоящих изменений попадает в вёрстку и интеграции.
Начинайте с обращений, а не с карты меню
Каталог разделов сам по себе не объясняет, как человек решит свою проблему. Полезнее собрать повторяющиеся ситуации из звонков, переписок, причин отказа и вопросов поддержки. Новый клиент может искать цену и сроки, действующий — инструкцию или сервис, партнёр — прайс и статус заявки. Домен у этих людей одинаковый, задачи — нет.
Для каждой ситуации формулируют начальную точку, вопрос человека, нужную информацию, действие и ожидаемый результат. Записывать сценарий стоит простым языком: «посетитель с мобильного устройства ищет обслуживание оборудования, выбирает модель, видит условия выезда, оставляет номер и получает понятное подтверждение». Такая запись сразу выявляет спорные места: где хранится список моделей, кому уходит обращение, что увидит человек при ошибке, нужна ли авторизация.
Разделяйте маршрут и контент страницы
Одна страница редко обслуживает один сценарий. На странице услуги посетитель может сравнить варианты, скачать документ, позвонить или оставить заявку. Прототип должен показать приоритеты: какое действие основное, какие данные нужны до обращения, что делать, если данных нет. Иначе в макет попадают одинаково заметные кнопки, а менеджеры получают обращения без контекста.
Проверьте сценарии с продажами
Продажи знают, какие вопросы задают до сделки и какие данные позволяют подготовить ответ. Но не каждую информацию стоит превращать в обязательное поле формы. На прототипе согласуют, что посетитель выбирает сам, что уточняет менеджер, какие варианты влияют на маршрут и какие сведения нельзя просить без необходимости.
Полезно разобрать минимум четыре типа сценариев: первое обращение, повторный клиент, срочный запрос и нестандартная ситуация. Для первого обращения достаточно темы и удобного способа связи. Для сервисной заявки нужен идентификатор оборудования или договор. Для сложного проекта может понадобиться загрузка технического задания. Эти различия должны быть видны в логике, а не спрятаны в комментарии к экрану.
Подключите поддержку до передачи в дизайн
Поддержка видит точки, где люди застревают: непонятные статусы, устаревшие документы, неочевидные условия гарантии, ошибки регистрации. Её участие помогает спроектировать состояния без результата: поиск ничего не нашёл, услуга недоступна в регионе, файл заменён, форма не отправилась, доступ к документу закрыт.
Прототипу нужны не только стрелки вперёд. Отдельно проверяют возврат назад, отмену действия, пустые экраны, сообщения об ошибке и контакты поддержки. Если таких состояний нет на этапе схемы, их всё равно придётся делать — но уже без согласованного текста и владельца процесса.
Как проводить проверку
На встрече не показывают весь сайт подряд. Участникам дают конкретную задачу и просят пройти путь по прототипу: найти услугу, сравнить условия, отправить запрос, открыть документ, изменить данные. Автор фиксирует, где человек спросил «что дальше?» или выбрал неверный маршрут. Это полезнее общего «понятно» в конце демонстрации.
Результат оформляют списком решений: изменили структуру, добавили экран, уточнили подпись поля, перенесли вопрос на этап звонка, описали правило маршрутизации. У каждого решения — владелец и критерий готовности. Так прототип становится основой для дизайна, разработки и приёмки, а не одноразовой картинкой.
Типичные ошибки
- Рисуют страницы без задач посетителя. Начинайте с типовых обращений и только потом определяйте, какие страницы и блоки нужны для маршрута.
- Проверяют только счастливый путь. Сценарий, где всё заполнено и доступно, редко раскрывает риски. Нужны состояния ошибки, пустого результата, отказа в доступе, отмены и повторного обращения.
- Путают бизнес-правило и оформление. Решение «покажем кнопку выше» не заменяет правило, кому она доступна и что происходит после нажатия.
- Не назначают владельцев контента. Если у документа, тарифа или статуса нет ответственного, прототип не спасёт от устаревшей информации после запуска.
Нужен ли в прототипе учёт CRM
Да, если действие на сайте создаёт или меняет сущность в CRM. Достаточно показать, какие данные собираются, как определяется маршрут и что увидит менеджер после передачи обращения. Это снимает половину вопросов на этапе интеграции.
Итог
Хороший прототип проверяет не красоту страниц, а путь человека до результата и работу команды после его действия. Согласованные сценарии, исключения и владельцы данных делают дизайн предметным и дают основу для тестирования сайта.
Top comments (0)