Приёмка прототипа сайта: пройдите путь клиента до разработки
Как заказчику проверить прототип на конкретных задачах, найти тупики в навигации и зафиксировать готовность к дизайну и разработке.
Спасибо! Заявка принята.
Не удалось отправить заявку. Попробуйте позже.
Оглавление статьи · 6 разделов
На встрече дизайнер быстро прокликал прототип, открыл карточку услуги, нашёл форму и показал подтверждение. Маршрут выглядел очевидным: автор заранее знал, куда идти. Принимать прототип сайта перед разработкой лучше иначе. Дайте задачу человеку, который видит схему впервые, и наблюдайте, сможет ли он выбрать нужную услугу и получить понятный результат без подсказки автора.
Напишите задания словами покупателя
Вместо «раскройте меню и нажмите калькулятор» дайте человеку жизненную ситуацию. Например, закупщику нужны перегородки для офиса, монтаж по выходным и предварительная оценка до выезда специалиста. Пусть выяснит, работает ли компания с таким объектом и что отправить для расчёта. Собственнику уже установленной перегородки нужен ремонт направляющей. Эти люди могут начать на одной главной странице, но прийти должны к разным решениям.
Для каждого задания заранее определите признак успеха. Первая роль нашла условия монтажа и форму с возможностью приложить план. Вторая нашла информацию о ремонте или понятное объяснение, что компания оказывает только монтаж. Если предполагаемая услуга ещё не подтверждена владельцем бизнеса, отметьте открытый вопрос. Прототип не должен обещать посетителю работу только ради красивого маршрута.
Проверьте вход не только с главной
Откройте ссылку на одну внутреннюю страницу, как если бы человек пришёл из объявления или поиска. Понятны ли специализация компании, назначение страницы и следующий шаг? Можно ли вернуться к выбору вариантов, не теряя ориентир? Ссылка в меню может быть очевидна дизайнеру и непонятна новичку. Попросите участника перед кликом сказать, что он ожидает увидеть. Расхождение между ожиданием и экраном точнее описывает проблему, чем оценка «название не нравится».
Посчитайте не просто число кликов. Четыре уверенных перехода могут быть проще двух экранов, на которых посетитель вынужден угадывать. В журнале отметьте место первого сомнения, текст кнопки, конкурирующие варианты и фактический результат. Для рекламного входа пригодится статья «Посадочная страница для рекламы»: обещание объявления должно совпадать с задачей на первом экране.
Соберите состояния, которых нет на красивой схеме
Добавьте в сценарий пустую категорию, длинное название услуги, отсутствие подходящего результата и отказ прикреплённого файла. Попросите показать, где пользователь узнает о проблеме и как её исправит. Для заявки нужны хотя бы начальный экран, ошибка поля и подтверждение. Если отправка в прототипе ещё имитируется, прямо обозначьте точку имитации и запишите будущую проверку доставки после разработки.
Разберите возврат на шаг назад. Человек заполнил адрес объекта, передумал насчёт способа связи и вернулся к предыдущему экрану. Какие данные сохраняются? Где он может посмотреть итог? Уточните мобильный сценарий: видны ли название услуги и основное действие без постоянно открытого меню, доступны ли ссылки под длинной таблицей, понятно ли закрытие всплывающего окна. Смена ширины макета сама по себе не проверяет этот путь.
Разделите замечания по последствиям
Записывайте наблюдение по четырём полям: исходное задание, место остановки, что сделал участник, какой результат нужен. Например, «в карточке монтажа вместо отправки плана выбрал вызов замерщика, поскольку обе кнопки называются “Оставить заявку”». Возможное решение — развести действия в названиях и пояснить, когда нужен выезд. Не предписывайте разработчику менять цвет кнопки, пока не выяснили, была ли причина в видимости или в смысле.
В первую очередь решайте тупики и ложные обещания. Потом — непонятные развилки и неудобные повторы. Вопросы фирменного цвета и иллюстраций обычно удобнее обсуждать на визуальном макете. Но реальный объём текста, наличие фотографий и длинные названия стоит проверить уже сейчас: короткая заглушка легко создаёт иллюзию, что раздел помещается на мобильном экране.
Зафиксируйте, какую версию вы приняли
После правок дайте тот же сценарий другому участнику. Сохраните ссылку на версию прототипа, перечень маршрутов, список известных ограничений и владельцев открытых вопросов. Отдельно согласуйте, какие действия проверяются позже на готовом сайте: реальные письма, интеграция с CRM, платежи, поиск по полному каталогу. Номер экрана или имя файла полезнее фразы «как обсуждали во вторник».
Финальный протокол может занимать одну страницу. В нём видно, где начинается путь клиента, что он должен увидеть по дороге, как завершает задачу и кто принимает результат. Когда в разработке возникает спор о неожиданном переходе, команда сможет открыть конкретное задание и воспроизвести его с самого начала. Если изменился состав работ, сопоставьте предложения и смету на сайт перед согласованием следующей стадии.
Свобода от рекламной зависимости – за 1 день
ЛидБлог за 1 день превращает сайт в канал привлечения новых клиентов из Яндекс, Google и поиска в нейросетях. Работает без вашего участия
.PDF ФАЙЛ
Выберите способ связи и укажите номер, чтобы получить персональный план привлечения клиентов с помощью нового канала «ЛидБлог» и узнать стоимость внедрения
Вопросы и ответы
Нужен ли на приёмке готовый фирменный дизайн?
Для проверки маршрута обычно достаточно читаемых названий, реальных примеров контента и кликабельных действий. Визуальную приёмку можно выделить отдельно.
Что делать, если участник выбрал другой рабочий путь?
Проверьте, достигнута ли цель без потери информации. Удобный альтернативный маршрут стоит сохранить и включить в дальнейшую проверку.
Как принять форму, которая пока ничего не отправляет?
Проверьте необходимые поля, исправление ошибок и ожидаемый экран подтверждения. Реальную доставку сообщения оставьте отдельным критерием для собранного сайта.