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