пользовательские истории и пользовательские сценарии
Как создать User Story, сценарии и кейсы
Не забывайте о пользователях
Dec 13, 2015 · 5 min read
Вы знаете как рассказывать User Story. Почему именно так, а не иначе? И уверены ли вы что вы делаете это правильно, а не просто потому что так сложилось.
В прошлом году я писал статью о том, как разные члены команды работают в одном проекте. Особенно меня интересовала техническая сторона и дизайн.
Любой проект это синтез знаний — с помощью обмена знаний, появляется что-то новое и это целиком и полностью результат совместной работы.
Но самым важным компонентом э того процесса является пользователь, для кого этот сервис и предназначен. Очень многие считают так разработчик и заказчик = сервис. И эта очень большая ошибка — делать продукт только для разработчика, или только для заказчика.
Довольно проще и “дешевле” взаимодействовать заказчику с командой разработки. Но как в эту картину вписать клиента?
Для этого нужны, как минимум, две вещи:
И скорее всего ни для кого это не является новостью. Об этом уже написана ни одна статья. Без пользователей мы анализируем, делаем гипотезы, проектируем интерфейс основываясь на своем опыте. Но это не всегда важно для тех людей, кто будет пользоваться продуктом.
В частности любое решение должно быть обосновано: необходимость>опыт>результат.
Самое главное в разработке правильно понимать потребности пользователей, для того чтобы создать продукт именно для них и добиться результатов.
Даже просто проведенные интервью с пользователями или юзабилити исследования само по себе ценно. Но желательно данные обработать, для того чтобы понять какие плоды принесет каждое из придуманных новых фич.
User Story
User Story краткое заявление которое идентифицирует пользователя и его потребности. Так как персонажи описаны довольно общими словами, пользовательских историй, так же может быть несколько (даже для одной персоны).
В пользовательских историях должно быть— кто пользователь, что ему нужно, и почему он нуждается в этом. Для примера рассмотрим интернет-магазин оборудования.
Джек владелец небольшой студии ландшафтного дизайна. Ему необходимо иметь возможность заказать запасные части для оборудования, для того чтобы своевременно его обслуживать.
Чаще всего подобные магазины имеют совершенно разных клиентов, со своими потребностями. Пользовательские истории помогают документировать практические различия этих пользователей. Если у вас персон 3–4, то пользовательских историй может быть 20, или даже больше. Но не пугайтесь. Они короткие, каждая из 1–2 предложений.
Пользовательские сценарии
Вот пример пользовательской истории для того же самого интернет-магазина
Джерри помогал отцу управлять механическим цехом в Западном Массачусетсе с тех пор как он окончил школу десять лет назад. В прошлом году отец Джери ушел на пенсию и оставил свою должность на сына. Их деревянная рубильная машина — купленная до того как Джери стал управляющим, сломалась. Он подозревает, что проблема в гидравлическом рычаге. Джери находит руководство по эксплуатации этой машины и по имени производителя и серийному номеру он хочет найти в интернете запчасть. Он находит несколько сайтов по своему запросу и выбирает первый. На этом сайте он находит описание и ссылку на PDF-руководство. Он читает его, находит схему гидравлического насоса и номер детали сломанного рычага. Но на той странице, которую он читает, нет ни слова о том как эту деталь можно заказать, как ее найти в магазине (просто номер детали). Он кликает на связь с консультантом надеется, что консультант сможет ему помочь.
Обратите внимание, как этот сценарий рассказывает некоторую предысторию пользователя, указывает его потребность и пытается указать на пробелы в его знаниях, которые могут привести к трудности в покупке.
Варианты использования
Варианты использования это просто длинный список шагов, которые может пройти пользователь до тех пор, пока он достигнет цели. Начинает с того, как пользователь попал на сайт и дальше шаг за шагом до тех пор, пока цель не будет достигнута.
Пример вариантов использования на примере сценария Джерри:
Рубильная машина Джерри ломается
С помощью такого детального описания вы можете увидеть несколько точек, в которых пользовательский опыт пользователя можно улучшить и облегчить ему жизнь. Например в этом примере, можно улучшить следующее: улучшить форму поиска по номеру запчастей из руководства, добавление контактной формы на страницу, с отсутствующим поисковым запросом
User Flow
Наконец, user flows, которые являются формой визуальной документации, иллюстрирующая, контент, с которым сталкивается пользователь вашего сайта, а также последовательность взаимодействия. Именно здесь пользовательские истории, сценарии и варианты использования объединяются в информационную архитектуру.
Вот пример, показывающий все возможные пути пользователя до целевой страницы.
Как это использовать?
Начинайте с описания ваших пользователей, расширяя затем их в пользовательские сценарии, далее создавайте варианты использования и объединяйте все это в пользовательские потоки. Если вы будете проделывать все эти шаги, вы сможете устранить разрыв между пользователем и сервисом, именно в этом случае ваш сервис будет для пользователя, а не для дизайнера, разработчика или заказчика
Пользовательские сценарии: что это такое, как и для чего их нужно строить
Денис Нарижный, руководитель интернет-агентства «Студия F1» и создатель сервиса юзабилити-тестирования сайтов AskUsers.ru, рассказал Нетологии о том, как составлять и использовать пользовательские сценарии.
Сценарии описывают пользовательские истории и взаимосвязи между ними. Они помогают определить, зачем и почему пользователи приходят на сайт и как достигают своих целей: совершают покупки, заказывают по телефону, сравнивают товары, общаются с консультантами.
Прежде чем разработать сценарий, нужно ответить на три вопроса:
1. Кто те люди, что заходят на ваш сайт?
Нужно выделить чёткий сегмент аудитории и проработать портрет клиента, под которого готовится сценарий.
2. Почему они заходят к вам?
На основе аналитики или опроса можно определить, зачем на самом деле пользователи посещают ваш сайт: просто посмотреть, что-то узнать или купить.
3. Какие цели при этом преследуют и как их достигают?
Вариантов не так много, особенно если мы говорим о коммерческих сайтах. Обычные цели — изучить предложение с целью сравнить его с другими, непосредственно купить или сделать заказ, но возможны и другие варианты.
Пошагово достижение целей обычно расписывается в профилях задач. Здесь такая детализация не нужна, просто нужно понимать, какие шаги делает пользователь для достижения цели.
Для чего нужны пользовательские сценарии
Сценарии помогают лучше понимать предпочтения посетителей сайта и анализировать пользовательский опыт. Это нужно, чтобы в дальнейшем проектировать сайт или интерфейс так, чтобы он вписывался в привычные для клиентов паттерны и приводил к цели посещения за наименьшее количество шагов и с минимальными затратами сил, времени и внимания.
Также сценарии используют для анализа пользовательского опыта при проведении юзабилити-тестов и других маркетинговых исследований.
Сценарий — наглядное схематическое представление того, как пользователь решает свою задачу с помощью сайта, что ему помогает и что мешает в достижении цели.
Разновидности сценариев
Пользовательские сценарии по степени детализации и технической проработки делятся на четыре группы.
1. Пользовательские истории
Это самый насыщенный подробностями вариант: рассказ, схемы, видео, фотографии — все, что помогает описать опыт взаимодействия, иногда даже без привязки к персоне клиента. У каждого пользователя может быть своя история и свой специфический опыт. Это сбор сырой информации.
Если мы говорим о покупке: кто-то берет для себя, а кто-то в подарок, кто-то подарит маме, а другой — жене. У кого-то все хорошо с финансами, кто-то собирал деньги на покупку, кого-то интересует кредит и рассрочка. Опыт в этих пользовательских историях будет отличаться.
Запишите простые человеческие истории: «Через месяц у нас юбилей свадьбы, я отложил деньги и собираюсь выбрать подарок жене. У меня есть предел по стоимости, я знаю, что жена любит серебро и носит серьги…».
Вот пример из серии скринкастов: пользователь пытается сделать покупку в интернет-магазине:
Разница между User Stories, Use Cases и Scenarios
За последнее время мы множество раз столкнулись с непониманием того, что же общего между сториз и юзкейсами, а чем они всё-таки отличаются? Что есть пользовательские сценарии и при чем тут Эджайл? Давайте попробуем разобраться.
Прежде, чем отвечать, нужно сделать паузу и признать, что в сегодняшней терминологии есть некоторая путаница — под Сториз, Сценариями или Юзкейсами могут понимать разные инструменты.
Авторы культовой Designing Interactive Systems — People, Activities, Contexts, Technologies выделяют 4 вида сценариев в зависимости от этапа проекта и целей их создания: пользовательские истории (сториз), концептуальные сценарии, конкретные сценарии и варианты использования (юзкейсы).
Важно заметить, что есть еще Эджайловские Юзер сториз товарища Паттона, что описываются по шаблону As a <>, I want <> so that <> и находятся где-то между Concrete Scenario и Use case.
Зависимость содержания деталей
Сториз, они про потребность пользователя. Raw user needs.
Юзкейсы же про поведение, которое вы встроите в продукт, чтобы удовлетворить эти потребности. What the software needs to do.
Сториз пишутся человеческим языком = легко читаются и бизнесом и разработчиками. Express understanding of User needs.
Написание Юзкейсов это designing a functional solution.
Разберемся на примерах
User story
Стартуем с самого масштабного уровня, уделяем внимание контексту и всем поведенческим особенностям. Рассказ ведется не от лица абстрактного пользователя, и даже не от лица персонажа, а от лица реального человека (либо от лица того, кто ведет наблюдение/проводит интервью).
Выиграли билеты на концерт Radiohead в Риме, сборы проходили в последний момент, нанервничались и чуть не поругались 🙂 Решили, лететь налегке.
Когда поехали в аэропорт, то очень торопились и решили не заезжать на заправку, чтобы сэкономить время. В тот момент нам казалось, что бензина достаточно и хватит добраться до аэропорта, но в наши планы вмешались непредвиденные обстоятельства.
Вообщем встряли в пробку и, спустя некоторое время, загорелась лампочка низкого уровня топлива. Пришлось спешно искать заправки поблизости. Как назло, нашу машину можно заправлять только 98-ым бензином, что только добавило накала страстей.
По итогу, нам повезло — заправку нашли, в аэропорт успели, но пришлось сильно поволноваться. Благо Том Йорк сгладил впечатления о поездке, да и Рим крут.
Conceptual scenario
Снижаем планку контекста и движемся к конкретике за счет абстрагирования. Conceptual scenario важны для генерации идей и поиска ответа на вопрос «Как улучшить существующий опыт?».
Алан Купер рекомендует представить, что интерфейс волшебный и в нем можно реализовать всё, что угодно, чтобы выйти за рамки привычного.
Люди в стрессовых ситуациях нуждаются в дополнительном внимании и заботе. В процессе ввода в навигатор конечного адреса маршрута можно определять расстояние до финиша, проверять текущий уровень топлива с учетом актуального среднего расхода и определять, хватит ли нам топлива добраться до заданной точки. Если нет, оповещать об этом водителя.
Если же лампочка низкого уровня топлива уже загорелась, то показывать в навигаторе ближайшие заправки (с возможностью сортировки голосовыми командами, например по октановому числу).
Concrete scenario
Concrete scenarios пополняются деталями реализации и используются для проектирования, в них появляются технические подробности. Пишутся они от лица конкретного персонажа, дабы проявить эмпатию.
Когда Сергей вводит адрес в навигатор, то он хочет быть уверенным, что ему хватит топлива доехать до указанной точки. Если нет, то автомобиль предупредит об этом Сергея.
Если в момент движения, Сергей отклонится от маршрута и поедет другим путем (или будет ехать очень быстро), то с включением лампочки низкого уровня топлива, он увидит на карте навигатора ближайшие заправки и сможет выбрать подходящую по особенностям топлива.
Во время движения соединение с интернетом может прерываться.
Agile User story
Примерно на этом уровне находятся и Эджайловские Юзер стори.
Я, как водитель, в момент включения лампочки низкого уровня топлива, хочу заправить свою машину на ближайшей заправке.
Use case
Далее уже можно написать Юзкейсы, описывающие все взаимодействия системы с пользователем. Пишутся они от лица абстрактных пользовательских ролей.
Из всех видов сценариев Юзкейс — наиболее технический и напоминающий алгоритм, а не историю.
Я, как пользователь-водитель (с включенной лампочкой низкого уровня топлива) смогу:
У Юзкейсов есть свой стандартизированный шаблон:
Потом собираете вместе ваши Сценарии, Сториз и Юзкейсы в один документ, рисуете Флоу и получаете полное описание каждого взаимодействия между пользователем и продуктом, которое вы планируете создать.
Когда и что использовать?
Все виды сценариев придуманы в угоду определения требований: что система должна делать в принципе и как она должна вести себя для того, чтобы удовлетворить запросы пользователей.
Конечно это требует дополнительных усилий и времени, поэтому на простых информационных продуктах можно пожертвовать сценариями, а без вариантов использования можно обойтись там, где взаимодействие достаточно прямолинейно, отсутствуют альтернативные и исключительные сценарии (или их проще и быстрее продемонстрировать в прототипе).
Но чем сложнее взаимодействие, тем желательнее начинать с контекста и поведенческих особенностей, двигаясь к конкретике по решениям. Иначе, есть риск вложить 80% усилий в 20% сценариев, с которыми пользователи будут работать мало и редко, а внимание дизайнера будет размазано по всем возможным сценариям, что снизит их качество.
Основы пользовательских историй. Часть 1. Введение
Перевод: Александр Якима (www.enter-agile.com)
Независимый консультант, agile-тренер. В IT-индустрии с 2002 года. Работал менеджером проектов, программ, а также присейл-менеджером в аутсорсинговых компаниях и директором по разработке в стартапах Силиконовой долины. В 2007-2008 сотрудничал с тренинг-центром Luxoft.
Аннотация:
В этой статье мы предлагаем обзор происхождения и приложений пользовательских историй, являющихся ключевым механизмом в гибких методах разработки и служащих проводником требований заказчика сквозь поток ценностей. В свою очередь, пользовательские истории являются критическим элементом в статьях «Бережливая и масштабируемая информационная модель требований для гибких компаний» и «Общая картина гибкости компании», обе статьи можно найти в блоге. Текущая же статья извлечена из будущей книги «Гибкие требования: бережливые практики управления требованиями для команд, программ и предприятий», издание которой запланировано на 2010 год. Отдельная благодарность Дженнифер Фосетт (Jennifer Fawcett) и Дону Видригу (Don Widrig) за их вклад в работу над книгой.
О терминологии (примечания автора перевода):
Центральным объектом статьи, как читатель уже мог догадаться, является пользовательская история, в оригинале звучащая как user story. Существует несколько различных, в том числе и довольно экстравагантных переводов этого термина (напр., «пожелание»). Однако при переводе я решил пользоваться исключительно практическими мотивами, именно поэтому мы используем термин «пользовательская история» в несколько официальном ключе и для непосредственных выкладок — «стори». Дело в том, что именно этот термин преобладает в быту большинства гибких команд при работе с англоязычными заказчиками и поэтому вполне оправдан.
Основы пользовательских историй
Они были на великом пиру языков, но довольствовались крохами.
— паж Моль к Костарду, «Напрасный труд любви», Уильям Шекспир
Введение
В гибкой разработке пользовательская история — это легковесная и более живая замена традиционным средствам описания требований: функциональных спецификаций, описаний сценариев использования (use cases) и т. д. На самом деле можно даже утверждать, что пользовательская история (стори) является наиболее весомым артифактом в гибкой разработке, поскольку представляет собой контейнер, служащий переносу потока ценностей к пользователю, а суть гибкой разработки как раз и состоит в быстрой доставке ценного результата.
Стори служит также метафорой всему нашему подходу, базирующемуся на инкрементальной доставке ценностей, а именно:
Определить полезную стори — реализовать и оттестировать в рамках короткой итерации — продемонстрировать и/или доставить ее пользователю — получить фидбек — усвоить информацию — повторить в цикле!
Я уже вкратце приводил обсуждение пользовательских историй в контексте моих более широких статей: «Бережливая и масштабируемая информационная модель требований для гибких компаний» и «Общая картина гибкости компании»(1), в которых наряду с темами, эпосами и фичами, стори являются первостепенными артефактами требований, используемых гибкими командами.
В этой статье мы более подробно опишем пользовательские истории, так как именно здесь мы раскроем одну из ключевых гибких практик, которая дает возможность направлять наше решение непосредственно на потребности пользователя и в то же время удостовериться в качестве продукта.
Пользовательские истории: обзор
В вышеупомянутых статьях и связанных с ними публикациях в блоге я подчеркивал существенность вклада Скрам-модели в гибкие практики для компаний, отмечая, к примеру, само определение роли продакт оунера (product owner), являющейся неотьемлимой по отношению к работе с требованиями. Но самим изобретением пользовательской истории мы обязаны XP и именно сторонники XP и разработали всю широту и глубину этого артефакта. Хотя это значительно менее значимое «методологическое распутье», чем это может показаться, так как пользовательские истории сейчас обычно входят в рамки Скрам-курсов как средство построения бэклога и определения состава Спринта. Наверняка мы должны благодарить Майка Кона (Mike Cohn) за большую часть этой интеграции, так как он обстоятельно проработал пользовательские истории в своей книге User Stories Applied [см. Cohn 2004], и был очень активным в сообществе Scrum Alliance.
Для наших целей мы определим пользовательскую историю так:
Пользовательская история — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.
В XP стори обычно пишутся заказчиком, непосредственно интегрируя таким образом заказчика в процесс разработки. В Скраме продакт оунер часто создает стори, учитывая информацию от заказчика, стейкхолдеров и команды. Однако, на самом деле любой член команды, обладающий достаточными знаниями в бизнес-области, может создавать пользовательские истории, но в конечном итоге продакт оунер решает вопрос о принятии и выставлении приоритетов потенциальных стори в бэклоге продукта.
Пользовательские истории являются средством определения поведения системы так, чтобы это было понятно и разработчикам и пользователям. Стори концентрируют работу на ценности, определенной пользователем, нежели на структурном разбиении на задачи, как это принято делать в силу традиции. Они предоставляют легковесный и эффективный подход к управлению требованиями в системе.
Пользовательская история фиксирует короткую формулировку функции на карточке или, возможно, с помощью онлайн-средства.
Подробности поведения системы не фигурируют в этой короткой формулировке, а оставляются на потом и разрабатываются посредством диалога и критерия приемки командой и продакт оунером.
Пользовательские истории помогают преодолевать разрыв между разработчиками и пользователями
В гибкой разработке разработчик должен уметь общаться на языке пользователя, а не пользователь – говорить техническим языком. Эффективное коммуницирование является ключем ко всему и поэтому нам просто необходим общий язык. Стори как раз предоставляет общий язык для достижения понимания между пользователем и технической командой.
Билл Вейк (Bill Wake), один из создателей XP, описывает это следующим образом(2):
Пиджин (pidgin) — упрощенный язык, обычно используемый в торговле, позволяет людям, которые не могут общаться на своем родном языке, тем не менее работать вместе. Пользовательские истории действуют подобным образом. Мы не ждем от заказчика или пользователей точно такого же видения системы, как у разработчиков; стори действуют как пиджин, где обе стороны всегда могут договориться, чтобы эффективно вместе работать.
В случае с пользовательскими историями нам не нужно понимать язык друг друга на уровне мастерства, необходимого для написания сонетов; нам просто нужно в достаточной мере понимать друг друга, чтобы знать, когда мы достигли соответствующего соглашения!
Пользовательские истории — это не требования
Несмотря на то, что стори играют в огромной степени роль, ранее принадлежавшую спецификациям требований (SRS), сценариям использования и т. п., они все же ощутимо отличаются рядом тонких, но критических нюансов:
Литература
Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston, MA: Addison-Wesley.
Пользовательские сценарии: что это, как и для чего их нужно строить
Как сделать сайт удобным для пользователей.
Пользовательские сценарии рассказывают об историях и образах покупателей, взаимосвязях между юзерами и позитивным клиентским опытом. Благодаря сценариям можно понять, почему люди попадают на сайт и как достигают своих целей: совершают покупки, делают заказ по телефону, сравнивают товары, разговаривают с консультантами.
Как разработать пользовательский сценарий для вашего продукта — разбираемся.
Что такое пользовательские сценарии
Пользовательский сценарий (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 по шагам: кто, что, как и в какой последовательности делает.
Пользовательские истории и концептуальные сценарии нужны для понимания основных мотивов юзеров и погружения в мир клиента. Конкретные сценарии и варианты применения уже могут использоваться для проектирования информационной архитектуры, интерфейсов, а также при проведении тестов и исследований юзабилити.