Как стать автором
Обновить
VK
Технологии, которые объединяют

Чеклист для прототипов

Время на прочтение7 мин
Количество просмотров9.1K

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

Создание сценария

Условно, алгоритм подготовки прототипа будет состоять из трёх этапов: 

  • проработка успешных и неуспешных сценариев прототипа; 

  • проверка элементов прототипа (кнопок, текстов, содержимого и др.);

  • предпросмотр прототипа. 

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

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

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

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

  • Гипотезу всегда можно либо подтвердить, либо опровергнуть. 

  • Гипотеза всегда должна быть проверяемой и простой.

  • Гипотеза должна соответствовать методу исследования. 

Мы предполагаем, что для генеральной совокупности гипотеза H0 верна, и формулируем её с частицей «не»: НЕпонятно, НЕочевидно, НЕзаметно. Например, гипотезы могут звучать так:

Пользователям непонятно, как выбрать способ оплаты сертификатом.
Пользователям непонятно, как оформить самовывоз.
Пользователи испытывают сложности с заполнить форму заказа.

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

Пользователи не могут перейти к оформлению заказа потому что кнопка «Корзина» незаметна.

Теперь превращаем гипотезы в задания, которые и будут составлять наш сценарий. Предположим, вы хотите протестировать интернет-магазин: 

Гипотезы

Задания

У команды есть подозрение, что при подборе товара пользователям неудобно пользоваться фильтром по цене. Кроме того, из статистики вы узнали, что часть людей «отваливаются» на оформлении заказа. А также неделю назад команда выкатила функцию сравнения товаров, и её тоже надо проверить.

Для теста нужны как минимум такие задания:

1) Подберите товар Х удобным способом.

2) Подберите товар Х не дороже 10 руб.

3) Выясните, какой из товаров Х или У обладает лучшими характеристиками.

4) Оформите заказ самовывозом рядом со станцией метро Кузнецкий мост.

Требования к прототипу по сценарию

После написания сценария тестирования можно реализовать его в прототипе и проверить:

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

  2. Все задания выполнимы. То есть, в прототипе нет блокирующих элементов, из-за которых целевое действие в принципе невозможно совершить.

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

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

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

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

Проверка элементов прототипа (кнопки, тексты, контент и др) 

  1. Чаще всего* прототип не должен быть монохромным, и, по возможности, должен быть максимально приближен к будущему дизайну системы. В связи с тем, что отсутствие визуального оформления делает прототип менее похожим на конечный продукт, респонденты не могут пользоваться им так, как они привыкли в реальной жизни, что приводит к искажению результатов тестирования. Отсутствие визуальных акцентов на блоках и элементах приводит к тому, что респонденты вынуждены читать только текст. Такое поведение нетипично для пользователей, поэтому не рекомендуется тестировать чëрно-белые прототипы.

    *Однако, в зависимости от задачи и контекста исследования, можно сделать упрощëнную версию. Например, вы нарисовали первую версию и хотите её проверить до того, как начали отрисовывать финальный дизайн.

  2. Работа элементов в прототипе должна соответствовать реальной их работе на сайте или в приложении, или стремиться к этому, насколько это возможно.

  3. Прототип не должен содержать шаблонного и прочего «рыбного» текста.

  4. Если tone of voice продукта сам по себе не предполагает жаргонизмы, профессиональный слэнг и англицизмы, то их не должно быть в прототипе. 

  5. Любой текст, включая названия элементов, продуктов и услуг не должен содержать орфографических ошибок.

  6. Если работа с прототипом предполагает ввод данных, необходимо сверить прототип с легендой, предложенной в сценарии тестирования.

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

  1. Если в прототипе используется элемент бегунок, не обязательно отображать максимальное количество его значений. Достаточно согласовать отображаемые значения со сценарием тестирования.

  2. Прототип должен содержать релевантное разделам, страницам и категориям наполнение.

  1. Прототип не должен содержать дублирующиеся товары, продукты или услуги, если это не предусмотрено в работе сайта или приложения. 

  2. Изображения и подписи должны быть релевантны друг другу. То есть к изображению слона не должно быть подписи, например, «Мышь».

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

  • Убедитесь, что пользователю не придëтся прикладывать усилия, чтобы прочитать текст на странице.

  • Убедитесь, что контраст между цветом текста и фоном достаточен. Проверить контрастность можно, например, здесь

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

Предпросмотр прототипа

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

Figma

  1. Проверьте, что по ссылке можно зайти незалогиненному пользователю. Бывает, что ссылка открывается у дизайнера, потому что он авторизован в Figma, а пользователи не могут открыть еë: проверять ссылку лучше в режиме инкогнито.

  2. Уберите hotspots. Это нужно для того, чтобы подсвечивающиеся элементы не подсказывали респонденту кликабельные элементы и путь.

  3. Если проводится немодерируемый тест, некликабельные элементы, с которыми, предположительно, могут взаимодействовать респонденты, должны иметь hotspot (включает в себя изменение формы курсора на тип «курсор-рука»).

  4. Прототип должен соответствовать разрешению устройства, на котором планируется исследование. В Figma можно настроить растягивание под экран (fit to screen) или заполнение экрана (fill screen). Выберите нужную ширину,  страницу и скопируйте для отправки ссылку из браузера — к ней добавится хвост из настроек (работает при просмотре из браузера) — &scaling=scale-down-width&hotspot-hints=0&hide-ui=1 (подогнать по ширине, скрыть подсказки, скрыть панель настроек). 

  5. Отправьте ссылку, в которой нет панели настроек — только показ прототипа. 

  1. Убедитесь, что прототип загрузится на разных компьютерах и телефонах: помните, что у респондентов могут быть необновлëнные версии ПО и не самые актуальные модели гаджетов.

Figma Mirror

  1. Если вы проверяете мобильное приложение или почему-либо ещë не должно быть видно окружения браузера, можно сделать прототип в приложении Figma Mirror.

  2. Тогда респонденту нужно зайти в приложение под логином и паролем, выданным дизайнером. Такой прототип тяжелее ссылки, будут проблемы со связью. Может быть тут тоже подойдëт удалëнный доступ, нужно пробовать.

  3. Предупреждения для респондентов:

Не нужно логиниться самим заранее. 

Чëрный экран возникает из-за сложностей со связью, нужно подождать или нажать в любом месте экрана. Не нужно нажимать рестарт. 

Invision

  1. Если делаете самостоятельно, то можно воспользоваться Invision — регистрация бесплатная. Загрузите скрины интерфейса, разметьте кнопки и целевые экраны при переходах. Чтобы получить ссылку, нажмите меню «...» / Embed Prototype. 

  2. Чтобы скрыть подсказки кликабельных кнопок, при создании ссылки для отправки зайдите в настройки. 

Самый важный пункт:

  • Проверьте, что все связи настроены корректно.

  • Прежде чем тестировать прототип на респондентах, проверьте его сначала на ком-то из команды, друзьях или родственниках.

Спасибо за участие в составлении чеклиста Юлии Кожуховой, Юлии Кингсеп, Марии Сушковой, Сергею Розуму и всем дизайнерам, согласившимся дать обратную связь.

Екатерина Бессчётнова

Руководитель направления UX-исследований RuStore

Теги:
Хабы:
Всего голосов 32: ↑32 и ↓0+32
Комментарии0

Публикации

Информация

Сайт
team.vk.company
Дата регистрации
Дата основания
Численность
свыше 10 000 человек
Местоположение
Россия