Пользовательский сценарий что это
Пользовательские сценарии: что это такое, как и для чего их нужно строить
Денис Нарижный, руководитель интернет-агентства «Студия F1» и создатель сервиса юзабилити-тестирования сайтов AskUsers.ru, рассказал Нетологии о том, как составлять и использовать пользовательские сценарии.
Сценарии описывают пользовательские истории и взаимосвязи между ними. Они помогают определить, зачем и почему пользователи приходят на сайт и как достигают своих целей: совершают покупки, заказывают по телефону, сравнивают товары, общаются с консультантами.
Прежде чем разработать сценарий, нужно ответить на три вопроса:
1. Кто те люди, что заходят на ваш сайт?
Нужно выделить чёткий сегмент аудитории и проработать портрет клиента, под которого готовится сценарий.
2. Почему они заходят к вам?
На основе аналитики или опроса можно определить, зачем на самом деле пользователи посещают ваш сайт: просто посмотреть, что-то узнать или купить.
3. Какие цели при этом преследуют и как их достигают?
Вариантов не так много, особенно если мы говорим о коммерческих сайтах. Обычные цели — изучить предложение с целью сравнить его с другими, непосредственно купить или сделать заказ, но возможны и другие варианты.
Пошагово достижение целей обычно расписывается в профилях задач. Здесь такая детализация не нужна, просто нужно понимать, какие шаги делает пользователь для достижения цели.
Для чего нужны пользовательские сценарии
Сценарии помогают лучше понимать предпочтения посетителей сайта и анализировать пользовательский опыт. Это нужно, чтобы в дальнейшем проектировать сайт или интерфейс так, чтобы он вписывался в привычные для клиентов паттерны и приводил к цели посещения за наименьшее количество шагов и с минимальными затратами сил, времени и внимания.
Также сценарии используют для анализа пользовательского опыта при проведении юзабилити-тестов и других маркетинговых исследований.
Сценарий — наглядное схематическое представление того, как пользователь решает свою задачу с помощью сайта, что ему помогает и что мешает в достижении цели.
Разновидности сценариев
Пользовательские сценарии по степени детализации и технической проработки делятся на четыре группы.
1. Пользовательские истории
Это самый насыщенный подробностями вариант: рассказ, схемы, видео, фотографии — все, что помогает описать опыт взаимодействия, иногда даже без привязки к персоне клиента. У каждого пользователя может быть своя история и свой специфический опыт. Это сбор сырой информации.
Если мы говорим о покупке: кто-то берет для себя, а кто-то в подарок, кто-то подарит маме, а другой — жене. У кого-то все хорошо с финансами, кто-то собирал деньги на покупку, кого-то интересует кредит и рассрочка. Опыт в этих пользовательских историях будет отличаться.
Запишите простые человеческие истории: «Через месяц у нас юбилей свадьбы, я отложил деньги и собираюсь выбрать подарок жене. У меня есть предел по стоимости, я знаю, что жена любит серебро и носит серьги…».
Вот пример из серии скринкастов: пользователь пытается сделать покупку в интернет-магазине:
Пользовательские сценарии: что это, как и для чего их нужно строить
Как сделать сайт удобным для пользователей.
Пользовательские сценарии рассказывают об историях и образах покупателей, взаимосвязях между юзерами и позитивным клиентским опытом. Благодаря сценариям можно понять, почему люди попадают на сайт и как достигают своих целей: совершают покупки, делают заказ по телефону, сравнивают товары, разговаривают с консультантами.
Как разработать пользовательский сценарий для вашего продукта — разбираемся.
Что такое пользовательские сценарии
Пользовательский сценарий (User Scenario) — это схема, которая позволяет определить, почему покупатели оказываются на сайте и как реализуют свои планы с помощью вашего продукта.
Чаще всего такие сценарии создаются в формате коротких рассказов о некоем эталонном пользователе, цель которого — удовлетворить свою потребность посредством вашего сайта или приложения.
Чтобы создать сценарий, необходимо сфокусироваться на образе вашего пользователя. Кто он? Какой у него характер, бэкграунд, зачем он пришел на веб-ресурс? Как будет вести себя на сайте, с какой страницы начнет, на что будет нажимать? Продумать все вероятные линии поведения клиента невозможно — поэтому пользовательские сценарии, как правило, учитывают образы и мотивации юзеров, которые часто встречаются в определенной сфере.
Важно! Сценарии пишутся до этапа техработ по созданию сайта/приложения, они сфокусированы на действиях и потребностях пользователей. Техническим нюансам (стекам, инструментам, интерфейсу) в этом процессе места нет.
Зачем нужны пользовательские сценарии?
Хотите получать дайджест статей?
Важно! Сценарий описывает текущую ситуацию. Но уже в процессе его создания у вас возникнут идеи, которые позволят улучшить юзабилити продукта — упростить, добавить новые функции или подсказки.
Какими бывают пользовательские сценарии
Самая популярная классификация пользовательских сценариев принадлежит Дэвиду Беньону, Сьюзан и Филу Тернерам, авторам учебника по взаимодействию компьютера и человека (HCI — human-computer interaction).
Визуализировать это разделение можно так:
Чтобы проработать в пользовательском сценарии все важные для покупателя моменты, необходимо пройти все 4 этапа, от создания истории — до кейса.
#1. Пользовательские истории
Пользовательские истории (User Stories) — база для сценариев. Это синопсис, краткое содержание «легенды» юзера и его потребностей относительно вашего продукта.
Отличительные черты пользовательских историй:
Директор по маркетингу
Татьяна Лукинюк,
B2C-директор в Kyivstar
Татьяна Лукинюк,
B2C-директор в Kyivstar
Разберем все 4 этапа на примерах пользовательских сценариев для создания сайта маркетплейса.
Пример: На этой неделе коллега пригласила меня на юбилей. Я ее почти не знаю, но другие сотрудники посоветовали подарить ей что-нибудь для дома — набор текстиля или посуды. Мне сложно выбрать, поскольку я слабо ориентируюсь в этих вещах и переживаю, что могу купить дорогой подарок плохого качества или даже бесполезный.
Хорошо бы получить совет от кого-нибудь, кто в этом разбирается. А то я не знаю, на что ориентироваться, кроме цветов. Это должен быть интернет-магазин с большим количеством отзывов на товары и либо с точкой выдачи недалеко от работы, либо с доставкой домой в вечернее время. Кроме того, нужна оплата картой, потому что я не хочу возиться с наличкой.
Было бы неплохо, если бы сразу в магазине могли красиво упаковать подарок и мне не пришлось бы тратить время еще и на это.
#2. Концептуальные сценарии
Несколько историй и характеров потенциальных покупателей объединяются в один концептуальный сценарий. Conceptual Scenarios создаются на основе пользовательских историй путем упрощения. Все малозначительное отбрасывается, похожие «легенды» объединяются в одну. Финальное описание практически полностью лишено технических подробностей.
Этот этап необходим для генерации идей и выявления ключевых требований. Когда в процессе обсуждения концепта возникает определенная система, с которой взаимодействует юзер, идея перерастает в конкретный сценарий.
Пример: Пользователь заранее планирует бюджет на покупку, ищет товар через поиск, сразу применяет фильтры, несколько дней принимает решение, сомневается и сравнивает продукты в корзине. Затем оставляет заказ, выбрав наиболее подходящий вариант оплаты и способ доставки.
«Правило 20 секунд»: почему пользователи покидают ваш сайт
#3. Конкретные сценарии
На этапе создания конкретного сценария важно сегментировать аудиторию, для каждой из категорий прописать персонажа — и уже исходя из усредненных характеристик ЦА обрисовать путь достижения цели. В этот блок работы можно также включить ограничения: например, пользователь делает заказ с ПК, мобильной версии сайта или из приложения.
Concrete Scenarios уже включают в себя детали реализации проекта и технические подробности. Конкретные сценарии пишутся от третьего лица.
Пример: Добавляем ограничение — заказ будет сделан через мобильную версию сайта.
Клиент Х хочет приобрести покрывало в подарок коллеге на этой неделе. Бренд должен быть «проверенным» (т. е. его качество подтверждают отзывы других покупателей и фильтр популярности). Необходимо, чтобы у товара была красивая упаковка, чтобы впечатлить коллегу во время поздравления.
Клиент Х выбирает покрывало с телефона, стоя в пробке по дороге домой и параллельно отвлекаясь на другие дела. Ему точно не хочется заполнять слишком много полей. Оплатить заказ лучше через Apple Pay на сайте, поскольку он почти не носит с собой наличку.
Определившись с подарком, клиент выберет праздничную упаковку и доставку после 20:00. Ему важно, чтобы товар привезли точно в указанное время, поскольку он приедет домой в 19:45, а в 20.30 отправится на встречу.
Весь бизнес-контент в удобном формате. Интервью, кейсы, лайфхаки корп. мира — в нашем телеграм-канале. Присоединяйтесь!
Чтобы проработать весь процесс взаимодействия покупателя с сайтом, важно создать нескольких персонажей, продумать для каждого из них историю, концепт и конкретный сценарий. После этого конкретные сценарии объединяют по главному признаку — в нашем примере это заказ через мобильную версию сайта. Конечный вариант, который получился после такой интеграции, называется сценарием применения или кейсом.
#4. Сценарии применения
Пример или кейс применения (Use Case) — пошаговое описание взаимодействий пользователей и системы. Это технический план, в фокусе которого находятся функции, а не чувства и мысли юзера, некий список деталей контактов человека с системой. Действующее лицо уже не персонаж, а абстрактная усредненная пользовательская роль — новый юзер, администратор магазина, зарегистрированный клиент.
На этом этапе следует описать user experience по шагам: кто, что, как и в какой последовательности делает.
Пользовательские истории и концептуальные сценарии нужны для понимания основных мотивов юзеров и погружения в мир клиента. Конкретные сценарии и варианты применения уже могут использоваться для проектирования информационной архитектуры, интерфейсов, а также при проведении тестов и исследований юзабилити.
Сценарий использования
Сценарий использования, вариант использования, прецедент или же пользовательский сценарий (англ. Use Case) — в разработке программного обеспечения и системном проектировании это описание поведения системы, которым она отвечает на внешние запросы. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рассматриваемой системой. Методика сценариев использования применяется для выявления требований к поведению системы, известных также как функциональные требования.
В системном проектировании сценарии использования применяются на более высоком уровне чем в при разработке программного обеспечения, часто представляя цели заинтересованных лиц или миссии. На стадии анализа требований сценарии использования могут быть преобразованы в ряд детальных требований и задокументированы с помощью диаграмм требований SysML или других подобных механизмов.
Содержание
История
В 1986 году Ивар Якобсон, позже соавтор Унифицированного Языка Моделирования (UML) и Рационального Унифицированного Процесса (RUP), впервые сформулировал методику визуального моделирования для описания сценариев использования. Первоначально он использовал несколько иные термины — англ. usage scenarios и usage case, но ни один из них не был естественным для английского языка. И в конечном счете он остановился на термине use case — сценарий использования. После создания Якобсоном методики моделирования сценариев использования многие люди поспособствовали улучшению этой методики, включая Курта Биттнера, Алистера Кокберна, Ганнэра Овергарда, и Джери Шнайдера.
В течение 1990-ых сценарии использования стали одной из самых распространенных методик документирования функциональных требований, особенно в объектно-ориентированной среде, откуда они и произошли. Но их применение не ограничивается объектно-ориентированными системами, поскольку сценарии использования не объектно-ориентированы по природе.
Цели сценариев использования
«Каждый сценарий использования сосредотачивается на описании того, как достигнуть цели или задачи. Для большинства программных проектов это означает, что потребуется множество сценариев использования чтобы определить необходимый набор свойств новой системы. Степень формальности программного проекта и его стадии будет влиять на необходимый уровень детализации, для каждого сценария использования.»
Сценарии использования не должны путаться с понятием свойств системы (англ. Feature ). Сценарий использования может быть связан с одним или более свойством системы, и свойство может быть связано с одним или более сценарием использования.
Сценарий использования определяет взаимодействия между внешними агентами и системой, направленные на достижение цели. Актер (англ. Actor ) представляет собой роль, которую играет человек или вещь, взаимодействуя с системой. Тот же самый человек, использующий систему, может быть представлен как различные актеры, потому что они играют различные роли. Например, «Джек» может играть роль Клиента использующего Банкомат, чтобы забрать наличные деньги, или играть роль Работника Банка, использующего систему для пополнения банкомата купюрами.
Сценарии использования рассматривают систему как «черный ящик», и взаимодействия с системой, включая системные ответы, описываются с точки зрения внешнего наблюдателя. Это — преднамеренная политика, потому что это вынуждает автора сосредоточиться на том, что система должна сделать, а не, как это должно быть сделано, и позволяет избегать создания предположений о том, как функциональные возможности будут реализованы.
Сценарии использования могут быть описаны на абстрактном уровне (деловой сценарий использования, иногда называемый ключевым сценарием использования), или на системном уровне (системный сценарий использования). Различия между ними — в деталях.
Сценарий использования должен:
Уровень детализации
Алистер Кокберн в книге «Написание эффективных сценариев использования» выделил три уровня детализации сценариев использования:
Подходящая детализация
Некоторым процессам разработки программного обеспечения достаточно простого сценария использования для определения требований системы. Другим необходимо много детализированных сценариев использования. В общем случае чем больше и сложнее проект, тем более вероятно, что будет необходимо использовать много детализированных сценариев.
Уровень деталей в сценарии использования часто зависит от стадии проекта. Начальные сценарии могут быть краткими, но в процессе развития проекта они становятся более детальными. Это отражает различные требования к сценариям использования. Первоначально они должны только быть краткими, так как они применяются для получения общих деловых требований с точки зрения пользователей. Однако, позже в процессе создания системы разработчики нуждаются в намного более определенном и детальном руководстве.
Рациональный Унифицированный Процесс (RUP) стимулирует разработчиков использовать краткое описание сценариев использования в диаграмме сценариев использования с обычным уровнем детализации в виде комментария и детальным описанием в текстовом анализе. Сценарии могут быть задокументированы с помощью специальных инструментов (например, UML Tool, SysML Tool), или написаны в обычном текстовом редакторе.
Нотация сценариев использования
В Унифицированном языке моделирования отношениях между всеми или частью сценариев использования и актерами представлены в виде диаграммы сценария использования или диаграммах, первоначально основанных на объектной записи Ивара Якобсона. SysML использует то же самое представление на системном уровне.
На диаграммах сценариев использования в UML сценариев отображается в виде эллипса. Внутри эллипса или под ним указывается имя элемента.
К сценариям использования в UML применимы следующие виды отношений:
В том числе между прецедентами:
Сценарии использования и процесс разработки
Варианты применения сценариев в процессе разработки зависят от используемой методологии разработки. В одних методологиях разработки все, что требуется это краткий обзор сценария. В других сценарии использования усложняются и изменяются в ходе разработки. В некоторых методологиях они могут начать как краткие деловые сценарии, развиться в детальные системные сценарии использования, и затем перерасти в чрезвычайно детальные и исчерпывающие тесты.
Шаблоны сценариев использования
Нет никакого стандартного шаблона для документации детальных сценариев использования. Существуют много конкурирующих схем, но лучше всего использовать те шаблоны, которые лучше подходят для проекта. Есть, однако смысл упомянуть об основных моментах на которые стоит обратить внимание.
Имя сценария Имя сценария стоит писать в формате глагол-существительное (например, Заимствовать Книги, Забрать Наличные деньги). Оно должно описывать достижимую цель (например, Регистрация Пользователя лучше чем Регистрирующийся Пользователь), и должно объяснять о чем сценарий использования.
Неплохо использовать как имя сценария цель актера, гарантируя таким образом внимание к потребностям пользователя. Два-три слова — оптимум. Если слов в названии больше, то обычно есть более короткое и более информативное имя.
Цель Без цели сценарий бесполезен. Нет никакой необходимости в сценарии использования, когда нет никакой потребности ни в каком актере, чтобы достигнуть цели. Цель кратко описывает то, чего пользователь намеревается достигнуть с этим сценарием. Актеры Актер это кто-то или что-то вне системы и влияющий на систему или находящийся под ее влиянием. Актер может быть человеком, устройством, другой системой или подсистемой, или временем. Человек в реальном мире может быть представлен несколькими актерами, если у них есть несколько различных ролей и целей по отношению к системе. Они взаимодействуют с системой и производят над ней некоторые действия. Заинтересованные лица Заинтересованное лицо — человек или отдел, которых затрагивает сценарий использования. Обычно это работники организации или отдела, для которого создается сценарий. К заинтересованному лицу можно обратиться с просьбой предоставить информацию, отзыв, или разрешение для сценария использования. Предварительное условия Стоит определить все условия, которые должны быть истиной (то есть, описать состояние системы системы) при которых исполнение сценария имеет смысл. Таким образом, если система не находится в состоянии, описанном в предварительных условиях, поведение сценария неопределенно. Заметьте так же, что предварительные условия это не «активаторы» (см. ниже). Так как верные предварительные условия НЕ инициируют выполнение сценария. Активаторы Активатор это событие инициирующее выполнение сценария. Это событие может быть внешним, временным или внутренним. Если активатор не реальное событие (например, клиент нажимает кнопку), но ряд сложных условий, тогда стоит описать процесс активации. Этот процесс должен периодически или постоянно проверять условия активации и инициировать сценарий.
Есть несколько вариантов как описать ситуацию, когда активация происходит, но предварительные условия не удовлетворены.
Сценарии для сайтов и приложений
Как написать пользовательский сценарий?
Во-первых, стоит сказать, что интерфейс – не для заказчика, и не для вас. Интерфейс для человека, который будет им пользоваться и иногда бывает так, что сделанная вами работа нравится только вам и через пару часов или дней и это ощущение проходит. То есть картинки по началу нравились, потому что вы влюблены в проект, но ощущение пропадает, потому что вы спустя какое-то время начинаете уже менее влюбленно на него смотреть и понимаете, что за ним нет никакого смысла, пользы, а проста пустота, картинки и ничего больше.
Сценарий–это сжатое описание способов применения интерфейса для достижения цели. Сценарий нужен, чтобы сформулировать тот стержень, который будет в вашем продукте.
Из чего состоит сценарий:
Не буду рассказывать теорию, я об этом рассказываю в курсе. Сейчас просто на конкретном примере я поясню и расскажу как пишется сценарий.
Во-первых, на примере приложения для РЖД(рис.1)
Цель этого приложения — попасть на поезд без бумажного билета.
Рис.1 Приложение РЖД
Все начинается с того, что человек просто покупает билет на сайте РЖД (рис.2).
Следующим шагом пользователь должен увидеть эту поездку в приложении (рис.3). Он видит активные элементы, с датами, городом и временем.
Дальше на человек на вокзале должен найти свой поезд, путь и вагон (рис.4). Видно поезд, время, путь (определяется непосредственно на вокзале), вагон, место. То есть человеку не нужно распечатывать и доставать бумажные билеты и вся информация, которая ему нужна в данной ситуации видна на экране.
Рис. 5 Альтернативный сценарий
Во-вторых, может быть альтернативный сценарий (рис.5). Человек может захотеть вызвать такси до вокзала и здесь есть ссылка на такси. И может получить push-уведомление, чтобы не пропустить поезд за какое-то время.
Рис.6 Шаг четвертый
Дальше, следующий шаг по основному сценарию. Человек у вагона может показать проводнице штрих-код, чтобы проводница прямо с экрана телефона может считать этот штрих-код, провести идентификацию и пропустить человека дальше в поезд.
Дальше мы уже в поезде. Человек может найти свое место в поезде.На последнем экране, что важно (рис.7).
Есть альтернативный сценарий (рис.8). То есть мы заботимся о человеке больше и думаем не только о том, как ему добраться до дома, т.к. это его конечная цель, в свою квартиру, отель и т.д. И мы даем альтернативный сценарий: сообщить по смс друзьям,родственникам, что все ок и где, во сколько будет встреча. Можно вызвать такси с вокзала. И подключить вайфай. То есть заботимся о человеке чуть больше, делая следующий шаг. И даем ему с комфортном добраться домой (рис.9).
Здесь (рис.9) немного деталей, некоторый вещи можно еще глубже детализировать (каждый альтернативный сценарий,например). Сценарий не должен быть громадным и подробным, необходимо помнить про ключевые точки. Помнить о контексте, откуда человек попадает в приложение, где она находится в данный момент, в какой ситуации. Наше приложение не кончается на поиске места в вагоне, а помнит о следующем шаге.
Сценарий –стратегия. Описывайте ключевые точки процесса глобально, от начала до конца.
Для отправки комментария вам необходимо авторизоваться.
Во-первых, стоит сказать, что интерфейс – не для заказчика, и не для вас. Интерфейс для человека, который будет им пользоваться и иногда бывает так, что сделанная вами работа нравится только вам и через пару часов или дней и это ощущение проходит. То есть картинки по началу нравились, потому что вы влюблены в проект, но ощущение пропадает, потому что вы спустя какое-то время начинаете уже менее влюбленно на него смотреть и понимаете, что за ним нет никакого смысла, пользы, а проста пустота, картинки и ничего больше.
Сценарий–это сжатое описание способов применения интерфейса для достижения цели. Сценарий нужен, чтобы сформулировать тот стержень, который будет в вашем продукте.
Из чего состоит сценарий:
Не буду рассказывать теорию, я об этом рассказываю в курсе. Сейчас просто на конкретном примере я поясню и расскажу как пишется сценарий.
Во-первых, на примере приложения для РЖД(рис.1)
Цель этого приложения — попасть на поезд без бумажного билета.
Рис.1 Приложение РЖД
Все начинается с того, что человек просто покупает билет на сайте РЖД (рис.2).
Следующим шагом пользователь должен увидеть эту поездку в приложении (рис.3). Он видит активные элементы, с датами, городом и временем.
Дальше на человек на вокзале должен найти свой поезд, путь и вагон (рис.4). Видно поезд, время, путь (определяется непосредственно на вокзале), вагон, место. То есть человеку не нужно распечатывать и доставать бумажные билеты и вся информация, которая ему нужна в данной ситуации видна на экране.
Рис. 5 Альтернативный сценарий
Во-вторых, может быть альтернативный сценарий (рис.5). Человек может захотеть вызвать такси до вокзала и здесь есть ссылка на такси. И может получить push-уведомление, чтобы не пропустить поезд за какое-то время.
Рис.6 Шаг четвертый
Дальше, следующий шаг по основному сценарию. Человек у вагона может показать проводнице штрих-код, чтобы проводница прямо с экрана телефона может считать этот штрих-код, провести идентификацию и пропустить человека дальше в поезд.
Дальше мы уже в поезде. Человек может найти свое место в поезде.На последнем экране, что важно (рис.7).
Есть альтернативный сценарий (рис.8). То есть мы заботимся о человеке больше и думаем не только о том, как ему добраться до дома, т.к. это его конечная цель, в свою квартиру, отель и т.д. И мы даем альтернативный сценарий: сообщить по смс друзьям,родственникам, что все ок и где, во сколько будет встреча. Можно вызвать такси с вокзала. И подключить вайфай. То есть заботимся о человеке чуть больше, делая следующий шаг. И даем ему с комфортном добраться домой (рис.9).
Здесь (рис.9) немного деталей, некоторый вещи можно еще глубже детализировать (каждый альтернативный сценарий,например). Сценарий не должен быть громадным и подробным, необходимо помнить про ключевые точки. Помнить о контексте, откуда человек попадает в приложение, где она находится в данный момент, в какой ситуации. Наше приложение не кончается на поиске места в вагоне, а помнит о следующем шаге.
Сценарий –стратегия. Описывайте ключевые точки процесса глобально, от начала до конца.