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