Кликабельный прототип одного сценария

Кликабельный прототип — это связанная последовательность экранов, по которой человек может пройти выбранную задачу. Он нужен, чтобы увидеть, понимает ли будущий пользователь, куда нажать, что ввести и какой результат он получит. Прототип не обязан хранить настоящие данные или выполнять весь расчёт, но должен достаточно правдоподобно воспроизводить проверяемый путь.

Представим учебный продукт: сервис для небольших студий, который помогает согласовывать время встреч. Автор уже нарисовал красивый кабинет, статистику и настройки команды. Однако главный вопрос пока другой: сможет ли администратор предложить клиенту несколько свободных окон и понять, какое из них выбрано? Десять дополнительных экранов не помогают ответить на этот вопрос.

Выберите одно неизвестное

Запишите решение, которое зависит от проверки. Например: «Нужно понять, найдёт ли администратор способ отправить три времени одной ссылкой». Это определяет необходимую часть прототипа. Если вы проверяете понятность стоимости, понадобятся тариф и момент выбора. Если удобство переноса записи — уже созданная встреча, изменение времени и подтверждение.

Руководство GOV.UK рассматривает прототипы как способ исследовать и проверять решения до полноценного создания сервиса; степень подробности зависит от задачи. Для первой проверки иногда достаточно связанных изображений. Если результат зависит от ввода, прокрутки или поведения на телефоне, может понадобиться более реалистичный вариант.

Не выбирайте инструмент по максимальному числу возможностей. Сначала определите, что человек должен сделать без вашей помощи. Затем найдите простой способ воспроизвести именно это действие. Если вы неделю изучаете анимацию, а вопрос касается подписи кнопки, затраты на прототип перестали соответствовать проверке.

Соберите путь от входа до понятного результата

Нарисуйте начало, основные действия и завершение. Для сервиса встреч это может быть выбор даты, отметка свободных интервалов, отправка ссылки и вид подтверждённой записи. Добавьте хотя бы одну ожидаемую ошибку: человек не выбрал время или пытается изменить уже занятый интервал.

Не делайте все кнопки ведущими в один успешный финал. Такой прототип позволяет «пройти» задачу, даже если человек действовал неправильно. Если часть интерфейса не работает, заранее определите, как обозначите ограничение, не подсказывая верный путь. Записывайте остановку из-за ограничения прототипа отдельно от непонимания пользователя.

Используйте правдоподобные, но вымышленные данные. Вместо «Клиент 1» можно показать обычное имя, дату и понятную услугу. Не загружайте реальные контакты без необходимости. Прототип должен помогать представить ситуацию, а не становиться хранилищем рабочих данных до появления нужных мер защиты.

Подготовьте задание без подсказки

Плохое задание: «Нажмите “Создать предложение времени”, выберите три окна и скопируйте ссылку». Оно проверяет выполнение вашей инструкции. Рабочий вариант: «Клиент хочет встретиться на следующей неделе. Предложите ему три удобных времени так, чтобы он мог выбрать одно сам».

Перед встречей пройдите сценарий самостоятельно на том же устройстве, на котором будет участник. Проверьте ссылки, начало и возможность вернуться. Если важен телефон, тест на большом мониторе оставляет часть вопроса открытой. Не приглашайте человека только потому, что он рядом: его задачи и опыт должны соответствовать выбранному сценарию.

Объясните, что проверяется решение, а не способности участника. Попросите говорить, что он пытается сделать. Не демонстрируйте правильный путь до начала: после демонстрации вы проверите память на вашу инструкцию, а не самостоятельное понимание.

Наблюдайте и меняйте по конкретной причине

Записывайте действие, затруднение и его последствия. «Трижды открыл календарь, пытаясь найти отправку ссылки» полезнее, чем «неудобный интерфейс». Спросите после действия, чего человек ожидал, но не спорьте с его объяснением и не защищайте дизайн.

Разделите найденное на препятствия основной задаче, менее серьёзные затруднения и идеи на будущее. Сначала исправьте то, что не даёт получить результат. Не добавляйте каждую предложенную функцию: участник сообщает о своей ситуации, а решение о продукте требует сопоставления нескольких наблюдений и экономики.

После исправления повторите проверку. Сохраните номер версии, сценарий и найденные проблемы. Если участник уже видел старый вариант, учитывайте эффект знакомства; для проверки понятности с первого раза полезны новые люди с подходящей задачей.

Что прототип ещё не подтвердил

Успешное прохождение показывает, что конкретный путь оказался понятным в условиях проверки. Оно не доказывает готовность платить, техническую надёжность, скорость под нагрузкой или регулярное использование. Если участник говорит «я бы пользовался», предложите следующий реальный шаг проверки спроса, соответствующий готовности продукта.

Не выдавайте демонстрацию за работающий сервис. GOV.UK отдельно обращает внимание на ограничение доступа к опубликованным прототипам, чтобы их не приняли за действующую услугу. Для вашего проекта важно ясно обозначить демонстрационный характер и не принимать через неготовую схему реальные обязательства.

1. Прототип проверяет, понятен ли один путь в условиях наблюдения.
2. Он не доказывает готовность платить, надёжность, скорость под нагрузкой и регулярное использование.
3. Фраза «я бы пользовался» не заменяет следующий реальный шаг проверки спроса.
4. Демонстрацию не выдают за работающий сервис и не принимают через неё реальные обязательства.

Практическое задание

Выберите одну пользовательскую задачу, соберите только необходимые экраны и подготовьте нейтральное задание. Проведите несколько наблюдений с подходящими людьми, фиксируя конкретные действия. Итогом должны стать не общие оценки красоты, а решение: какой участок исправить, что проверить заново и какой вопрос уже требует настоящего продукта. Первое использование работающей версии разбирается в статье №251.