Артефакты: сценарии

Описание

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

В терминологии есть некоторая путаница – под «сценариями» могут иметь в виду разные инструменты, от пользовательских историй и до вариантов использования. Авторы книги Designing Interactive Systems — People, Activities, Contexts, Technologies Benyon, Turner и Turner предложили отличное объяснение того, как разные виды сценариев связаны между собой и для каких целей служат. Они выделяют 4 вида сценариев в зависимости от этапа проекта и целей их создания: пользовательские истории, концептуальные сценарии, конкретные сценарии и варианты использования.

Соотношение между разными видами сценариев:

На каждой последующей стадии особенностям интерфейса уделяется все больше внимания.

Пользовательские истории (user stories, несмотря на полное совпадение по названию, не имеют ничего общего с историями из гибких методологий разработки) описывают идеальный опыт взаимодействия пользователей в свободной форме и включают информацию о среде использования. Пользовательские истории могут быть представлены в самых разных форматах: от дневниковых записей, результатов наблюдения и интервью до фотографий и даже видео (пример http://vimeo.com/40533396).

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

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

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

Пример:

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

Правда неясно, как его выбирать: впарят какую-нибудь дорогую ерунду, а потом окажется, что пить это невозможно. Может просто взять что-то популярное?

Хорошо бы посоветовал кто-нибудь, кто в этом разбирается. А то я кроме «красное/белое» и «сухое/сладкое» даже не знаю, на что ориентироваться.

Ну и хорошо бы магазин поближе к работе был, чтобы в обед можно было заскочить. На худой конец – доставка домой после 19:00 тоже подойдет, но тогда лучше бы оплатить заранее – вдруг налички не будет.

Да, и главное – начальника впечатлить и удивить подарком, может как-то вручить оригинально.

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

Концептуальные сценарии (conceptual scenarios) создаются из пользовательских историй при помощи абстрагирования. Все мелкие детали отбрасываются, похожие истории объединяются в одну. Оставшееся описание практически полностью лишено технических подробностей.

Пример:

Заказ вина

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

Концептуальные сценарии важны для генерации идей и определения требований. На этом этапе полезно собраться с командой (и заказчиком, если он есть) на мозговой штурм и поискать ответ на вопрос «Как улучшить опыт [Название задачи]». Алан Купер рекомендует вообще представить, что интерфейс волшебный и в нем можно реализовать все, что угодно, чтобы выйти за рамки привычного. Ничего, если какие-то из идей будут казаться на первый взгляд нереализуемыми. Технические ограничения окажут свое влияние на следующем этапе. И, в конце концов, «Любая достаточно продвинутая технология неотличима от волшебства» 🙂

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

Конкретные сценарии (concrete scenarios) создаются на основе абстрактных, включают детали реализации и используются для проектирования. Именно в конкретных сценариях появляются технические подробности. Конкретные сценарии пишутся от лица персонажа.

Пример:

Берем за основу концептуальный сценарий, добавляем ограничение – пользователь работает с планшета:

Заказ вина

Борис Пожарский хочет купить вино в подарок начальнику на этой неделе. Вино должно быть «проверенным» (т.е. его качество должны подтверждать отзывы от других покупателей, награды и рейтинги экспертов). У вина должна быть красивая легенда, чтобы впечатлить начальника при вручении.

Борис выбирает вино с планшета (iPad), параллельно отвлекаясь на другие дела. Ему точно не хочется заполнять слишком много полей. Так что оплатить заказ лучше на месте.

После выбора вина по дороге в магазин Борис сверится с картой на планшете. По дороге, кстати говоря, доступа к Интернету может и не быть.

Главное, чтобы выбранное вино было в наличии, когда он приедет.

Несколько конкретных сценариев могут быть формализованы и объединены в один вариант использования (use case).

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

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

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

В то же время создавать варианты использования без предварительной проработки сценариев нежелательно по главной причине: применение в них абстрактных ролей, которые не вызывают эмпатии и ничего не сообщают проектировщикам о пользователях и контексте их работы. Из-за этого все возможные взаимодействия (включая альтернативные и исключительные сценарии) рассматриваются как одинаково важные и возможные. А это приводит к тому, что, грубо говоря, вместо того, чтобы вложить 80% усилий в те 20% сценариев, с которыми пользователи будут работать много и часто, внимание проектировщика размазывается по всем возможным сценариям, делая их «средними» по качеству.

Пример:

В целях экономии времени привожу фрагмент варианта использования:

Зачем использовать

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

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

Подводные камни

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

Создание сценариев (а особенно – прохождение по всему пути от истории до вариантов использования) требует дополнительных усилий и времени, поэтому на проектах с жесткими ограничениями по бюджету/срокам придется выкручиваться. Смело жертвовать сценариями можно для простейших проектов вроде сайтов-визиток. Без вариантов использования можно обойтись там, где взаимодействие достаточно прямолинейно, отсутствуют альтернативные и исключительные сценарии (или их проще и быстрее продемонстрировать в прототипе).

В зависимости от исследуемой деятельности анализ и документирование пользовательских историй может занять от 1-2 часов (простые задачи, либо весь набор действий воспроизводится за это время) до 8 часов (рабочий день), реже – дольше. Чтобы можно было говорить о каких-то закономерностях в поведении, количество пользователей для исследования должно быть не меньше 7.  Анализ результатов и поиск закономерностей может занимать 8-16 часов. Итого примерные затраты по времени на самый первый этап – порядка 30-70 часов. Все последующие этапы занимают как правило значительно меньше времени. Абстрактные сценарии можно создать за ~8 часов (зависит от доступности команды для мозгового штурма), конкретные – за 8-16 часов (очень зависит от количества персонажей и способов взаимодействия). Все это, конечно же, средние оценки.

В общем же чем сложнее система, чем необычнее взаимодействие, тем желательнее включить в список работ все шаги.

И напоследок вопрос на засыпку: как вы считаете, к какому типу сценариев можно отнести те самые user stories из гибких методологий?

Полезные ссылки и инструменты

Подробный разбор формата описания конкретного сценария и пример в моей статье для analyst.by