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