Пользовательские сценарии тестирование это

Денис Нарижный, руководитель интернет-агентства «Студия F1» и создатель сервиса юзабилити-тестирования сайтов AskUsers.ru, рассказал Нетологии о том, как составлять и использовать пользовательские сценарии.

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

Прежде чем разработать сценарий, нужно ответить на три вопроса:

1. Кто те люди, что заходят на ваш сайт?

Нужно выделить чёткий сегмент аудитории и проработать портрет клиента, под которого готовится сценарий.

2. Почему они заходят к вам?

На основе аналитики или опроса можно определить, зачем на самом деле пользователи посещают ваш сайт: просто посмотреть, что-то узнать или купить.

3. Какие цели при этом преследуют и как их достигают?

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

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

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

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

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

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

Это самый насыщенный подробностями вариант: рассказ, схемы, видео, фотографии — все, что помогает описать опыт взаимодействия, иногда даже без привязки к персоне клиента. У каждого пользователя может быть своя история и свой специфический опыт. Это сбор сырой информации.

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

Запишите простые человеческие истории: «Через месяц у нас юбилей свадьбы, я отложил деньги и собираюсь выбрать подарок жене. У меня есть предел по стоимости, я знаю, что жена любит серебро и носит серьги…».

Вот пример из серии скринкастов: пользователь пытается сделать покупку в интернет-магазине:

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

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

Составляются уже с позиции персонажа (персоны покупателя). Еще меньше абстракции и больше конкретики. Каждой группе ЦА сопоставляется персонаж, далее прописывается его путь достижения цели.

Могут добавляться ограничения: например, проработка только варианта заказа с планшета или со смартфона.

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

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

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

«Общение» пользователя и терминала по приему платежей:

Еще сценарий от uxforthemasses.com:

Работа над User flow, пользовательским сценарием — важный этап создания интерфейса. User flow принимает различные формы в зависимости от этапа развития продукта. Расскажу, как тестировать сценарии в разных ситуациях и как это можно делать бесплатно. Пригодится людям, задействованным в создании интерфейсов: UI дизайнерам, менеджерам продуктов, UX исследователям.

Что такое User flow и почему сценарий важнее всего

User Flow — пользовательский сценарий иллюстрирует порядок действий, который пользователь выполняет для решения задачи. Сценарий — это скелет интерфейса, состоит из шагов — отдельных экранов. Удобный для пользователя интерфейс начинается именно с проработки user flow, структуры.

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

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

Задаем вопросы: общая оценка user flow готового продукта

Тестировании User Flow продукта — это гигиеническая норма. Для оценки общего уровня удобства важны количественные метрики. Подход к сбору данных зависит от исследовательской культуры и возможностей.

Для проверки сценариев достаточно провести онлайн опрос. Даем респондентам ссылку на продукт и задание. По итогу прохождения задаем вопросы из стандартной анкеты по оценке юзабилити (SUS). Полезно наравне с собственным продуктом тестировать прямых и косвенных конкурентов. В разнице оценок и содержится наиболее полезная информация.

Пример: летом 2019 года провели сравнительное исследование трех онлайн супермаркетов. За несколько часов получили общие метрики по удобству интерфейса, а из открытых ответов почерпнули информацию о разрывах в пользовательском сценарии.

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

Наблюдаем за действиями: поиск проблемы в User Flow готового продукта

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

Удаленное немодерируемое юзабилити тестирование

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

Модерируемое юзабилити тестирование

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

Фиксируем клики: тест User Flow на этапе разработки

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

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

Пример: я тестировал пользовательский сценарий по поиску дверной ручки на сайте строительного гипермаркета. На втором шаге сценария, при попадании в каталог 71% ищут дверные ручки в разделе двери и окна. И лишь 6% в скобяных изделиях, где они и находятся. Вывод: интерфейс не решает задачу для сценария по поиску этого товара.

Выводы

Если задача — общая оценка то из исследований наиболее релевантен опрос с применением классической шкалы SUS или ее разновидностей.

Если на этапе готового продукта ищем проблему в User Flow, то в зависимости от требуемой детализации и ресурсов используем немодерируемое или модерируемое юзабилити тестирование.

На этапе разработки, когда user flow представлен в виде последовательных экранов рекомендую тест первого клика — он покажет, на каком шаге люди теряются, поможет при размещении кнопок.

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

Пользовательские сценарии (сценарии использования)

К отдельному подвиду последовательных наборов тест-кейсов можно отнести пользовательские сценарии, представляющие собой цепочки действий, выполняемых пользователем в определённой ситуации для достижения определённой цели.

Допустим, пользователь хочет распечатать табличку на дверь кабинета с текстом «Идёт работа, не стучать!»

Для этого ему нужно:

• Запустить текстовый редактор.
• Создать новый документ (если редактор не делает это самостоятельно).
• Набрать в документе текст.
• Отформатировать текст должным образом.
• Отправить документ на печать.
• Сохранить документ (спорно, но допустим
• Закрыть текстовый редактор.

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

Сценарии могут быть достаточно длинными и сложными, могут содержать внутри себя циклы и условные ветвления, но при всём этом они обладают рядом весьма интересных преимуществ:

• Сценарии показывают реальные и понятные примеры использования продукта (в отличие от обширных чек-листов, где смысл отдельных пунктов может теряться).
• Сценарии понятны конечным пользователям и хорошо подходят для обсуждения и совместного улучшения.
• Сценарии и их части легче оценивать с точки зрения важности, чем отдельные пункты (особенно низкоуровневых) требований.
• Сценарии отлично показывают недоработки в требованиях (если становится непонятно, что делать в том или ином пункте сценария, — с требованиями явно что-то не то).
• В предельном случае (нехватка времени и прочие форс-мажоры) сценарии можно даже не прописывать подробно, а просто именовать — и само наименование уже подскажет опытному специалисту, что делать.

Последний пункт проиллюстрируем на примере.

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

На этой стадии можно представить отличия в логике работы с приложением, например, «консервативного» и «отчаянного» пользователей.

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

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

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

Антон Ульяненков, аналитик Playtestix

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

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

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

Хорошо знать игру и четко понимать цели и задачи пользовательского тестирования; понимать, какой инструментарий проекта какие задачи решает. Расписанное “разделение труда” между методиками сбора фидбека на выходе дает более качественную информацию. Например, в анкете мы спрашиваем, какой режим игры понравился игроку больше всего, и получаем на выходе количественную оценку предпочтений. Наблюдение за игровой сессией поможет нам увидеть, как часто игрок играл в тот или иной режим, насколько он был успешен в каждом из них. В интервью мы просим игрока озвучить мотивы, по которым он выбрал тот или иной режим в качестве более привлекательного.

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

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

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

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

Подумайте над тем, как формируется опыт у игрока в вашей игре, и, в зависимости от этого, определите, когда лучше задать тот или иной вопрос. Начинайте с тестирования рекламных материалов, определите, какие ожидания они формируют. Обязательно спросите игрока о его первых впечатлениях — оправдались ли ожидания, удалось ли разобраться с основами управления, целями игры. Дальнейшие этапы зависят от специфики конкретного проекта. Важно не переутомить игрока слишком длинными игровыми сессиями, максимум — 2 часа. Задавайте основной объем вопросов после игровой сессии; старайтесь, чтобы промежуточные блоки анкеты/интервью содержали лишь наиболее актуальные вопросы.

После того, как вы определились со сценарием, разработали инструментарий (анкеты, бланки наблюдений и интервью), нашли представителей целевой аудитории, можно преступать непосредственно к проведению плейтеста. В следующей статье поговорим о данном этапе подробнее.

Если вы нашли опечатку — выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.

• Что такое юзкейс
• Из чего состоит
• Как написать
• Пример
• Диаграммы
• Польза для команды

Что такое юзкейс

Use case (также юзкейс, сценарий использования) – это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.

Юзкейсы содержат следующие сведения:

• кто использует сайт или приложение
• что пользователь хочет сделать
• цель пользователя
• шаги, которые делает пользователь, чтобы совершить определенное действие
• описание того, как сайт или приложение реагируют на действия пользователя.

Юзкейсы не содержат детали реализации, а также описания пользовательского интерфейса или экранов.

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

В отличие от user story, которая излагается от имени какого-то конкретного пользователя, в use case может быть описано взаимодействие (с определенной целью) нескольких участников. Например:

• покупка товара в магазине (Покупатель – Продавец);
• отправка письма по электронной почте (Отправитель – Почтовый клиент);
• запрос страницы браузером (браузер – веб-сервер).

Элементы use case

Юзкейсы могут содержать следующие элементы (их количество зависит от сложности сценария):

• Актор (actor) — тот, кто использует систему. Если взять за пример онлайн-магазин, там может быть несколько акторов: покупатели, продавцы, компании, занимающиеся доставкой, компании, проводящие платежи.
• Стейкхолдер (stakeholder) — тот, кто заинтересован в определенном поведении системы. Зачастую это не конечный пользователь, а кто-то, получающий выгоду от функционирования системы. В случае с онлайн-магазином это может быть партнер — платежная платформа.
• Первичное действующее лицо (primary actor) — человек или система, чьи цели достигаются при помощи нашего продукта. В онлайн-магазине это может быть основной дистрибьютор, чьи товары продаются на этой онлайн-платформе.
• Предусловия и постусловия — что должно быть в наличии или должно произойти до и после запуска сценария использования.
• Триггеры — события, запускающие юзкейс.
• Успешный сценарий — юзкейс, при котором все идет по плану, без ошибок и неожиданностей.
• Альтернативные пути — вариации основного успешного сценария на случай, если что-то пойдет не так на уровне системы.

Как написать use case?

Шаги в юзкейсе описываются максимально понятно. Что касается самих шагов, они могут быть следующими:

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

Пример use case

В этом юзкейсе изложен сценарий входа пользователя в школьную систему.

Юзкейс-диаграммы

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

Пример диаграммы для юзкейсов входа в школьную систему:

Зачем нужны use case?

Давайте рассмотрим, в чем ценность юзкейсов для участников проекта разработки ПО.

1. Заказчики

В юзкейсе отражается конечная бизнес-ценность, понятная заказчику. Реализация сценария использования в системе очевидна даже для нетехнического специалиста. Наличие готового use case позволяет заказчику своевременно дать старт дальнейшей работе тестировщиков и разработчиков.

1. Разработчики

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

1. Тестировщики

Юзкейсы — отличная основа для формирования тест-кейсов. Это, по сути, пригодные для тестирования требования с понятной целью и путями ее достижения. Тестирование по сценариям использования (use case testing) позволяет обнаружить в приложении недостатки,  которые сложно найти, например, при юнит-тестировании.