Как подготовить прототип к тестированию и доработать его по результатам

Теперь прототип нужен, чтобы проверить конкретное предположение о поведении человека.

Что может помешать

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

Короткое имя и круглая сумма подходят для примера, но не показывают, как экран работает с разными данными.

На прошлой ступени Lorem ipsum заменили реальными подписями. Теперь нужно подобрать данные, по которым участник сможет принимать решения. Добавьте не только короткие названия и небольшие суммы, но и длинные адреса, несколько товаров, пустые поля. Так будет легче заметить ограничения экрана.

Сравните две карточки заказа. В левой — короткие тексты и один товар, в правой — длинные данные, несколько позиций и другой статус.

Какие данные подготовить

Подготовьте состояния, которые нужны для выбранного сценария проверки.

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

Пять состояний для проверки

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

• Загрузка — что происходит и, если известно, сколько ждать.
• Пусто — что тут бывает и что сделать первым.
• Ошибка — что не удалось, что произошло с введёнными данными и как продолжить.
• Нет прав — почему не пускает и как пройти дальше.
• Успех — подтверждение, что действие выполнено. Без него человек может нажать кнопку повторно.

Подробность прототипа зависит от того, что вы хотите узнать.

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

С какими выводами стоит быть осторожнее

• Конверсия продукта. Если трое из трёх выполнили задачу, так и запишите. Это результат этих встреч, а не прогноз доли покупок после запуска.
• Скорость работы. Время в прототипе можно записывать, но учитывать условия: человек комментирует действия, впервые видит экран, сталкивается с ограничениями прототипа.
• Привычка. Одна встреча показывает первое знакомство с решением. По ней нельзя судить, как человек будет пользоваться им каждый день.
• Готовность платить. Нажатие «Оплатить» без реального списания не подтверждает, что человек купит товар.

Сначала сформулируйте вопрос и определите, какие наблюдения помогут на него ответить.

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

В нашем примере проверяем, понимают ли люди, что кнопка «Оформить заказ» сразу запускает оплату. Это поможет оценить вариант без отдельного экрана оплаты. Остальные наблюдения тоже запишем.

Что готовим, кроме прототипа

1. Легенда — одна-две фразы про ситуацию человека. «Вы выбрали кофемашину и хотите заказать её с доставкой на завтра». Без объяснения интерфейса.
2. Две-три задачи, сформулированные целью и без слов из интерфейса. «Сделайте так, чтобы заказ приехал завтра утром» — да. «Нажмите «К оплате»» — нет.
3. Стартовый экран — тот же, с которого человек начинает в жизни.
4. Знакомый участнику контекст, если он важен для задачи: например, город или привычный способ оплаты. Уточните его заранее.
5. Бланк наблюдений с колонкой «пришлось подсказать»: именно её вы сдаёте по итогам задания.
6. Трое участников не из команды, которым знакома задача покупки. В упражнении этого достаточно, чтобы потренироваться наблюдать и сопоставлять результаты. Выводы будут относиться к этим встречам.

ВОПРОС ПРОВЕРКИ (один, письменно, до встречи)
______________________________________________________________
как пойму ответ: ______________________________________________

ВСТУПЛЕНИЕ (пример, около минуты)
«Спасибо, что согласились помочь. Это черновой прототип,
часть действий в нём пока недоступна. Мы хотим понять,
насколько удобен интерфейс; ваши навыки здесь не оцениваются.
Пожалуйста, говорите, если что-то непонятно, и рассказывайте
вслух, что пытаетесь сделать и чего ожидаете.»

ЛЕГЕНДА
«______________________________________________________________»

ЗАДАЧИ (целью, без слов из интерфейса)
1. ______________________________________________________________
2. ______________________________________________________________

КАК ВЕСТИ ВСТРЕЧУ
— Не указывать нужную кнопку: «нажмите сюда», «она справа».
— Не оценивать действия словами «правильно» или «неправильно».
— Не объяснять устройство экрана до выполнения задачи.
— На вопрос «что дальше?» уточнить: «Что вы ожидаете сделать?»

БЛАНК                                   участник __ из 3, дата __.__
экран        | что сделал        | что сказал     | подсказал? | сек
_____________|___________________|________________|____________|____
_____________|___________________|________________|____________|____
_____________|___________________|________________|____________|____
_____________|___________________|________________|____________|____

ВОПРОСЫ НА ВЫХОД (после всех задач)
— «Что здесь было самым непонятным?»
— «Что, по-вашему, произошло, когда вы нажали последнюю кнопку?»
— «Если бы это был настоящий магазин, что бы вы сделали дальше?»

ИТОГ ПО УЧАСТНИКУ
дошёл до конца: да / нет      подсказок понадобилось: __
главная заминка: ______________________________________________

Записывайте действия, вопросы и подсказки: по ним будет проще восстановить, что произошло.

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

Что делать, когда человек застрял

1. Дайте время разобраться. Небольшая пауза позволяет увидеть, как человек ищет следующий шаг.
2. Спросите, а не подскажите: «О чём вы сейчас думаете?» или «А что бы вы сделали, если бы меня здесь не было?»
3. Если совсем тупик — подскажите минимально, чтобы продолжить, и сразу поставьте отметку в бланке. Дальше идёте по сценарию.
4. Не меняйте прототип во время выполнения задачи. Если он сломался, остановитесь и поясните, что это ограничение черновика. Запишите проблему и исправьте её перед следующей встречей.

Шесть наблюдений и возможные объяснения

Ниже — учебные примеры записей о двухшаговом оформлении. Раскройте каждый, чтобы сравнить наблюдение, его возможную причину и следующий шаг.

Как собрать результаты трёх встреч

Сведите наблюдения в одну таблицу для команды. Пишите «двое из трёх»: так виден размер проверки и меньше риска принять результат за статистику продукта.

После проверки определите, что нужно изменить в прототипе, в интерфейсе или в самой идее.

Перед правками разберите причины затруднений. Где прототип не передаёт задуманное поведение? Где нужно изменить интерфейс? Какие наблюдения ставят под вопрос саму идею? Это поможет выбрать следующий шаг.

Когда стоит пересмотреть саму идею

Иногда достаточно изменить подпись или расположение ссылки. Но если проверка ставит под сомнение основное предположение идеи, стоит вернуться к её цели. Обсудите, сохраняется ли польза после необходимых правок.

Как обсудить отказ от идеи

• Уже потрачено время. Сравните оставшуюся работу с тем, что теперь известно о решении. Затраты на прототип сами по себе не повод продолжать разработку.
• Отказ кажется неудачей. Проверка помогла заметить проблему раньше. Сохраните, что удалось узнать, и используйте это в следующем варианте.
• Команда рассчитывала на идею. Покажите наблюдения и предложите следующий шаг: «Все трое искали адрес на подтверждении. Предлагаю показывать его и оставить возможность изменения».

После переделки — короткая повторная проверка

Для упражнения пригласите одного-двух новых участников и дайте те же задачи. Посмотрите, возникает ли прежнее затруднение. В отчёте опишите наблюдение конкретно: «После правки оба участника верно объяснили, когда спишутся деньги».

Подготовьте прототип, проверьте его с тремя участниками и запишите затруднения, в том числе места, где понадобилась ваша помощь.

Часть 1 · Вопрос проверки, 15 минут

1. Сформулируйте один вопрос так, чтобы на него можно было ответить наблюдением, а не мнением.
2. Опишите признаки понимания: например, участник до нажатия верно объясняет, когда спишутся деньги. Запишите также, какие наблюдения покажут затруднение.
3. Выберите детализацию по таблице из раздела 4. Проверьте, что её хватит для вашей задачи.

Часть 2 · Данные и состояния, 1–2 часа

1. Заполните основной путь реалистичными данными: именами, суммами, адресами и статусами.
2. Сделайте один экран на самых неудобных данных: длинное имя, большая сумма, двенадцать позиций, пустое поле.
3. Пройдите свой тестовый сценарий и на каждом экране спросите: что если данных нет? что если долго? что если не сработало? что если гость?
4. Подготовьте недостающие состояния на основе основных экранов.
5. Пройдите прототип сами и проверьте все доступные кнопки. Для действий из задания настройте переходы, для остальных — заглушки с возвратом.

Часть 3 · Проверка на трёх людях, полдня

1. Возьмите скрипт и бланк из раздела 5, заполните легенду и задачи.
2. Пригласите троих не из команды, которым знакома задача. Проведите отдельные встречи по 20–30 минут.
3. Наблюдайте и уточняйте ожидания. Если пришлось подсказать действие, запишите это в бланке.
4. Исправляйте технические ошибки прототипа между встречами и отмечайте изменения. Для сравнения наблюдений оставьте само решение одинаковым у всех трёх участников. В Nielsen Norman Group черновик, наоборот, советуют править прямо между встречами, пока проблема очевидна: за три встречи так проверяют больше вариантов. Это другой способ — не сравнение, а доводка. Если выбираете его, записывайте, какую версию видел каждый участник.

Часть 4 · Свод и переделка, 2 часа

1. Сведите находки в таблицу: место, сколько человек споткнулось, подсказывали ли, что делаем.
2. Определите дальнейшие действия: исправить прототип, доработать интерфейс или пересмотреть идею. Наблюдения без ясного объяснения сохраните для уточнения.
3. Доработайте решение по наблюдениям до подробного оформления. Учитывайте последствия проблемы, её повторяемость и связь с задачей.
4. Проверьте правки с одним-двумя новыми участниками: посмотрите, осталось ли затруднение.

Что должно получиться

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

Для планирования отведите до полудня на данные и состояния, полдня на три встречи и около двух часов на разбор и правки. Время повторной проверки и поиск участников учтите отдельно.

Частые сложности

• «Прототип не сработал на первой встрече». Исправьте ошибки и проверьте переходы сами. Отметьте, какие задачи участник не смог выполнить из-за ограничений прототипа. При необходимости запланируйте дополнительную встречу.
• «Участник всё прошёл и похвалил интерфейс». Сопоставьте отзыв с наблюдениями: где он останавливался, что переспрашивал, нужна ли была помощь. Это разные части результата.
• «Не получается найти троих». Начните с доступных участников и прямо укажите размер проверки. Даже одна встреча может показать проблему, но не расскажет, насколько она распространена.
• «Команда хочет сначала оформить макет». Объясните, какой вопрос можно проверить на черновике и какое решение зависит от ответа. Договоритесь о времени на проверку.
• «Нашли двадцать проблем». Начните с тех, которые мешают выполнить задачу или могут привести к серьёзной ошибке. Повторяемость поможет расставить приоритеты, но единичную важную проблему тоже стоит разобрать.

Прототип готов к проверке, если

• Записан один вопрос проверки и способ понять ответ
• Данные реалистичны и подходят тестовым задачам
• Есть хотя бы один экран на самых неудобных данных
• Подготовлены состояния, необходимые для сценария проверки
• Есть подтверждение успеха — экран или явное изменение
• Каждая кнопка ведёт на экран, состояние или заглушку
• Всё, что участник тронет по сценарию, работает
• Уровень детализации не выше, чем нужно для вопроса
• Прототип открывается по ссылке и проходится без вас

После проверки у вас есть

• Записи трёх отдельных встреч с участниками, которым знакома задача
• Задания, сформулированные через цель без указания нужных кнопок
• Записи всех подсказок и мест, где они понадобились
• Наблюдения за поведением и отдельные записи отзывов
• Пометки о технических исправлениях между встречами
• Разбор причин затруднений и дальнейших действий
• Для задания — пример решения, доработанного до подробного оформления
• Результат повторной проверки после правок

Ошибки, характерные для этой ступени

• Подробное оформление слишком рано. На непроверенную структуру уходит время, а менять её после этого сложнее.
• Только короткие данные. По ним не видно, что происходит с длинными названиями, большими суммами и пустыми полями.
• Пропущенные состояния. Участник упирается в ограничение прототипа, и проверить задуманный путь не получается.
• Нет подтверждения результата. Человек может не понять, сработало ли действие, и повторить его.
• Лишняя детализация. На неё уходит время, хотя для текущего вопроса достаточно более простого прототипа.
• Вы выполняете задачу за участника. Так не видно, сможет ли он разобраться самостоятельно.
• Незаписанные подсказки. В отчёте выполнение с помощью может выглядеть как самостоятельное.
• Незаметная смена решения между встречами. Результаты разных версий трудно сопоставить, если изменения не отмечены.
• Правка без разбора причины. Сначала выясните, что помешало участнику и насколько важны последствия.
• Проценты вместо людей. «67 % не справились» на трёх людях — это «двое из трёх», и говорить надо так.
• Спор с участником. За объяснением своей идеи легко упустить его ожидания и затруднения.
• Разработка без учёта результатов. Команда продолжает работу, хотя главное предположение идеи осталось под вопросом.

На этой ступени важно уметь подготовить проверку и связать наблюдения с решением о дальнейшей работе.

• Не заставляйте меня думатьСтив Круг, 3-е издание · книга на русском · платнаяКак проверить прототип на троих своими силами: глава 9. В открытой версии главы (2000) — показывать людям даже бумажные наброски и давать задачи, которые человек выбирает сам: на придуманных задачах видно меньше.
• UX Prototypes: Low Fidelity vs. High FidelityNielsen Norman Group, Кара Перниче · на английском · бесплатноТри оси подробности прототипа — интерактивность, внешний вид, содержание — и что сказать, если участник нажал туда, где ничего нет. Статья 2016 года; спорит с уроком: советует править черновик прямо между встречами, а урок держит решение одинаковым для всех трёх участников.