что такое проектирование сценария ошибок пользователя
Пользовательские сценарии: что это такое, как и для чего их нужно строить
Денис Нарижный, руководитель интернет-агентства «Студия F1» и создатель сервиса юзабилити-тестирования сайтов AskUsers.ru, рассказал Нетологии о том, как составлять и использовать пользовательские сценарии.
Сценарии описывают пользовательские истории и взаимосвязи между ними. Они помогают определить, зачем и почему пользователи приходят на сайт и как достигают своих целей: совершают покупки, заказывают по телефону, сравнивают товары, общаются с консультантами.
Прежде чем разработать сценарий, нужно ответить на три вопроса:
1. Кто те люди, что заходят на ваш сайт?
Нужно выделить чёткий сегмент аудитории и проработать портрет клиента, под которого готовится сценарий.
2. Почему они заходят к вам?
На основе аналитики или опроса можно определить, зачем на самом деле пользователи посещают ваш сайт: просто посмотреть, что-то узнать или купить.
3. Какие цели при этом преследуют и как их достигают?
Вариантов не так много, особенно если мы говорим о коммерческих сайтах. Обычные цели — изучить предложение с целью сравнить его с другими, непосредственно купить или сделать заказ, но возможны и другие варианты.
Пошагово достижение целей обычно расписывается в профилях задач. Здесь такая детализация не нужна, просто нужно понимать, какие шаги делает пользователь для достижения цели.
Для чего нужны пользовательские сценарии
Сценарии помогают лучше понимать предпочтения посетителей сайта и анализировать пользовательский опыт. Это нужно, чтобы в дальнейшем проектировать сайт или интерфейс так, чтобы он вписывался в привычные для клиентов паттерны и приводил к цели посещения за наименьшее количество шагов и с минимальными затратами сил, времени и внимания.
Также сценарии используют для анализа пользовательского опыта при проведении юзабилити-тестов и других маркетинговых исследований.
Сценарий — наглядное схематическое представление того, как пользователь решает свою задачу с помощью сайта, что ему помогает и что мешает в достижении цели.
Разновидности сценариев
Пользовательские сценарии по степени детализации и технической проработки делятся на четыре группы.
1. Пользовательские истории
Это самый насыщенный подробностями вариант: рассказ, схемы, видео, фотографии — все, что помогает описать опыт взаимодействия, иногда даже без привязки к персоне клиента. У каждого пользователя может быть своя история и свой специфический опыт. Это сбор сырой информации.
Если мы говорим о покупке: кто-то берет для себя, а кто-то в подарок, кто-то подарит маме, а другой — жене. У кого-то все хорошо с финансами, кто-то собирал деньги на покупку, кого-то интересует кредит и рассрочка. Опыт в этих пользовательских историях будет отличаться.
Запишите простые человеческие истории: «Через месяц у нас юбилей свадьбы, я отложил деньги и собираюсь выбрать подарок жене. У меня есть предел по стоимости, я знаю, что жена любит серебро и носит серьги…».
Вот пример из серии скринкастов: пользователь пытается сделать покупку в интернет-магазине:
Диаграмма сценариев использования в процессе разработки ПО
Уже несколько лет я, как аналитик, довольно широко использую в своей работе сценарии использования (СИ) и диаграммы СИ для документирования требований. Вообще, у сценариев использования есть разные названия. Их называют use cases, варианты использования и даже прецеденты. Помню, как в середине 2000-х, на некоторых аналитических ресурсах шло жаркое обсуждение того, как же перевести термин use case на русский язык. Вот тогда это страшное слово «прецедент» и появилось, даже более того, некоторые товарищи утверждали, что русский язык ущербен и не позволяет передать все тонкости понятия use case. Но как показало время, понятие сценарий использования (или вариант использования) вполне себе подходит и довольно приятно на слух.
Имея только положительный опыт работы с СИ, я был очень удивлен, когда при общении с коллегами из других компаний узнал, что они их не используют и, более того, даже пытались переубедить меня, что рисование человечков, овалов и палочек между ними – это пустая трата времени. Поэтому я и решил поделиться своим опытом и продемонстрировать, как диаграммы СИ помогают мне в работе.
Во-первых, что такое сценарий использования? Сценарий использования – это связный рассказ о поведении системы, когда она взаимодействует с кем-то (или чем-то) из внешней среды. Кто-то или что-то может быть пользователем системы, это может быть какая-то информационная система или устройство. И этот кто-то или что-то называется Действующим лицом (ДЛ). А сам сценарий использования представляет собой последовательность шагов, которые описывают действия ДЛ и реакцию системы на них.
Например, сценарий регистрации на каком-нибудь сайте может выглядеть вот так:
Но въедливый читатель может справедливо возразить, что в разработку такой сценарий отдавать нельзя. И он будет прав! Мы ведь сейчас посмотрели на систему с высоты, наверно, 5-этажного дома, когда общее поведение уже понятно, но детальных требований ещё нет. Поэтому сценарий использования должен быть, как минимум, дополнен альтернативными потоками выполнения (то что представлено выше, называется основной поток и описывает действия системы, когда все идет как надо). Альтернативные потоки – это потоки, в которых описывается реакция системы на ошибочные действия пользователя или исключительные ситуации, либо же случаи альтернативных действий пользователя, если он захотел, например, зарегистрироваться с помощью аккаунта в социальной сети. Также документ со сценарием использования можно дополнить деталями пользовательского интерфейса, правилами валидации данных, различными бизнес-правилами и сообщениями об ошибках. А вот нефункциональные требования обычно описываются в отдельном документе, так как они обычно применимы ко всей системе целиком, а не к конкретным СИ.
Если же подняться ещё выше и посмотреть на систему с большей «высоты», то она будет выглядеть как набор услуг, предоставляемых системой пользователю (сценарии использования также можно рассматривать как высокоуровневые требования к системе). Тут мы приходим к тому, что неплохо бы было визуализировать эти требования, и для этого отлично подходит соответствующая диаграмма UML: диаграмма сценариев использования. Кусочек диаграммы показан ниже. Она состоит из действующих лиц, сценариев использования и различных связей между ними.
Для разработчиков и тестировщиков она, на первый взгляд, несет ещё меньше пользы, чем сами сценарии использования. Но ведь и предназначена она для другого!
Диаграмма СИ рисуется обычно аналитиком в самом начале проекта для того, чтобы широкими мазками охватить весь планируемый функционал проекта и согласовать его с заказчиком. И после этого каждый СИ уже детализируется с помощью шагов и детальных требований. СИ помогают смотреть на систему с точки зрения предоставляемых системой услуг и не закапываться в частности.
Я обычно использую диаграмму СИ для решения следующих задач:
Оценка трудоемкости проекта
Как показывает опыт и практика, оценка получается тем точнее, чем детальнее выделен список предстоящих работ. Ведь действительно, задачу «написать статью» оценить гораздо сложнее, чем задачу «найти 5 картинок для иллюстраций». Так вот, сценарии использования являются первой итерацией разбивки системы на отдельные элементы. Более того, эти элементы обладают хорошей связностью (в данном случае – функциональная) и могут быть оценены отдельно друг от друга. Если этого недостаточно, то уже каждый СИ можно декомпозировать на основной/альтернативные потоки или даже задачи, которые необходимо выполнить программисту для реализации отдельного сценария.
Здесь довольно часто также проявляется возможность повторного использования ранее созданных артефактов. Например, если для системы требуется функционал регистрации пользователей, то плюс/минус он будет работать одинаково во многих системах, что при оценке сразу же снижает степень неопределенности.
Даже существует специальный способ оценки, основанный на СИ – Use Case Points. В этом случае выделяются действующие лица и сценарии, у них по определенным правилам определяется сложность, задаются некоторые поправочные коэффициенты, учитывающие профессионализм команды и сложность предметной области, и на выходе появляется готовая оценка. То есть, к оценке, в идеале, даже не надо привлекать разработчиков и тестировщиков.
Планирование графика работ
В проектах с фиксированном бюджетом обычно явно выделяются последовательные стадии проектирования, разработки и тестирования (как в водопадной модели). Но в реальности тестирование уже частично начинается даже до завершения стадии проектирования, так как тестировщики подключатся к ревью разработанных требований и начинают писать тест-дизайн. И если для аналитика и, скажем, архитектора, составить график работ не составляет большого труда, так как активности этих ролей начинаются вместе со стартом проекта, то определить, когда и на какую задачу стоит подключать тестировщиков с разработчиками, уже становится сложнее. Действительно, ведь входными данными для них являются подготовленные и согласованные документы с требованиями. И для решения этой проблемы опять хорошо подходят СИ. Так как каждый сценарий содержит в себе завершенное описание какого-то процесса, то их проще согласовывать с заказчиками и, соответственно, можно довольно точно установить в план-графике ключевые точки согласования документов требований. А уже от этих точек планировать работу остальной команды.
Выявление пропущенных требований
Не удивительно, что когда заказчик каким-то образом озвучивает требования к будущей системе, то он в своем описании сконцентрирован именно на полезном функционале и никак не упоминает, например, функции настройки системы или функции управления учетными записями пользователей, хотя без них система не будет полноценно работать. Очень часто после получения таких требований команда начинает выполнять оценку. У меня на практике были случаи, когда команда сразу бросалась в бой и оценивала то, что описал заказчик, оставляя за бортом неозвученные, но, тем не менее, обязательные функции системы.
Также бывает и другая ситуация, когда в описании системы присутствуют требования о том, что в процессе работы пользователи должны создавать какие-то сущности. В подавляющем большинстве случаев, к таким сущностям применимы все CRUD (Create, Read (или также встречается расшифровка Retrieve), Update, Delete) операции, про которые тоже иногда забывают. В чем же здесь польза модели СИ? А как раз в графическом представлении требований. Когда глаз охватывает всю картинку, то гораздо проще заметить недостающие элементы, чем когда требования сформулированы обычным текстом.
«Оглавление» для проектных документов
Очень часто заказчик просит вместе с системой передавать комплект проектной документации. У себя в компании мы пишем проектную документацию в виде сценариев использования. Если же заказчик требует документы по ГОСТу, то все равно сперва пишутся сценарии использования, а затем уже на их основе формируются ГОСТовские документы.
У нас используется, как минимум, два подхода к документированию: когда каждый СИ описывается в отдельном документе, и когда в одном документе описываются сразу несколько СИ, относящихся к одной подсистеме. Часто тот или иной подход определяется, исходя из принятого процесса или привычек заказчика.
Выше уже было сказано, что первая версия списка сценариев использования уже формируется на этапе оценки и планирования графика работ. В дальнейшем этот список может дополняться и корректироваться, но уже с определенной степенью точности можно договариваться с заказчиком о том, какие именно документы будет предоставлять проектная команда.
Очерки о юзабилити: Часть 6. Проектирование взаимодействия
Приветствую всех, кому интересна тема юзабилити. Напомню, в своей предыдущей статье (Очерки о юзабилити. Часть 5: Вежливые программы) я размышляла о том, какое поведение программ создает отрицательное впечатление у пользователей. Сегодня мы поговорим о том, как создавать системы, которые казались бы пользователю вежливыми и дружелюбными и вызывали бы желание использовать их в дальнейшем.
Проектирование взаимодействия
Итак, начнем с определения. Которое, вообще говоря, звучит достаточно туманно:
«Проектирование взаимодействия (Interaction Design, IxD) — область знаний, направленная на проектирование поведения продуктов и систем, с которыми пользователем осуществляется взаимодействие». Wikipedia
Трудно назвать это определение исчерпывающим и понятным. Так что попробуем разобраться, используя знания:
а) о смежных областях:
б) о результатах деятельности проектировщиков взаимодействия.
Для лучшего понимания места проектирования взаимодействия в контексте UX можно посмотреть на следующую диаграмму, из которой видны связи с такими областями знаний как информационная архитектура, проектирование интерфейса, юзабилити-инженерия, эргономика, человеко-компьютерное взаимодействие, промышленный дизайн и, в конечном итоге, проектирование опыта взаимодействия:
Несомненно, диаграмму рисовал кто-то, занимающий должность проектировщика взаимодействия 🙂 (это видно по огромной области, уделенной под эту деятельность). Можно найти похожие диаграммы, центр которых будет точно также же занят, к примеру, информационной архитектурой. Правда, как обычно, где-то посередине: с одной стороны, разные компетенции очень часто пересекаются, и потому их «рвут на части», причисляя ту или иную деятельность к компетенциям то проектировщиков взаимодействия, то информационных архитекторов, то юзабилити-инженеров. С другой – в зависимости от специфики проекта действительно порой приходится уделять больше внимания той или иной составляющей. Для себя я определила проектирование взаимодействия как «сердце» UX. В основном потому, что все остальные области (информационная архитектура, визуальный дизайн, юзабилити инженерия) направлены на решение довольно узких задач (организация информации и проектирование навигации, подбор цветовых схем, шрифтов и других элементов дизайна, обеспечение эффективности, продуктивности и удовлетворенности пользователей), и, пожалуй, концентрируясь только на этих областях, спроектировать систему нельзя. А проектирование взаимодействия вполне способно покрыть весь процесс.
Лучше понять, что же такое проектирование взаимодействия, можно, взглянув на возможные артефакты этой деятельности (я умышленно описываю только самые близкие аналитикам варианты, разумеется, полный список намного больше):
Так как практически каждый первый аналитик очень хорошо представляет, что такое варианты использования, на них мы останавливаться не будем. А рассмотрим мы вместо этого такой артефакт как пользовательские сценарии.
Пользовательские сценарии
Одним из мощнейших инструментов проектирования взаимодействия являются пользовательские сценарии. Я начала использовать этот инструмент относительно недавно, ранее отдавая предпочтение описанию в виде Use Case-ов (Варианты использования или Прецеденты использования). Однако на текущий момент сценарии зарекомендовали себя исключительно положительно. Во-первых, в процессе разработки сценариев остается гораздо больше пространства для воображения и условий для придумывания уникальных решений и мощных фич (что только плюс, если вы не просто документируете будущую систему, а и пытаетесь учесть / улучшить опыт взаимодействия). Сам процесс построен так, что стимулирует творческую деятельность. Во-вторых, это не обезличенные сценарии, а взаимодействия, привязанные к реальным персонам. Персоны, напомню, иллюстрируют собой живых людей, с их мотивами, целями, задачами, опытом, эмоциями (см. Очерки о юзабилити. Часть 1: Введение). А значит, процесс взаимодействия в результате получится естественным, а не искусственным и чуждым пользователю алгоритмом. Ну и в-третьих, как показала практика использования сценариев, этот инструмент вносит тот самый fun в процесс.
Тем, кто не проникся таким инструментом, как персоны, настоятельно советую посмотреть презентацию Санжара Кеттебекова «Новое лицо персоны. Аналитика поведения для дизайна», в которой рассказывается, как именно при помощи персон команда Санжара добилась повышения прибыли сайта Los Angeles Times (http://latimes.com/) вдвое.
Вот как выглядит профиль персоны (пример на английском с реального проекта; имена, пароли и явки изменены):
Сценарий – это в буквальном смысле сценарий, в котором в роли актеров выступают ваши персоны. В условиях ограниченного времени можно использовать только персоны (без сценариев), правда, в этом случае будет довольно трудно удерживать в памяти их особенности в каждый момент времени. Поэтому если время позволяет и есть желание попробовать что-то новое, стоит представить взаимодействие пользователя с вашей системой в виде сценария.
Для описания сценариев я использую следующий шаблон (его можно скачать по ссылке «шаблон описания сценариев»):
В этом разделе нужно определить, с одной стороны, чего пытается достичь пользователь, а с другой – как задачи пользователей вписываются в цели организации. Если вы провели всю предварительную работу (например, создали Vision & Scope документ и персоны), эти цели у вас уже где-то задокументированы. Остается только включить их сюда. Это позволяет заодно проконтролировать, что никакие цели не остались «за бортом» и вы учли интересы всех сторон (фактически – еще один вариант трассировки требований).
Это самый главный раздел сценария. Здесь обычно по шагам расписывается, каким образом пользователь будет достигать своих целей. Если вы хотя бы раз описывали Use Case-ы, с описанием сценария у вас едва ли возникнут трудности. Если нет, то вам понадобится всего лишь чуть больше практики. Главное отличие в том, что в сценариях допустимы «лирические отступления»: любые детали о контексте использования системы, о мыслях и эмоциях пользователя, приветствуются.
В этом разделе описывается, какие материалы и какая информация нужна пользователю для того, чтобы успешно использовать интерфейс. Например, для приглашения своих друзей в какую-то систему пользователю может понадобиться список их электронных адресов (которые едва ли он помнит наизусть). Значит, можно подумать о том, как помочь ему с этим.
Какие похожие вещи делал пользователь в прошлом? Как раньше организация обходилась без этого решения?
Как ни крути, большинство систем, которые мы создаем – не уникальны. Если бы было не так, в сети не нашлось бы двух сайтов, имеющих нечто общее. Если вы создаете платежную систему, подумайте, с какими платежными системами пользователь уже умеет работать. Если это мобильное приложение – вы уже в некотором роде ограничены предыдущим опытом пользователя: можно, конечно, придумать уникальные жесты, которых никто еще не встречал. Однако в этом случае обучаемость заметно снизится, что, в свою очередь, отрицательно скажется на юзабилити.
Какие физические, временные или финансовые ограничения проявят себя во время работы пользователя?
Зная о таких ограничениях, можно определить метрики, по которым в дальнейшем мы будем судить об успешности нашего решения. Например, если мы знаем, что у пользователя есть только 5 минут перед тем, как ему нужно будет убежать на совещание, мы можем проверить, реально ли выполнить задачу за 5 минут. Или другой пример, мы знаем, что нас персонаж будет в большинстве случаев использовать систему (мобильное приложение на смарт-фоне) в московском метро в часы пик. В таком случае мы знаем, что пользователь будет стеснен в движениях (ага, пассажиры вокруг) и ограничен в жестах (т.к. будет держать свой смарт-фон и пользоваться им одной рукой). Так давайте учтем и тоже проверим это.
Где находится пользователь? Что у него на столе? Как у пользователя обстоят дела с доступом к необходимой информации (например, пользовательским мануалам)? Что написано на стикерах, прикрепленных к его монитору?
Что из железа и софта использует пользователь в своей работе? Эту информацию, как и многое другое, можно получить при изучении данных веб-аналитики.
Каковы связи между этим пользователем и другими людьми, на которых влияет система? Задумайтесь о социальных последствиях вашего решения.
Созданный сценарий в результате выглядит примерно следующим образом:
После того, как такие сценарии составлены, проводится нечто вроде мозгового штурма. Шаги сценария выписываются на отдельные стикеры, затем каждый шаг обсуждается командой. В процессе обсуждения выясняется следующее:
1) Какие вопросы, в том числе – технические, вызывает шаг?
2) Комментарии к шагу (например, пожелания заказчика)
3) Идеи: самое интересное и приятное, именно на этом этапе зачастую обнаруживаются хитрые решения и уникальные «фичи».
Обсуждение может выглядеть вот так:
Артефакт, который получается в результате, называется Scenario Map. Пример (не мой):
Это все касается проектирования систем. Если говорить об оценке существующих интерфейсов, без сценариев там тоже никуда. Можно, конечно, оценивать каждую «фичу» самостоятельно и оторвано от контекста. Правда, нужно понимать, что в реальной жизни пользователь не совершает действий, вроде «Открыть список ». Он делает это для достижения какой-то цели или выполнения конкретной задачи. И в зависимости от того, какой будет эта цель или эта задача, у пользователя будут разные требования к интерфейсу. Т.е. при оценке отдельной «фичи» можно не обнаружить проблем ни с визуальным дизайном, ни с информационной архитектурой (или обнаружить и даже поправить их). Но как быть, если эта «фича» просто не соответствует целям пользователя? Чтобы оценить это, вам понадобятся сценарии. Можно, конечно, пройтись и по шагам юз кейса. Однако тут велик шанс того, что вы в результате оцените не юзабилити, а то, насколько соответствует разработанная система спецификации.
Для оценки юзабилити необязательно описывать сценарий настолько же детально, как для проектирования. Можно ограничиться целями и шагами сценария (хотя, конечно, чем больше информации о контексте использования у вас будет, тем выше вероятность того, что ваша оценка будет объективной). Попробуйте пройти по шагам, описанным в сценарии. Так ли ведет себе система, как предполагалось? Наблюдаются ли особенности, которые могут мотивировать пользователя? Или, наоборот, системе присущи признаки поведения, перечисленные выше? Это вопросы, на которые предстоит ответить, перед тем, как дать заключение о том, насколько хороша система.
Ну и, конечно же, стоит всегда помнить о том, что то, как вы себе представляете пользователей и контекст использования – не более чем ваши гипотезы. А гипотезы нужно проверять. Поэтому ищите возможности для таких проверок. Выходите «в поле», наблюдайте за пользователями, задавайте им вопросы, проверяйте свои предположения.
Дальнейшее чтение и полезные ссылки:
1. Сообщество проектировщиков взаимодействия: Interaction Design Association
2. Онлайн-библиография статей на тему проектирования взаимодействия http://www.interaction-design.org/references/authors/
3. Джеф Раскин «Об интерфейсе»
Предыдущие статьи по теме:
Пишем пользовательские сценариии для анализа дизайна сайта
При анализе каждого нового проекта, непосредственно перед проектированием его дизайна, функционала и информационной архитектуры, для лучшего понимания главной задачи сайта, да и любой информационной системы, очень полезным является «прогонять» сценарии взаимодействия пользователя с системой. Всегда хорошо понимать для кого конкретно ты делаешь сайт, а не просто держать в голове сокращение «ЦА».
Для того что бы сценарий не получался “картонным”, притянутым за уши и заранее заточенным под пожелания, например, дизайнера важно прорабатывать персонажей гораздо более детально чем деление целевой аудитории по половому признаку или финансовому положению, т. к. например персонаж «работающая мать двоих детей» может быть как врачём скорой помощи так и дизайнером-фрилансером. Для создания более объективного и качественного персонажа нужно ответить на следующие вопросы:
В книге «Call to action» посвящённой аналитике проектирования интернет-магазинов предлагается делить характеры персонажей на 4-е категории:
Стоит заметить, что в книге предлагается продумывать характер при написании «продающих текстов», но я считаю, что метод справедлив и для проектирования дизайна, т. к. характер штука глобальная и распространяется на всё. Так же надо помнить, что нет 100%-х представителей того или иного типа характера и представленные типы характеров в большой мере рафинированное обобщение, но для понимания того что движет человеком этого достаточно.
В идеале каждая страничка сайта должна давать то что нужно каждому персонажу с любым характером, т. е. быть достаточно универсальной.
Реальный пример персонажа для проработки дизайна сайта обувного магазина составленный нашим дизайнером:
«Общее описание: Ирина, 35 лет, бухгалтер. По долгу службы проводит много времени за компьютером и довольно неплохо с ним справляется. Склонна методично анализировать поступающую информацию. Как и любая женщина, следит за своей внешностью, однако не любит проводить слишком много времени в магазинах.
Устройство: десктопный компьютер (или планшет).
Цель: найти конкретную модель туфель, узнать наличие в других магазинах.
История: Ирина уже была в одном из магазинов Любимая Обувь, где ей понравились очень милые черные осенние туфли. Но, к сожалению, не оказалось подходящего размера. Дома Ирина решила зайти на сайт и узнать, в каком магазине она может эти туфли приобрести. Набрав в яндексе «любимая обувь» она сразу же попала на главную страницу сайта. К сожалению, Ирина не запомнила ни бренд, ни тем более артикул модели. Поэтому она решила искать через каталог товаров. Нажала «Для женщин», затем «Туфли», после чего увидела, что может отфильтровать обувь по цвету, материалу, сезону и т.д. После выбора нужных фильтров осталось всего 3 пары туфель, одними из которых были те самые черные осенние туфли. Посмотрев фотографии модели с разных ракурсов и убедившись, что это именно та модель, Ирина нажала ссылку «Узнать где купить», увидела список магазинов Любимая Обувь и позвонила в ближайший из них. Менеджер узнала, что пара нужного размера есть в наличии в данном магазине и отложила её для Ирины.
Выводы для сайта: дать ясно понять, что узнать о наличии товара, его цене и т.д., а так же зарезервировать товар можно позвонив в любой розничный магазин Любимой Обуви.»
Для сокращения времени на придумывание сценариев можно заготовить персонажей с фотографиями реальных людей и своим описанием их характеристик чтобы в нужный момент просто доставать нужный шаблон и класть себе на стол для большей визуализации. Пока именно такой практики у нас нет, но думаю мы к ней придём когда накопится достаточное количество разноплановых персонажей.
Используемая литература: «Call to action» (авторы.: Брайан Айзенберг, Джефри Айзегнберг. Издат. «Манн, Иванов и Фербер»)