Если вы когда-нибудь занимались тестированием прототипов на респондентах, то наверняка замечали, что люди подсознательно сразу воспринимают прототип как готовый продукт и не «делают скидку» на все его условности. Опечатки, дублирование информации, шаблонный текст, тупиковые пути, долгая загрузка и прочие особенности прототипов отвлекают респондентов от реальных недостатков и могут восприниматься как ошибка интерфейса. Наверняка вы хотите не собирать отзывы об очевидных огрехах работы прототипа, а сосредоточиться на поиске возможных проблем при взаимодействии пользователей с конечным продуктом. А чтобы люди не отвлекались на косяки прототипов, нужно создавать их по некоторым правилам.
Создание сценария
Условно, алгоритм подготовки прототипа будет состоять из трёх этапов:
проработка успешных и неуспешных сценариев прототипа;
проверка элементов прототипа (кнопок, текстов, содержимого и др.);
предпросмотр прототипа.
Сценарии прототипа строятся вокруг сценария тестирования — последовательности вопросов и заданий, которую мы предлагаем респонденту. Поэтому сначала необходимо обозначить задачи и гипотезы исследования.
Основной пул задач исследования строится вокруг поиска скрытых причин и недостатков пользовательского опыта в продукте, которые могут привести к оттоку пользователей. Например, наша задача может звучать так:
— Понять, с какими трудностями сталкиваются пользователи при оформлении заказа в приложении.
Чтобы обнаружить те самые скрытые причины мы строим гипотезы, то есть предположения, сформулированные в менее общих понятиях. И здесь нам важно привязывать их к конкретным элементам интерфейса. Чтобы гипотезы помогали ответить на наши вопросы, они должны соответствовать ряду требований:
Гипотезу всегда можно либо подтвердить, либо опровергнуть.
Гипотеза всегда должна быть проверяемой и простой.
Гипотеза должна соответствовать методу исследования.
Мы предполагаем, что для генеральной совокупности гипотеза H0 верна, и формулируем её с частицей «не»: НЕпонятно, НЕочевидно, НЕзаметно. Например, гипотезы могут звучать так:
— Пользователям непонятно, как выбрать способ оплаты сертификатом.
— Пользователям непонятно, как оформить самовывоз.
— Пользователи испытывают сложности с заполнить форму заказа.
После того формулирования задач и гипотез мы определяем, действительно ли необходимо делать прототип. Что-то можно обсудить на примере конкурента или скриншота, или протестировать первым кликом. Например:
— Пользователи не могут перейти к оформлению заказа потому что кнопка «Корзина» незаметна.
Теперь превращаем гипотезы в задания, которые и будут составлять наш сценарий. Предположим, вы хотите протестировать интернет-магазин:
Гипотезы | Задания |
У команды есть подозрение, что при подборе товара пользователям неудобно пользоваться фильтром по цене. Кроме того, из статистики вы узнали, что часть людей «отваливаются» на оформлении заказа. А также неделю назад команда выкатила функцию сравнения товаров, и её тоже надо проверить. | Для теста нужны как минимум такие задания: 1) Подберите товар Х удобным способом. 2) Подберите товар Х не дороже 10 руб. 3) Выясните, какой из товаров Х или У обладает лучшими характеристиками. 4) Оформите заказ самовывозом рядом со станцией метро Кузнецкий мост. |
Требования к прототипу по сценарию
После написания сценария тестирования можно реализовать его в прототипе и проверить:
Продумайте контекст и точки входа в тестируемый сценарий. Без контекста респондент может чувствовать себя внезапно оказавшимся посреди шестиполосного шоссе с чашкой чая в руке: почему я здесь, как я здесь оказался, как отсюда уйти, и т.д. Чтобы избежать этой ситуации, а также протестировать точку начала взаимодействия с продуктом, рекомендуем продумать имитацию входа. Например, мы хотим проверить, как пользователь узнает, что нового происходит в продукте: можно просто отрисовать сценарий, начинающийся с экрана новостей, уведомлений или главной страницы в продукте, а можно начать сценарий с имитации пуша или приложения почты на главном экране или рабочем столе.
Все задания выполнимы. То есть, в прототипе нет блокирующих элементов, из-за которых целевое действие в принципе невозможно совершить.
Прототип должен содержать все элементы, разделы и страницы, которые требуется протестировать.
В том числе важно отобразить все граничные случаи, с которыми пользователь может столкнуться в рамках проверяемого сценария. Например, не нужно рисовать 404 страницу, но важно показать все снеки и, например, сообщения об ошибках, если пользователь заполнил не все поля.
Если сценарий предусматривает взаимодействие с пользователем не только в рамках интерфейса продукта, но и, например, с помощью писем, то эти экраны тоже надо внести в прототип.Отображайте максимальное количество пользовательских путей для «успешного» решения задачи. Это необходимо для того, чтобы зафиксировать наиболее приоритетный путь пользователей при выполнении задания, а также чтобы сравнить между собой главный и второстепенные пути, измерив показатели успешности, времени выполнения и удовлетворённости. Ещё это позволит избежать ошибки наведения на ответ. Однако тут надо искать компромисс между максимальной реалистичностью и тяжестью прототипа: если прорисовать все-все экраны, прототип будет долго открываться.
Отображайте «ошибочные» пути, по которым может пойти пользователь. Так проверяется наличие или отсутствие проблемы и исключается возможность того, что абсолютно все респонденты выполнят задание. Вместе с тем фиксируется, на каком этапе ошибочного пути респонденты заметят ошибку и найдут способы её решения. Здесь важно сделать НЕ все элементы активными, а те, которые вызывают сомнения либо являются развилочными.
В сценарии должен быть отработан не только линейный путь, но и возможность вернуться назад.
Проверка элементов прототипа (кнопки, тексты, контент и др)
Чаще всего* прототип не должен быть монохромным, и, по возможности, должен быть максимально приближен к будущему дизайну системы. В связи с тем, что отсутствие визуального оформления делает прототип менее похожим на конечный продукт, респонденты не могут пользоваться им так, как они привыкли в реальной жизни, что приводит к искажению результатов тестирования. Отсутствие визуальных акцентов на блоках и элементах приводит к тому, что респонденты вынуждены читать только текст. Такое поведение нетипично для пользователей, поэтому мы не рекомендуем тестировать чëрно-белые прототипы.
*Однако, в зависимости от задачи и контекста исследования, можно сделать упрощëнную версию. Например, вы нарисовали первую версию и хотите её проверить до того, как начали отрисовывать финальный дизайн.
Работа элементов в прототипе должна соответствовать реальной их работе на сайте или в приложении, или стремиться к этому, насколько это возможно.
Прототип не должен содержать шаблонного и прочего «рыбного» текста.
Если tone of voice продукта сам по себе не предполагает жаргонизмы, профессиональный слэнг и англицизмы, то их не должно быть в прототипе.
Любой текст, включая названия элементов, продуктов и услуг не должен содержать орфографических ошибок.
Если работа с прототипом предполагает ввод данных, необходимо сверить прототип с легендой, предложенной в сценарии тестирования.
Если тестируемая пользовательская задача содержит в себе заполнение форм или заявок, то поля для ввода данных должны быть активны и не должны быть предзаполнены. Однако для максимальной схожести с реальным взаимодействием поля должны заполняться по клику на них. Если поле ввода имеет функцию автоподстановки, подсказки или автоввода, следует отобразить эту возможность.
Если в прототипе используется элемент бегунок, не обязательно отображать максимальное количество его значений. Достаточно согласовать отображаемые значения со сценарием тестирования.
Прототип должен содержать релевантное разделам, страницам и категориям наполнение.
Прототип не должен содержать дублирующиеся товары, продукты или услуги, если это не предусмотрено в работе сайта или приложения.
Изображения и подписи должны быть релевантны друг другу. То есть к изображению слона не должно быть подписи, например, «Мышь».
Необходимо делать интерфейсы продуктов доступными для максимального количества людей. Поэтому нам важно, чтобы люди с ограниченными возможностями тоже могли пользоваться нашими сервисами:
Убедитесь, что пользователю не придëтся прикладывать усилия, чтобы прочитать текст на странице.
Убедитесь, что контраст между цветом текста и фоном достаточен. Проверить контрастность можно, например, здесь.
На сенсорных устройствах область нажатия должна быть достаточно большой и доступной. Особенно внимательно отнеситесь к работе с областью нажатия на устройствах с крупным экраном.
Предпросмотр прототипа
После того, как прототип проработан, нужно подготовить его к показу.
Figma
Проверьте, что по ссылке можно зайти незалогиненному пользователю. Бывает, что ссылка открывается у дизайнера, потому что он авторизован в Figma, а пользователи не могут открыть еë: проверять ссылку лучше в режиме инкогнито.
Уберите hotspots. Это нужно для того, чтобы подсвечивающиеся элементы не подсказывали респонденту кликабельные элементы и путь.
Если проводится немодерируемый тест, некликабельные элементы, с которыми, предположительно, могут взаимодействовать респонденты, должны иметь hotspot (включает в себя изменение формы курсора на тип «курсор-рука»).
Прототип должен соответствовать разрешению устройства, на котором планируется исследование. В Figma можно настроить растягивание под экран (fit to screen) или заполнение экрана (fill screen). Выбе нужную ширину, страницу и скопируйте для отправки ссылку из браузера — к ней добавится хвост из настроек (работает при просмотре из браузера) —
&scaling=scale-down-width&hotspot-hints=0&hide-ui=1(подогнать по ширине, скрыть подсказки, скрыть панель настроек).Отправьте ссылку, в которой нет панели настроек — только показ прототипа.
Убедитесь, что прототип загрузится на разных компьютерах и телефонах: помните, что у респондентов могут быть необновлëнные версии ПО и не самые актуальные модели гаджетов.
Figma Mirror
Если вы проверяете мобильное приложение или почему-либо ещë не должно быть видно окружения браузера, можно сделать прототип в приложении Figma Mirror.
Тогда респонденту нужно зайти в приложение под логином и паролем, выданным дизайнером. Такой прототип тяжелее ссылки, будут проблемы со связью. Может быть тут тоже подойдëт удалëнный доступ, нужно пробовать.
Предупреждения для респондентов:
Не нужно логиниться самим заранее.
Чëрный экран возникает из-за сложностей со связью, нужно подождать или нажать в любом месте экрана. Не нужно нажимать рестарт.
Invision
Если делаете самостоятельно, то можно воспользоваться Invision — регистрация бесплатная. Загрузите скрины интерфейса, разметьте кнопки и целевые экраны при переходах. Чтобы получить ссылку, нажмите меню «...» / Embed Prototype.
Чтобы скрыть подсказки кликабельных кнопок, при создании ссылки для отправки зайдите в настройки.
Самый важный пункт:
Проверьте, что все связи настроены корректно.
Прежде чем тестировать прототип на респондентах, проверьте его сначала на ком-то из команды, друзьях или родственниках.
Спасибо за участие в составлении чеклиста Юлии Кожуховой, Юлии Кингсеп, Марие Сушковой и всем дизайнерам, согласившимся дать обратную связь.
Екатерина Бессчётнова
Руководитель направления UX-исследований RuStore
