Как протестировать интерактивный прототип? Опыт UXCrowd в вопросах и ответах

Все знают, что тестировать прототипы надо, чтобы найти и исправить юзабилити-проблемы до того, как начнется разработка. Многие пытаются внедрить процесс тестирования в своих компаниях. Но знаний о том, как это делается, в открытых источниках мало. Мы решили это исправить — и в этой статье поделимся практическим опытом, который получили, тестируя прототипы нашего собственного сервиса UXCrowd и сервисов наших клиентов

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

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

Мы в UXCrowd часто проводим тестирования именно с этой целью. Бывали случаи, когда после тестирования мы отказывались от внедрения новой функции, потому что оказывалось, что пользователи не понимают саму идею, которую мы хотели воплотить.

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

Мы, как и большинство наших клиентов, используем два инструмента: Invision и Figma, у каждого есть свои преимущества и недостатки.

Figma — наверное, самый часто используемый инструмент. Его любят за удобство использования, богатую функциональность и возможность коллаборации. Но интерактивные прототипы, созданные в Figma, могут медленно загружаться (30-50 секунд), особенно на старых смартфонах. Это сильно раздражает респондентов, а если вы проводите немодерируемое тестирование, респондент может просто не дождаться загрузки и уйти.

Чтобы прототипы, созданные на Figma, работали быстрее, на одной странице Figma нужно располагать макеты экранов только для одной функции. Когда вы разрабатываете сложную систему со множеством функций, возникает соблазн расположить все макеты на одной странице, чтобы они все были перед глазами. Это ошибка. Такие прототипы оказываются слишком тяжелыми и медленно грузятся, а еще с ними неудобно работать команде. Чем меньше экранов расположено на одной странице Figma — тем лучше.

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

Чтобы выбрать инструмент для создания прототипа, нужно понимать, что вы будете тестировать, зачем, и какой это будет тест, модерируемый или нет. Если система будет большая и сложная — возможно, Invision подойдет лучше, так как работает быстрее. Но при тестировании мобильных прототипов, созданных в Invision, могут быть проблемы со свайпами.

Распространенная ошибка при подготовке к тестированию прототипа — сначала готовить интерактивный прототип, а потом писать сценарий тестирования. После написания сценариев выясняется, что в прототипе не хватает экранов, не прописаны необходимые состояния и события. В результате приходится дорабатывать прототип, а на это уходит время.

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

1. Подготовить минимально необходимое количество статичных макетов, которые будут иллюстрировать вашу новую функцию.
2. Определить цели тестирования — от этого зависит, какие задания вы будете давать пользователю и насколько интерактивным и детальным должен быть прототип.
3. Написать сценарий тестирования: сформулировать задачи, которые будет выполнять пользователь, определить критерии успешности их выполнения.
4. Прописать шаги, которые будет проходить пользователь, выполняя задачу. Возможно, у задачи есть несколько путей решения — это нужно учесть при создании макета: вы хотите протестировать все из них или только один? На этом же этапе нужно решить, что вы будете делать, если пользователь отклонится от сценария и нажмет «не туда» — прорисовывать экраны? Делать заглушку?
5. Подготовить макеты с учетом всех шагов и состояний, которые вы определили на предыдущем шаге.
6. Добавить в макеты реалистичные тексты. Дизайнеры интерфейсов, как правило, забивают в макеты «рыбный» текст, не имеющий особого смысла. Для того, чтобы понять, как текст будет выглядеть в интерфейсе, этого достаточно — но для тестирования это не подойдет, потому что интерфейс должен выглядеть реалистично.
7. Добавить признаки кликабельности на те элементы, нажатие на которые не предусмотрено сценарием — это необходимо чтобы они выглядели интерактивными. Если этого не сделать, пользователь сразу увидит, на какие элементы он должен нажать, чтобы пройти сценарий — и это лишит тестирование смысла.
8. Проверить, что прототип адекватно отображается в разных браузерах. Если окажется, что в каком-либо браузере есть проблемы с отображением, в инструкции для респондента нужно будет обозначить рекомендацию воспользоваться тем браузером, в котором проблем нет.
9. Провести пилотную сессию тестирования. Она нужна, чтобы найти не юзабилити-проблемы, а недостатки сценария тестирования и недоработки прототипа с точки зрения этого сценария. Вам нужно проверить, все ли вы учли: все необходимые тексты прописаны, действия системы продуманы, отклонения от сценария предусмотрены и т.п. По результатам пилота нужно доработать макеты или сценарии — и только после этого можно приступать к тестированию.

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

Формулировать задания нужно так же, как если бы вы тестировали «настоящую» систему. Частая ошибка, которую мы встречали — показать респонденту макет и попросить его оценить или же показать два макета и спросить, какой нравится больше. Так вы не узнаете, содержит ли ваш макет какие-нибудь юзабилити-проблемы, насколько он удобен для пользователей. Нужно просить респондента решить ту же задачу, которую он выполнял бы в этом интерфейсе в реальной жизни: пройти регистрацию, найти товар и положить в корзину, оформить профиль, найти информацию об условиях сервиса и т.п.

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

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

Действительно принципиальные отличия — это количество респондентов и фиксация юзабилити-метрик.

При тестировании прототипов важно быстро найти критичные проблемы и быстро их исправить. Поэтому к этому типу исследования хорошо подходит методология RITE (Rapid Iterative Testing and Evaluation): вы проводите тестирование на 2-3 респондентах, исправляете обнаруженные проблемы, затем проводите следующую итерацию и так далее, пока несколько пользователей подряд не смогут пройти сценарий без существенных затруднений.

«Живую» систему обычно тестируют, чтобы получить исчерпывающую информацию о ее юзабилити-проблемах: сколько пользователей с ними сталкиваются, сколько времени тратят на выполнение заданий, насколько пользователи в целом удовлетворены взаимодействием с системой. В одном исследовании принимают участие минимум 5–8 человек, при этом сначала проходят все сессии тестирования, и только затем делаются выводы о юзабилити-проблемах и необходимых улучшениях. Методология RITE при тестировании «живой» системы обычно не применяется.

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

Технически проводить немодерируемые тестирования прототипов возможно — и наш сервис, UXCrowd, позволяет это делать. Но этот метод подходит не для каждого продукта.

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

Также без участия модератора проходят first-click тесты. Они тоже отлично подходят для тестирования прототипов, не требуют такой сложной подготовки, как классические юзабилити-тестирования, но и сфера применения у них сильно ограничена. При помощи first-click теста вы не сможете исследовать весь сценарий в прототипе — только проверить гипотезы о том, какое первое действие респондент будет делать, чтобы выполнить определенную задачу.

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

Часто от тестирования прототипов отказываются, потому что на это нет времени: макет уже готов, спецификация есть, разработчики готовы приступать к внедрению, и в текущий спринт (если вы работаете по методологии Agile) тестирование точно не влезет.

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

Пишите вопросы в комментариях, в Facebook или в UXCrowd