Нужен ли интерактивный прототип для тестирования с пользователями
Что проверяют
Понимаете ли вы, зачем вообще тестируют с пользователями, и умеете ли считать стоимость проверки. Для фронтендера вопрос практический: иногда дешевле собрать кликабельный макет, иногда быстрее написать черновую версию на реальном коде и не делать одну и ту же работу дважды.
Как отвечать
От гипотезы, которую проверяем:
- понятность потока, формулировки, порядок шагов: хватает кликабельного прототипа в дизайн-инструменте, он собирается за часы и его не жалко выбросить;
- ощущение скорости, поведение на слабой сети, ввод с клавиатуры, длинные списки и реальные данные: прототип тут врёт, нужен работающий код хотя бы на моках;
- доступность, работа со скринридером, поведение на телефоне: только реализация;
- если функцию всё равно решили делать, черновая версия под флагом часто дешевле прототипа: её показывают части пользователей и она остаётся в кодовой базе.
Полезно добавить, как вы участвуете в тесте: смотреть запись сессии информативнее пересказа, а задание формулируется как цель пользователя, не как инструкция по нажатию кнопок.
Где спотыкаются
Считают прототип обязательным всегда. Для мелкой правки формы подготовка теста стоит дороже самой правки, и разумнее выкатить изменение на часть аудитории и посмотреть на поведение.
Второе: тестируют макет и делают выводы о производительности и удобстве ввода. В кликабельном прототипе нет ни задержек, ни валидации, ни экранной клавиатуры, и человек ведёт себя не так, как в реальном продукте.
Третье: подсказывают во время сессии. Вопрос «вы же видите кнопку сохранения?» обнуляет результат, а потом команда годами защищает решение ссылкой на такой тест.