О чем речь? Пользовательский сценарий — описание поведения потребителя на сайте или в приложении. На его основе вносятся изменения, призванные упростить взаимодействие клиентов с продуктом компании.
На что обратить внимание? Сценарий бывает разных видов: от краткой истории до юзеркейса. Его создание состоит из нескольких этапов. В работе используют специальные инструменты. Главное — не допустить в ходе создания описания распространенные ошибки.
В этой статье:
- Понятие и задачи пользовательского сценария
- Виды пользовательских сценариев
- Этапы создания пользовательского сценария
- Команда для создания пользовательского сценария в дизайне
- Инструменты для разработки пользовательских сценариев
- Использование пользовательского сценария на практике
- Ошибки при создании пользовательского сценария
- Часто задаваемые вопросы о пользовательском сценарии
-
Чек-лист: Как добиваться своих целей в переговорах с клиентамиСкачать бесплатно
Понятие и задачи пользовательского сценария
Пользовательский сценарий (User Scenario) — это, по сути, набор действий, необходимый юзеру сайта или покупателю приложения, чтобы достичь желаемой цели.
Пользовательские сценарии включают в себя:
-
тип и характеристику клиента;
-
мотивацию пользователя;
-
состояния и условия, в которых пребывает потребитель;
-
прочие нюансы.
Помимо этого, пользовательский сценарий сайта или приложения может содержать дополнительный набор сведений, позволяющий уточнить пожелания к продукту. Благодаря ему целевую аудиторию (ЦА) можно разделить на группы ключевых персон, обладающих собственными мотивами и ситуациями взаимодействия с продуктом.
Источник: shutterstock.com
К примеру, представители студенческой среды не проводят весь день напролет за ПК, для них будет актуальнее мобильная версия сайта. А вот офисные работники в будни предпочтут десктоп-вариант.
За счет пользовательских сценариев можно найти решение сразу по нескольким задачам:
-
Лучшее понимание потребителей. Знание сценариев дает представление разработчикам о том, как именно происходит взаимодействие пользователей с продуктом. Оно дает увидеть результаты работы глазами потребителя. Качество подготовки сценариев особенно важно при изучении удобства использования сайта или приложения.
-
Выстраивание продуктивной коммуникации внутри команды и презентация продукта. Когда дизайн уже разработан, сценарии помогут продемонстрировать визуально пошаговое взаимодействие с сайтом или приложением. Они дают возможность придерживаться изначально выбранного плана и выбирать элементы интерфейса для потребителей определенного продукта.
Читайте также!
Виды пользовательских сценариев
Их классифицируют по-разному. Самое распространенное деление выглядит так:
-
Пользовательские истории.
-
Концептуальные сценарии.
-
Конкретные сценарии.
-
Варианты применения.
Их разработка эффективна для решения задач бизнеса только при соблюдении указанной последовательности. Рассмотрим каждую группу подробнее.
Пользовательские истории (User Stories)
Включают в себя сценарную базу, мини-резюме о запросе потребителя в отношении определенного продукта. Таких историй может быть огромное количество — зависит от числа товаров и групп ЦА. У каждой узкой группы пользователей свои User Stories, отличные друг от друга. Пишутся пользовательские истории от первого лица.
Пример User Stories пользовательского сценария: Я женщина, у меня трое детей и работа, и нет времени на походы в магазины и ТЦ. Близится новогодний корпоратив, и необходимо создать вечерний образ. Для этого я воспользуюсь онлайн-магазином, на другие варианты нет времени и сил. В интернет-площадке мне важны: удобство каталога, широкий ассортимент вечерних платьев разной длины. А лучше с указанием повода — на Новый год, корпоратив, день рождения и т. д.
Для каждого платья нужна понятная таблица размеров. Важны выбор времени доставки, возможность заказать варианты, чтобы курьер все привез и забрал то, что не подошло. И удобство расчета тоже значимо — лучше, если я смогу примерить все платья без предоплаты.
Концептуальные сценарии (Conceptual Scenarios)
Готовые User Stories группируют в Conceptual Scenarios. Похожие сценарии поведения объединяют по общим признакам, убирая все лишнее, максимально упрощая. Разработчики фокусируются на наборе действий условного юзера, не вдаваясь в технические нюансы. Здесь они описываются от третьего лица.
Например: Человек не располагает лишним временем на посещение торговых точек офлайн, отдавая предпочтение маркетплейсам для повседневных покупок. Пользуется фильтрами, планирует размер финансовых затрат в отношении предстоящей сделки. Он проводит сравнение ассортимента нескольких торговых площадок, учитывает сервис, параметры доставки и удобство оплаты. Окончательный выбор зависит от наиболее подходящих для покупки условий.
Конкретные сценарии (Concrete Scenarios)
Уточнение сценария в данном случае предполагает более подробное техническое описание путей к заданным целям. Прописываются и имеющиеся ограничения. К примеру, конкретный сценарий может содержать перечень действий пользователя, производящего оформление заказа на сайте (в мобильной или десктоп-версии), в приложении. Конкретный сценарий также предполагает описание от третьего лица.
Источник: shutterstock.com
Пример: Заказ оформляется через сайт в мобильной версии. Девушка готова заказать вечернее платье для новогоднего корпоратива. Она изучила таблицу размеров, подобрала два варианта нарядов, ознакомилась с отзывами покупателей. Прочитала об условиях доставки — с 8 до 24 часов по любому адресу, доступна оплата при примерке.
Покупательнице некогда включать компьютер и заполнять формы, а потому важно оформить заказ на смартфоне. Оплату удобнее осуществить с банковской карты. Подходящее время доставки — 23:30, когда дети легли спать и можно спокойно все примерить и выбрать подходящее. Для девушки важно, чтобы заказ был привезен именно к этому времени.
Подобные конкретные сценарии составляются под каждую из покупательских групп и целевые действия в отдельности.
Сценарии применения (User Case)
Юзеркейсы подразумевает поэтапное последовательное описание взаимодействий пользователя и системы с технической точки зрения. Это выглядит как набор действий, выстроенных по ходу движения клиента к желаемому результату. Здесь нет места лирике, личным нюансам покупателя — акцент на функционале сайта и его эффективности в решаемых задачах.
Пример: Заказ праздничного платья.
-
Участник — зарегистрированный пользователь.
-
Условие — открыта карточка товара в мобильной версии сайта.
-
Действия пользователя по основному сценарию:
-
Открывает каталог «Вечерние платья».
-
Устанавливает фильтры — длина, цвет, материал, цена, повод.
-
Открывает карточку товара.
-
Изучает размерную сетку.
-
Читает отзывы.
-
Откладывает товар в корзину.
-
Заполняет форму для доставки.
-
Выбирает способ оплаты — картой при получении.
-
Оформляет заказ.
-
Читает уведомление «Заказ создан».
-
Заказ отправлен продавцу на обработку.
Эти сценарии эффективны в планировании архитектуры сайтов и дизайне интерфейсов. Их также могут использовать при тестировании пользовательских путей на ресурсе.
Читайте также!
Этапы создания пользовательского сценария
-
Шаг 1. Составьте портрет клиента.
Проанализируйте ЦА: что нужно этим людям, каковы их мотивы и поведение. Так вы получите представление о задачах, которые они будут решать при помощи вашего продукта.
Для создания пользовательского сценария опишите пользователя — сделайте следующее: Сформируйте персону клиента — портрет типичного покупателя продукта, состоящий из его социальных данных, параметров психографики, поведенческих особенностей и потребностей, запросов. Она важна для понимания пользователя: кто он, чего хочет и как мыслит. Рассмотрим пример персоны юзера приложения доставки продуктов питания и готовой еды:
-
Имя: Валерия.
-
Возраст: 26 лет.
-
Профессия: маркетолог.
-
Хобби: медитация, книги, путешествия.
-
Цель: заказать доставку еды на ужин.
-
Потребность: поужинать с минимальным вложением времении денег.
-
Проблема: дефицит средств и сил на приготовление еды, трудности с выбором из многочисленных предложений.
-
Мотивация: удобно и быстро получить вкусную и здоровую пищу.
-
Ожидание: интуитивный интерфейс приложения, возможность выбора из множества ресторанов и широкий ассортимент блюд, хорошее качество обслуживания и невысокая стоимость доставки.
Теперь нужно понять сценарий использования товара, то есть описать ситуацию, где продукт помогает персоне решить ее задачу. Это может быть так: Рабочий день Валерии в офисе длится с 9 до 18 часов. Сегодня она пришла домой позже, чем обычно, и не успевает приготовить ужин. Валерия хочет решить этот вопрос при помощи оформления доставки в мобильном приложении. Открыв приложение, она ищет что-то сытное, но легкое из ресторанов, находящихся вблизи дома.
-
Шаг 2. Выявите пользовательские цели и согласуйте их с целями продукта.
Важно иметь четкое представление о том, как соотносятся потребности клиента с тем, чего вы бы хотели достичь при помощи сайта/приложения. В этом полезны, например, диаграмма Венна или матрица приоритизации. Они помогут визуально оформить соотношение целей продукта и пользователя.
Бизнесмены пользуются матрицей приоритизации как аналитическим инструментом для разных бизнес-процессов. Предметом изучения могут быть проекты или задачи любой сложности. Исходя из критериев оценки приоритетов, формы матрицы приоритизации различны: модель Кано, матрица Эйзенхауэра, метод RICE и др.
Источник: shutterstock.com
Диаграмма Венна позволяет увидеть все доступные варианты логических отношений между какими-либо несколькими группами чего-то/кого-то. Внешне она выглядит как пересекающиеся круги, представляющие собой группу объектов с общим свойством (например, пользовательские или цели компании). Инструмент помогает визуально представить взаимосвязь приоритетов продукта и пользовательских. И выявить общие либо индивидуальные цели для каждой из групп.
Далее необходимо сформулировать для User Flow измеримые и конкретные приоритеты. Исходя из этого можно будет определить, какую именно задачу вы хотели бы решить при помощи User Flow. Выберите конкретную достижимую цель, она должна быть измерима, релевантна и иметь ограничения по времени (SMART).
-
Шаг 3. Определите точки входа.
Обзаведитесь аналитикой каналов продаж — как пользователи выходят на ваш продукт или приложение. Здесь могут сыграть главную роль реклама, работа поисковика, социальные сети, реферальные рассылки, СМС, письма на электронную почту или другой вариант продвижения. Каждый из этих источников приводят пользователя в разные «уголки» сайта — поисковая система отправит его на главную страницу ресурса, а электронное письмо — сразу в корзину товаров.
Для четкого понимания точек входа необходимо дать ответ на вопрос «Как потребитель узнает о вашем продукте и как он приобретает его?» К примеру, при проектировании User Flow для регистрации пользователя в приложении ею может стать первый экран после установки программы либо ссылка на главный экран, открытая в качестве приглашения от другого клиента.
Нелишним будет выяснить способы поиска продуктов из вашей ниши и то, какие факторы выбора точки входа могут сработать. Для этого можно опрашивать пользователей, проводить интервью или наблюдение. Проанализировав полученные данные, сделайте выбор самых удобных, понятных и привлекательных для клиента начальных пунктов.
-
Шаг 4. Продумайте пути от точек входа до мест выхода.
Создайте диаграмму, где отразите пошагово весь пользовательский путь в приложении/продукте, используя простые информационные блоки, жесты и элементы интерфейса. Типы графиков могут быть разными, исходя из нужной степени детализации и этапа дизайнерского процесса.
Существуют ключевые способы отражения User Flow: Mind Map (ментальная карта) и Wire Flow.
Mind Map представляет собой схему пути пользователя, которая состоит из простых фигур. Внешне ментальная карта напоминает паутину или дерево, в центре которого находится главная тема (продукт), а его ветви — вторичные темы либо подфункции. Как правило, в изображении User Flow выбирают такие фигуры из общепринятого стандарта условных обозначений BPMN, как:
-
круг и эллипс — начало или конец главного пути и подпутей внутри приложения;
-
стрелка — указывает направление движения пользователя;
-
прямоугольник — какой-то процесс, к примеру, «просмотр меню» или «добавление товара в корзину»;
-
ромб — условие «если..., то…», например, «если пользователь прошел авторизацию, то…» или «если клиент оформил заказ, то…».
Wire Flow — схема, которая состоит из экранов или страниц приложения с минимальными дизайнерскими составляющими — так называемых вайрфреймов. Она способствует более тщательному и логичному подходу к разработке структуры интерфейса продукта, позволяет выделить главные функции и составляющие на каждом экране.
-
Шаг 5. Получите обратную связь, улучшите и завершите User Flow.
Проверьте удобство и результативность своего потока, оценив пользовательский сценарий в тестировании с реальными клиентами либо экспертами. Методы могут быть разные: A/B-тест, когнитивное моделирование, юзабилити-тестирование. Результаты анализа обратной связи помогут подстроить схему под запросы пользователя, не отходя от заданной для продукта цели.
Команда для создания пользовательского сценария в дизайне
Над этим обычно трудится целая группа, состоящая из координатора (менеджера проекта) и UX- и UI-разработчиков. Могут также быть привлечены тестировщики — это специалисты по контролю качества (QA, Quality Assurance), знающие каждый кейс и любое условие (позитивное/негативное) с позиции пользователя. Они помогут сделать сценарии более точными.
Источник: shutterstock.com
Прежде чем сделать продукт доступным широкому кругу пользователей, необходимо убедиться в его готовности и понять все возможные уязвимые места, чтобы своевременно внести соответствующие коррективы. Тестировщики — ваши первые клиенты, которым необходимо дать максимум сведений о продукте и предоставить как можно больше возможных сценариев.
Этот шаг особенно важен, ведь ваш продукт попадет в руки большого числа людей. И вам будет полезно знать все возможные варианты того, как он будет использован. Любой член команды должен осознавать важность пользовательского сценария, ведь именно с его помощью можно прийти к лучшему решению задачи с учетом интересов обеих сторон.
Каждому участвующему в разработке необходимо поставить себя на место пользователя. И потребитель этот может быть разным, ведь множество людей получат доступ к продукту. Когда все вживутся в свои роли, пора перейти к следующим шагам:
-
Изучите своих клиентов, их потребности и привычки.
-
Начните пользоваться продуктом всеми доступными способами. Станьте тем самым пользователем, который зашел на ваш сайт или установил приложение.
-
Разделите процесс на части. Например, создайте пользовательские сценариидля случаев авторизации в системе и для оплаты товаров или добавления их в корзину.
-
Проработайте каждый из них в позитивном и негативном ключе. Например, попытка авторизации. Позитивный вариант: пользователь ввел логин и пароль и вошел в личный кабинет. Негативный: клиент забыл логин и не смог попасть в систему.
-
Продумайте как можно больше вариантов неудачного исхода — так вы сможете их предугадать и что-то с этим сделать.
-
Подключите к работе всю команду. Пусть все коллеги вместе составят список возможных сценариев и завершат их, используя продукт. Чем больше точек зрения — тем лучше для дальнейшего совершенствования конечного варианта.
-
Создайте карту сценариев. Это документ, где будут собраны все они, так вы сможете избежать повторений. Такая карта даст возможность отследить все имеющиеся сценарии и отмечать уже проработанные.
-
Подумайте о том, как упростить путь пользователя по обозначенному вами сценарию. Можно воспользоваться Experrto — это платформа для адаптации юзеров к интерфейсу и взаимодействию с продуктом. Индивидуальная настройка визуальных интерактивных подсказок Experrto позволяет так выстроить онбординг, чтобы пользователь мог достичь своей цели на сайте максимально удобно и легко пройти весь сценарий.
Дизайн пути пользователя начинается с проработки базового варианта. Затем приглашаются QA-специалисты для его детального анализа. Эти этапы повторяются до тех пор, пока не получится завершенный пользовательский сценарий — после этого можно делать следующие шаги разработки. Необходимо убедиться, что вы следуете всем пунктам указанного ранее алгоритма, особое внимание уделяя негативным кейсам.
Инструменты для разработки пользовательских сценариев
В этой деятельности применяют массу разных инструментов, отличающихся по сложности, способам использования и доступному функционалу. Приведем наиболее популярные из них:
Инструмент | Описание | Основные возможности | Для кого подходит |
Google Docs | Доступное и несложное решение для текстового описания. Есть возможность совместного редактирования документа в режиме реального времени | Создание, редактирование текста. Совместная работа с документом. Комментарии, рецензии | UX-дизайнеры и продукт-менеджеры |
Excel/Google Sheets | Для структурированного описания шагов в виде таблицы. В основном для небольших проектов | Упорядочение данных по шагам. Создание таблиц с описанием целей, задач и действий пользователей | Те, кому предпочтительнее работать в таблицах |
Figma | Дизайнерский инструмент, подходящий также для визуализации с созданием прототипов | Визуализация. Создание интерактивных прототипов. Командная работа | UX/UI-дизайнеры |
Sketch | Схожий с Figma инструмент дизайнеров интерфейсов с возможностью визуализации | Проектирование интерфейсов и визуализация | UX/UI-дизайнеры, работающие в экосистеме macOS |
UXPressia | Специализированный инструмент для построения карт пути с визуализацией | Построение карт пути. Визуализация основных этапов | Продуктовые менеджеры, UX-дизайнеры |
Lucidchart | Инструмент в формате онлайн-сервиса для создания диаграмм, схем, карт, отлично подходящий для визуализации сложных проектов | Визуализация шагов в виде диаграмм. Командная работа. Интеграция с прочими сервисами (Slack,Google) | Команды, которым важна визуализация в сложных проектах |
Miro | Виртуальное пространство в формате «доски» для совместной работы, которая может быть полезна для проведения мозговых штурмов | Визуализация пользовательских путей. Мозговые штурмы. Совместная работа в реальном времени | Креативные команды, предпочитающие гибкий формат работы |
Axure | Инструмент для профессиональной работы по прототипированию | Проектирование интерактивных прототипов. Детализация | Профессиональные UX-дизайнеры, работающие над сложными проектами |
FlowMapp | Специализированный инструмент для формирования карт сайта | Создание карт сайта. Визуализация UX-структуры | UX-дизайнеры, работающие с архитектурой сайта |
Canva | Простое и доступное для новичков решение для визуализации | Построение визуальных карт, простых прототипов. Интуитивный интерфейс | Начинающие UX-дизайнеры, небольшие команды |
Приведенный перечень инструментов позволяет командам не только дать текстовое описание пользовательских сценариев, но и визуализировать их — так процесс UX-проектирования становится на порядок эффективнее.
Использование пользовательского сценария на практике
Приведем пример эффективного их применения для понимания поведения клиента и в дизайне приложения/сайта. В ходе исследования можно говорить о нескольких сценариях сразу, которые содержат одну или несколько функций в приложениях.
Соберите дискуссионную группу
Помимо организации пространства и необходимых ресурсов нужно сформировать команду для обсуждения, примерно из пяти участников. Это оптимальное число для эффективной работы без лишних временных затрат на общение. В группу можно включить дизайнеров, тестировщиков, UX-исследователей и разработчиков проекта.
Представьте цель сценария
Обозначить ее необходимо в самом начале встречи. Важно донести цель до каждого из собравшихся для результативности процесса.
Начните с первого UX-сценария
Ведущий встречи (куратор) выбирает его для обсуждения и связанную с ним персону.
Например:
Персона: Анна, студентка, 27 лет. Обладает непринужденным вкусом, предпочитает приобретать вещи в Интернете, чтобы иметь возможность широкого выбора без лишних затрат времени.
Цель: приобрести оригинальный подарок для подруги по приемлемой цене.
Визуализируйте шаги UX
Воспользуйтесь стикерами для заметок, напишите на них шаги, которые необходимо пройти пользователю, чтобы достичь цели. Под каждым из пунктов добавляйте комментарии.
Например:
Групповые комментарии на этапе, такие как отзывы или впечатления предыдущих клиентов. Вопросы и предположения, касающиеся этапа и его функций, например отображение продуктов и их месторасположение на странице.
Идеи, замечания и предложения, которые могут сделать шаг более удобным и полезным.
После того, как пункты выполнены, информация размещается на доске и фотографируется. Так результаты работы с пользовательским сценарием станут доступны для других членов команды, менеджеров и руководителей, которые не смогли присутствовать на встрече, но заинтересованы в ее исходе.
Читайте также!
Повторяйте, пока не закончите
Разрабатывайте сценарии под любые цели разных персонажей, пока не охватите все возможные варианты функций. Одного обсуждения может оказаться недостаточно, для охвата всех возможных приоритетов может понадобиться организовать другие встречи.
Получите обратную связь
По завершении работы участники могут дать развернутые отзывы, направленные на улучшение взаимодействия пользователя с продуктом или одной из его версий. Некоторое время спустя после получения обратной связи можно организовать еще одну встречу, чтобы проработать отклики и внести необходимые изменения в сценарий. Окончательную его версию можно передавать дизайнерам, разработчикам для дальнейшего воплощения идей.
Ошибки при создании пользовательского сценария
Создание пользовательских сценариев — это важный этап в разработке программного обеспечения, который требует внимательности и тщательного подхода. Однако, несмотря на его значимость, многие разработчики сталкиваются с распространёнными ошибками, которые могут негативно сказаться на конечном результате. Рассмотрим частые ошибки при создании пользовательского сценария.
Слишком длинный
Излишне объемный сценарий чреват потерей важных сведений о потребностях пользователя или его ожидаемых действиях. Если в нем часто встречаются формулировки с «который», «и» и «или», стоит задуматься о его сокращении.
Кроме того, есть вероятность, что сценарий приобрел эпик-формат (настолько крупный, что его разработка требует разделения на более маленькие части).
Источник: shutterstock.com
Пример длинного сценария: «Как пользователь, я бы хотел вернуться к статье позже, по дороге домой. При этом мне не хотелось бы проходить регистрацию и искать место, где остановился». Если вчитаться, станет ясно, что пользователю важны два аспекта (цели) — не фиксировать новый вход и не искать, где прекратил чтение. Не стоит усложнять сценарий, разделите его на два.
После разбивки он будет выглядеть следующим образом:
-
«Как пользователь, я хочу вернуться к чтению статьи по дороге домой без необходимости проходить регистрацию».
-
«Как посетитель, я хочу возобновить чтение с того места, где остановился, без необходимости искать его повторно».
Слишком детализированный
Чрезмерный объем элементов в пользовательском сценарии влечет массу лишних рассуждений. Пользователь уходит на второй план, а разработчикам станет трудно представить итог.
Вот пример излишне детализированного сценария: «Спроектируйте структуру масштабируемой реляционной базы данных, чтобы в дальнейшем с её помощью мне была бы доступна реализация любого возможного решения».
Сложно говорить о бизнес-ценности качественной реляционной БД, когда конечный клиент не может её использовать. К тому же, этот сценарий составлен с позиций дела, а не пользователя. Когда в сценарий включены аспекты реализации, интересы последнего уходят на вторые роли.
Бескомпромиссный
Пользовательские сценарии могут меняться, они не подразумевают точного, строгого описания функционала.
Приведем пример бескомпромиссного сценария: «Как пользователя, я хотел бы на панели уведомлений иметь кнопку «Очистить всё», чтобы можно было удалить старые уведомления».
Ясно, что цель посетителя — возможность убирать уже ненужные известия. Эта задача решается при помощи кнопки «Очистить всё», но она может быть достигнута и автоудалением уведомлений после их прочтения.
Если ваша команда считает, что реализовать пользовательский сценарий так, как описано, слишком сложно, и есть более простая альтернатива — вероятно, условия заданы слишком жёстко. Желательно прийти к компромиссу, в котором выгоды пользователя также будут учтены.
Совпадает с критериями приемлемости
Нередко пользовательские сценарии — это те же критерии приемлемости, только иначе сформулированные. Как это тогда выглядит?
Сценарий: «Как пользователь, я хочу дополнить мой блог всплывающими окнами, чтобы предложить посетителю оставить свой e-mail до того, как он покинет сайт».
Критерий приемлемости: «В тот момент, когда посетитель пытается уйти с веб-ресурса, должна всплыть форма с советом подписки».
Критерии приемлемости определяют условия, при выполнении которых пользовательский сценарий можно считать завершённым. Они предполагают сбор обратной связи с целью дальнейшего планирования работы команды. Так сценарий совершенствуется и становится проще для тестирования. И команда приходит к единому видению конечной цели разработки.
Вот еще пример:
Сценарий: «Я, и, чтобы всегда быть в курсе происходящего, хотел бы получать уведомления о новых комментариях других пользователей».
Критерий приемлемости: «Если приложение открыто, когда я работаю с документом, счётчик на иконке с колокольчиком должен обновляться, отражая число непрочитанных уведомлений».
Пользователь не определён
Упоминание персоны вновь и вновь в каждом из сценариев может показаться странным. Однако для результата разработки это может быть чрезвычайно важно. Особенное значение это имеет, когда продукт предполагает более одного пользователя. Разумеется, разные персоны требуют свой набор функций. Для единого понимания целей всей командой важно, чтобы разработчики «видели» каждого конечного пользователя и его выгоды от функционала.
Все вышеописанные примеры наглядно демонстрируют, как делать не надо. Но не стоит переживать — мы это сделали специально, чтобы теперь всё объяснить.
Источник: shutterstock.com
Начало пользовательского сценария с фраз «Как пользователь», «Как посетитель», «Как читатель», вносит неясность. Необходимый для эффективной работы команды контекст возможен только с четким определением персоны пользователя.
Советуем вместо применения слов «пользователь/посетитель/читатель» описывать персону. Тогда ваш пользовательский сценарий должен будет выглядеть приблизительно так: «Как автор, я хотел бы не обновляя страницы получать уведомления о новых комментариях читателей в Google Docs».
Недостаточный контекст
Увы, многие приходят к тому, что пишут сценарии ради них самих. На определенном этапе они все могут казаться одинаковыми.
К примеру, «Я контент-менеджер, и мне нужен текстовый редактор, чтобы править материал».
Это скажет вашим разработчикам только то, что им необходимо создать такое ПО, и все. Если вы перегружены обилием сценариев, составленных в последнее время, стоит на время сделать паузу, вернуться к работе с ними позже. Но порой даже перерыв не дает выхода к более осмысленному и ясному решению. В таком случае стоит подумать о более тесном общении с пользователями для лучшего понимания их запроса. Насильно выдавить из себя ответ не получится.

Часто задаваемые вопросы о пользовательском сценарии
Пользовательские сценарии — это один из главных инструментов оптимизации взаимодействия пользователей с продуктом, помогающий глубже понять их поведение и запросы.
В чем главное преимущество?
Снижение объема затрат на разработку: создание пользовательских сценариев позволяет выявить потенциальные проблемы и недостатки продукта на ранних этапах, предотвращая затраты на их исправление в дальнейшем.
Какой вид выбрать?
Чем труднее взаимодействие, тем предпочтительнее начинать с контекста, специфики поведения, продвигаясь к конкретике по решениям. Иначе рискуете вложить 80 % усилий в 20 % сценариев, которые будут редко возникать на деле, а внимание дизайнера будет рассредоточено на все возможные варианты, что негативно отразится на их качестве.
На каком этапе продукта нужны сценарии?
На любом. Этот полезный инструмент и на стадии запуска, и для внесения изменений в уже работающий продукт. Он эффективен и когда его нужно презентовать, например, инвесторам.
Они дают возможность разработки удобного и привлекательного интерфейса продукта. И помогают улучшить его функционал в целом. Анализ и построение сценариев — ценное звено в разработке продукта, будь то мобильное приложение, сайт или любое другое цифровое решение.