Денис Нарижный, руководитель интернет-агентства «Студия F1» и создатель сервиса юзабилити-тестирования сайтов AskUsers.ru, рассказал Нетологии о том, как составлять и использовать пользовательские сценарии.
Сценарии описывают пользовательские истории и взаимосвязи между ними. Они помогают определить, зачем и почему пользователи приходят на сайт и как достигают своих целей: совершают покупки, заказывают по телефону, сравнивают товары, общаются с консультантами.
Прежде чем разработать сценарий, нужно ответить на три вопроса:
1. Кто те люди, что заходят на ваш сайт?
Нужно выделить чёткий сегмент аудитории и проработать портрет клиента, под которого готовится сценарий.
2. Почему они заходят к вам?
На основе аналитики или опроса можно определить, зачем на самом деле пользователи посещают ваш сайт: просто посмотреть, что-то узнать или купить.
3. Какие цели при этом преследуют и как их достигают?
Вариантов не так много, особенно если мы говорим о коммерческих сайтах. Обычные цели — изучить предложение с целью сравнить его с другими, непосредственно купить или сделать заказ, но возможны и другие варианты.
Пошагово достижение целей обычно расписывается в профилях задач. Здесь такая детализация не нужна, просто нужно понимать, какие шаги делает пользователь для достижения цели.
Сценарии помогают лучше понимать предпочтения посетителей сайта и анализировать пользовательский опыт. Это нужно, чтобы в дальнейшем проектировать сайт или интерфейс так, чтобы он вписывался в привычные для клиентов паттерны и приводил к цели посещения за наименьшее количество шагов и с минимальными затратами сил, времени и внимания.
Также сценарии используют для анализа пользовательского опыта при проведении юзабилити-тестов и других маркетинговых исследований.
Сценарий — наглядное схематическое представление того, как пользователь решает свою задачу с помощью сайта, что ему помогает и что мешает в достижении цели.
Пользовательские сценарии по степени детализации и технической проработки делятся на четыре группы.
Это самый насыщенный подробностями вариант: рассказ, схемы, видео, фотографии — все, что помогает описать опыт взаимодействия, иногда даже без привязки к персоне клиента. У каждого пользователя может быть своя история и свой специфический опыт. Это сбор сырой информации.
Если мы говорим о покупке: кто-то берет для себя, а кто-то в подарок, кто-то подарит маме, а другой — жене. У кого-то все хорошо с финансами, кто-то собирал деньги на покупку, кого-то интересует кредит и рассрочка. Опыт в этих пользовательских историях будет отличаться.
Запишите простые человеческие истории: «Через месяц у нас юбилей свадьбы, я отложил деньги и собираюсь выбрать подарок жене. У меня есть предел по стоимости, я знаю, что жена любит серебро и носит серьги…».
Вот пример из серии скринкастов: пользователь пытается сделать покупку в интернет-магазине:
Создаются с помощью объединения похожих пользовательских историй и отсечения лишнего и несущественного. Такой подход обобщает множество пользовательских историй в несколько сценариев. Например, таких: «Пользователь готовит деньги заранее, ищет через форму поиска, имеет ограниченный бюджет — сразу использует фильтры, принимает решение долго, несколько раз заходит в корзину и сравнивает товары».
А вот, например, шаги сценария, подготовленные при изучении сайта по аренде автокранов. Пользователи выделили вопросы, которые для них важны, теперь можно расписывать разные сценарии поведения.
Составляются уже с позиции персонажа (персоны покупателя). Еще меньше абстракции и больше конкретики. Каждой группе ЦА сопоставляется персонаж, далее прописывается его путь достижения цели.
Могут добавляться ограничения: например, проработка только варианта заказа с планшета или со смартфона.
Опишите пользовательский опыт по шагам: кто, каким образом и в какой последовательности делает. Это должен быть наиболее детализированный и технически проработанный вариант.
Пользовательские истории и концептуальные сценарии нужны для понимания основных мотивов пользователей и погружения в мир клиента. Конкретные сценарии и варианты использования уже могут использоваться для проектирования информационной архитектуры и интерфейсов, а также при проведении тестов и исследований юзабилити.
Единой формы для разработки пользовательских сценариев не существует. Поэтому итоговый результат может сильно отличаться.
«Общение» пользователя и терминала по приему платежей:
Еще сценарий от uxforthemasses.com:
Показываем на примере «Помощника ОСАГО».
Любое мобильное приложение можно раскритиковать, было бы желание. Но мы так не делаем — слишком велик соблазн докопаться до визуальных решений. Поэтому используем инструменты, которые помогают увидеть продукт целиком и воспринять его глазами пользователя, а не внешнего наблюдателя «про красивенькое». Один из таких инструментов — сценарии.
Легче всего показать силу сценариев в «приложениях одной задачи». Например, в «Помощнике ОСАГО» (iOS, Android), которое помогает водителям оформлять европротоколы. У него всего одна задача, но очень важная. А еще — это приложение с некоторой степенью риска. Пользователь может не дойти до финала, и тогда оба водителя, попавшие в ДТП, потеряют время (мы потратили 40 минут) и будут обязаны вызвать наряд ГИБДД. Сценарий как раз и покажет, удалось ли разработчикам создать стопроцентно проходимый путь.
В общем, почти идеальный для нашего материала случай.
Скажем больше: если вы разрабатываете приложение, выполняющее всего одну задачу, сценария будет достаточно, чтобы начать делать дизайн и даже разработку. А еще — заранее оценить, где пользователю будет неудобно, как он себя поведет на каждом этапе, что ему не пригодится. И все это — сразу, не написав и строчки кода.
В статье мы намеренно выбрали формат диалога, чтобы проявить в сценарии его сущность: протяженность во времени, сложность шагов, риски каждого шага. Поэтому у нас такой разговорный диалог. Вы можете использовать любые другие форматы.
Что мы ожидали от приложения и что получилось?
Мы ожидали, что приложение проведет нас по сценарию из семи пунктов. Вот такой порядок мы представляли.
0. Приложение объяснит, как работает и что от нас понадобится при оформлении ДТП.
1. Приложение расскажет про правила поведения при ДТП, предупредит о необходимых документах и других требованиях к участникам.
2. Предупредит об обязательных условиях, когда мы можем и не можем оформить ДТП онлайн.
3. Попросит документы у обоих участников ДТП.
4. Зафиксирует повреждения.
5. Попросит описать, при каких обстоятельствах произошло ДТП.
6. Проверит всю введенную информацию, попросит подтверждение у обоих участников.
7. Объяснит, что нам делать дальше.
Примерно так и получилось. В приложении реализован именно этот сценарий. Но отличий тоже хватило.
Чем реальный сценарий отличается от вымышленного:
- не хватает сценария обучения, который объяснил бы, как пользоваться приложением;
- участники ДТП неравноправны — один оформляет, другой ждет и нервничает, все ли заполнено верно;
- приложение не предупреждает, что оба водителя должны быть зарегистрированы в «Госуслугах»;
- последний этап оформления ДТП проводится в «Госуслугах», а не внутри приложения.
Это были краткие предварительные итоги. А вот процесс.
0. Обучение
Сценарий, который используется один раз.
Мы установили приложение, сидя дома, и хотим знать, что можно сделать, чтобы быть лучше подготовленным к оформлению ДТП. Вдруг есть какие-то нюансы? А может, мне стоит заранее загрузить все документы в приложении?
Зимой в разбитой машине не хочется тратить время и зарядку, чтобы знакомиться с новым интерфейсом. Лучше подготовиться заранее.
Ожидание
— Я скачал приложение. Надеюсь, оно мне не понадобится, но на всякий случай пусть будет. Чем оно мне поможет?
— Если никто не пострадал, вы собственник и все согласны друг с другом, вы сможете быстро оформить ДТП без вызова ГИБДД.
— Без подводных камней?
— Есть одна мелочь: вы должны быть зарегистрированы на «Госуслугах».
— А как оформиться?
— Сделайте вот это.
— А как с документами? Что нужно заполнить?
— Вот документы, которые нужны от вас, вот форма для информации, сюда загрузите фотографии.
— И все, смогу уехать и получить деньги?
— Не совсем, нужно будет написать обстоятельства ДТП на «Госуслугах».
— Хорошо, зарегистрируюсь, пожалуй.
Реальность
Никакого обучения в реальности нет.
Этот сценарий разработчики не отработали.
1. Информированное согласие
Ожидание
— Я попал в ДТП.
— Оформлять будете?
— Да.
— Давайте проверим, что вы сможете это сделать через приложение. Ваше ДТП такое-то и такое-то?
— Да.
— Второй участник готов участвовать в оформлении через приложение?
— Да.
— У вас у обоих есть доступ к «Госуслугам»? Проверьте, кстати.
— Проверили, есть.
— Достаньте бумаги. Понадобятся права, полис страхования и что-то там еще. Всё есть?
— Да, всё есть.
— Проверим технические условия: у вас у обоих должны быть смартфоны с интернетом и работающей фотокамерой.
— Есть.
— Вы понимаете, что нельзя никуда уходить и перемещать автомобили, пока я не скажу?
— Да.
— Если что-то пойдет не так (например, у кого-то сядет батарейка), вам все-таки придется вызвать ГИБДД. Согласны?
— Угу.
— План такой: сначала то-то сделаем, потом то-то, а в конце то-то. Поехали?
— Да.
Реальность
В приложение можно войти только через аккаунт в «Госуслугах». По-другому — никак. Это означает, что, если у вас нет подтвержденного аккаунта, воспользоваться «Помощником» вы не сможете. Зарегистрироваться на ходу не получится — сперва данные должны проверить в ФМС РФ и Пенсионном фонде РФ.
Для удобства приложение сразу спрашивает права и ОСАГО. Этот этап можно пропустить — потом попросит еще раз. Но если вы при входе заполнили данные, они сами подставятся в поля позже.
Приложение разделено на три вкладки. Центральная вкладка — оформление ДТП. Нажимаем на нее — приложение просит доступ к геопозиции, а потом предупреждает, что работает не везде. Затем сразу начинается транзакция.
Отличия от сценария
- Непонятно, будет ли участвовать в оформлении второй участник ДТП.
- Неизвестно, какие понадобятся данные.
- Про смартфоны и камеры приложение не предупреждает. А вдруг у одного из участников старый телефон или разбита камера?
- Что делать сейчас и что понадобится сделать во время оформления, ни слова.
- Приложение не предупреждает, что у второго участника тоже должен быть подтвержденный профиль на «Госуслугах». Иначе все зря. Но мы узнаем об этом позже.
Главное отличие — в этом этапе не участвует второй участник ДТП. Мы оформляемся, а он стоит рядом и нервничает. Вдруг мы как-то его обманем? Может, обстоятельства ДТП опишем неправильно? Или оформим неверно, а потом окажется, что оба покинули место ДТП.
2. Старт транзакции
Транзакция — это группа последовательных операций. Она прерывается, если не выполнено условие любой из операций.
В нашем случае транзакция — это согласие двух водителей с обстоятельствами ДТП. Если кто-то из них не согласен хотя бы с одним условием, оба не смогут воспользоваться приложением.
Ожидание
— Вот код вашего ДТП. Он понадобится для разного. На всякий случай сохраните. Но сейчас важно другое: попросите второго участника присоединиться к оформлению ДТП по этому коду.
— (1) Прошу.
— (2) Присоединяюсь.
— Порядок. Все в сборе. Теперь назначим крайнего. Кто из вас виноват в ДТП?
— (1) Я виноват.
— (2) Ага, он виноват.
— Договорились.
Реальность
Приложение проводит транзакцию.
- Просит подтвердить, что собственниками автомобилей являются физические лица и у водителей, попавших в ДТП, нет разногласий в отношении происшествия.
- Предупреждает, что надо включить аварийную сигнализацию, выключить двигатель и поставить знак аварийной остановки.
- Спрашивает, пострадал ли кто-нибудь в ДТП.
- Удостоверяется, что в ДТП участвуют только два автомобиля, не пострадали третьи лица и их имущество, а у водителей нет разногласий по поводу обстоятельств ДТП, в том числе и видимых повреждений автомобилей.
После этого приложение переходит к документам.
Отличия от сценария
Отличий нет. Приложение ведет себя именно так, как мы и ожидали.
3. Документы участников
Ожидание
— Пожалуйста, введите оба информацию из водительских прав.
— (1) (2) Вводим.
— ОК. Теперь — информацию о страховом полисе.
— (1) (2) Вводим.
— Проверяю… Да, вся информация корректна, можем двигаться дальше.
Реальность
Приложение предупреждает, что карточка участника А будет отмечаться желтым цветом, а участника Б — синим. Становится понятно, что оформлять ДТП будут оба водителя.
Если вы не ввели документы при входе, приложение потребует их на этом шаге. ФИО, дату рождения и права нужно ввести руками, а вот ОСАГО можно загрузить, если отсканировать QR-код на страховке. Приложение сразу проверит, зарегистрирован ли полис в базе РСА и есть ли совпадения данных по транспортному средству.
Потом все то же самое нужно сделать за участника Б: ввести его ФИО, дату рождения, права и страховку в своем смартфоне. Приложение попросит скинуть специальную ссылку участнику Б, чтобы тот подтвердил верность данных у себя на смартфоне. Можно показать QR-код. По этой ссылке участник Б перейдет на портал ЕПГУ, где ему сперва понадобится авторизоваться и только потом подтвердить, что его данные ввели верно.
Затем приложение просит указать время и место ДТП, указать свидетелей, дать общий план их автомобилей, фотографии госномеров, ФИО, места жительства и номера телефона.
Отличия от сценария
- Участник А должен заполнять информацию за двоих — это может нервировать участника Б, потому что неизвестно, что он там напишет.
- Участник Б тоже должен быть зарегистрирован на «Госуслугах» — это сюрприз.
Потом приложение просит оформить свидетелей.
4. Повреждения автомобилей
Ожидание
— Теперь прошу каждого зарегистрировать повреждения своих автомобилей. Нужны будут фотографии и названия деталей. Вот инструкция, как это сделать, будьте внимательны. Если тут ошибетесь, будет то-то и то-то.
— (1) и (2) Фотографируем, вводим буковки… Уф, вроде всё.
— Посмотрите, что получилось. Все верно?
— (1) и (2) Ну, по моей машине все верно.
— А машины друг друга проверьте еще, пожалуйста? Вот информация.
— (1) и (2) И тут все верно.
Реальность
Приложение просит участника А:
1) выбрать поврежденные детали;
2) сфотографировать каждое повреждение;
3) сфотографировать регистрационный знак;
4) сфотографировать общее расположение автомобилей на фоне неперемещаемой окружающей инфраструктуры.
Приложение без предупреждений отправляет фото в Российский союз автостраховщиков.
Затем то же самое делает участник Б на смартфоне участника А: указывает поврежденные детали и фотографирует свой автомобиль.
Приложение не просит обоих участников ДТП подтверждать заполненные данные.
Отличия от сценария
- Участник Б должен пользоваться смартфоном участника А.
- Приложение не просит участников подтвердить повреждения.
- Неизвестно, что произойдет, если кто-то неправильно зафиксирует повреждения.
5. Обстоятельства
Ожидание
— Теперь нужно написать много букв для страховой: как обгонял, как подрезал… Делать нужно правильно и аккуратно, а не то будет то и это. Вот кое-какие пояснения.
— (1) и (2) Пишем. Написали.
— Проверяю… И правда написали. Теперь друг друга проверьте.
— (1) и (2) Всё так, всё так.
Реальность
Приложение переносит участников в «Госуслуги» и предлагает проверить данные именно на портале. То есть переносит из этапа «Повреждения автомобилей» в «Проверку данных». На той же странице можно описать обстоятельства ДТП.
Отличия от сценария
- На этом этапе приложение не дает участникам А и Б проверить, кто как описал обстоятельства ДТП.
- Приложение не объясняет и не подсказывает, как правильно описывать обстоятельства ДТП.
6. Проверка данных
Ожидание
— Так, ну вот всё, что вы понаписали. Одной простыней. Нужно «угу» от каждого — ну или желание поменять что-то. Подтверждайте или меняйте?
— (1) и (2) Да верно всё.
Реальность
Каждый участник на своем смартфоне переходит в «Госуслуги» и видит большое полотно текста со всеми введенными данными.
В полотне есть пустые поля — можно что-то дописать и добавить обстоятельства ДТП.
Мы закончили на этом этапе — не рискнули оформлять ДТП на государственном портале, в котором пользователи авторизуются по паспорту.
7. Инструкция по дальнейшему
Ожидание
— Ну класс. Теперь я буду пережевывать всю эту инфу. А вы уже можете идти в страховую вот с этим волшебным кодом. Кстати, прислать вам код и все заполненные анкеты по почте, например? На какие адреса?
— (1) и (2) Сюда присылай.
— Отправила. Всё. Можете ехать по своим делам.
Реальность
<…>
До этого этапа мы не добрались.
А выводы?
В начале статьи мы задались целью показать, как использовать сценарии для оценки и создания приложений. У нас не было задачи найти все возможные ошибки в «Помощнике ОСАГО».
Наш сценарий — это то, что мы ожидали от приложения. Разумеется, мы не претендуем на единственное правильное мнение. Да и вообще на правильное. И да, мы могли придумать другой сценарий. Но взяли этот для примера.
Главное, что мы хотели сказать: фиксировать сценарий — важно.
Вот как еще можно использовать сценарий.
- Узнать, чего от приложения хотят пользователи и как они им будут пользоваться.
- Убрать все лишнее и второстепенное. Каждый раз, когда кто-то предлагают идею в духе «А давайте еще сделаем вот это», можно сверить ее со сценарием и спрогнозировать, как на конкретном этапе изменится поведение человека.
-
Начать создавать продукт, не привязываясь к технологиям. Например, сценарий может показать, что вам можно не заморачиваться с разработкой приложения и создать чат-бота.
-
Включить фантазию. Когда команда знает, какую задачу и каким образом выполняет их продукт, она может искать эффективные решения, и не только интерфейсные.
-
Подготовиться к разработке. Все в команде представляют, что у них должно получиться. Поэтому можно начинать заранее, не дожидаясь, пока коллеги закончат свой этап работы.
-
Заменить им тестирование продукта. Пройтись по сценарию и посмотреть, где возникают трудности.
А вывод такой: для «приложений одной задачи» сценарий — важный этап работы над продуктом. Возможно, даже главный. И уж точно — один из самых-самых первых.
Центром любого дизайн-проекта является пользователь.
Мы создаем продукты, основываясь на том, что знаем о пользователях, даже если это противоречит нашему собственному мнению или представлениях об идеальном дизайне. Как? Благодаря различным методам исследования пользователей, таким как пользовательские сценарии.
Чтобы понять, как этот метод изучения пользовательского опыта (User Experience, UX) реально помогает создавать удобные интерфейсы, рассмотрим несколько основных моментов, включая определение пользовательских сценариев, их роль в UX-дизайне, отличие от пользовательских историй и многое другое.
Содержание статьи
Что такое пользовательские сценарии?
Зачем нужны сценарии?
Как создать пользовательский сценарий
Отличие пользовательского сценария от пользовательской истории
Привлекаем команду контроля качества
Заключение
Что такое пользовательские сценарии?
По сути, пользовательские сценарии (User Scenarios) — это короткие рассказы о пользователях, представленных в виде образов идеальных пользователей (персон), пытающихся достичь своих целей в своем контексте в ходе взаимодействия с вашим сайтом или приложением. Как правило, сценарии разрабатываются для продуктов и сервисов, только планируемых к запуску.
Создание сценариев требует особого мышления: необходимо сосредоточиться на целях пользователей. Чего они будут пытаться достичь на вашем сайте или в приложении? Будет ли ваш продукт им полезен? Также важно подумать о сопровождающем их контексте (нюансы поведения и использования продукта, условия, влияющие на UX), их предыдущих знаниях и опыте.
Пользовательские сценарии не представляют всех возможных пользователей. Вместо этого они обычно учитывают только самые распространенные персоны и их мотивации. Хорошие сценарии включают контекст и детализацию, чтобы быть как можно более точными и связными.
Чтобы представлять целевых пользователей в максимально реальном виде, сценарии должны исходить из четкого понимания того, с кем вы будете иметь дело, — требуется исследование, проведенное с существующими или потенциальными пользователями. Работая с хорошо продуманными сценариями, наполненными реалистичными персонами, команда разработчиков сможет выявить ранее неизвестные проблемные области и затем исправить их.
Зачем нужны сценарии?
Пользовательский сценарий — это вымышленная история о том, как пользователь выполняет действия или достигает своих целей с помощью вашего продукта. Сценарий обращает особое внимание на мотивацию пользователя в ходе взаимодействия с дизайном и документирует особенности поведения на сайте. В итоге дизайнеры получают набор полезных соображений, которые могут стать основой для выработки новых идей и юзабилити-тестирования.
Визуализация того, как юзер будет использовать продукт или услугу, весьма полезна на этапе идейной разработки проекта. На такой ранней стадии гибкость, которую эти сценарии предлагают воображению дизайнера, огромна. Благодаря этому можно расширить потенциал дизайна в плане его универсальности и даже выйти за рамки того, что предлагается на рынке.
Пользовательские сценарии также применяются для определения наиболее важных для юзабилити-тестирования областей, они позволяют понять, как именно должен проводиться каждый тест.
Благодаря сценариям мы можем определить:
- наиболее важные моменты, на которые нужно обратить внимание в процессе разработки UX;
- какие этапы процесса потребуют от вас дополнительной помощи вашим пользователям;
- основные потребности и мотивы ваших пользователей.
Как создать пользовательский сценарий
Как вы уже поняли, предварительным условием является создание персон. Разработав образы идеальных пользователей, вы можете переходить к следующему плану:
1. Решите, какие сценарии создавать, отталкиваясь от наиболее значимых действий каждого вида персон.
2. Напишите правдоподобную историю, содержащую:
- сюжет (триггеры, действия, достигнутая цель);
- контекст использования (где? когда? каковы окружающие пользователя условия?);
- мотивации, причины;
- ответ на вопрос: как продукт/сервис помогает достигнуть конечной цели?
3. Отойдите от решений относительно пользовательского интерфейса (User Interface, UI). Суть не в этом. Главное — это опыт персон, что они чувствуют, видят, делают, о чем думают.
4. Постарайтесь избегать далеких от реальности предположений. Ориентируйтесь на то, что в данной ситуации сделал бы реальный пользователь.
5. Уберите все, что не вписывается в сценарий.
Пользовательский сценарий должен сосредотачиваться не только на взаимодействии с продуктом, но и на других вещах, которые происходят во время этого взаимодействия. Он может включать культурную информацию, контекст и описание обстоятельств, которые побуждают использовать продукт или приложение. Например, сценарий описывающий применение мобильного приложения, будет содержать информацию о том, что устройство используется, когда пользователь находится в поезде, или что действие прерывается входящим вызовом. Подобная информация помогает разработчикам адаптировать дизайн, исходя из целей улучшения пользовательского опыта и юзабилити.
Написав сценарий, вы можете на его основе начать определять требования к дизайну приложения.
Почему компании так боятся поговорить со своими клиентами?
Отличие пользовательского сценария от пользовательской истории
Следует отметить, что сценарии создаются, исходя из пользовательских историй (User Stories), коротких утверждений, описывающих, что нужно определенной персоне и почему. Сценарии выводят пользовательские истории на новый уровень, добавляя к истории подробности взаимодействия с продуктом или услугой.
Пользовательские истории:
- короче (как правило, одно предложение), не содержат деталей о пользователе и его прошлом опыте, мыслях и мотивациях;
- с точки зрения пользователя описывают некую потребность, которая должна удовлетворяться вашим продуктом;
- представлены прямой речью самого пользователя.
Пример истории: «Как любитель кино, я хочу, чтобы на моем смартфоне была вся информация о предстоящих премьерах в местных кинотеатрах, чтобы мне не приходилось проверять сайты каждого из них по отдельности».
Хорошо написанная пользовательская история — это скелет любого проекта по дизайну UX, а сценарий — это его мышцы. Вместе они помогают создать надежный продукт, успешно решающий проблемы пользователя и вызывающий чувство удовлетворения.
Отличие сценария от примера использования
Пример, или кейс, использования (Use Case) — это, скорее, технический план, чертеж проекта, в центре которого находятся функции, а не чувства и мысли. Кейсы представляют собой список действий при взаимодействии человека с системой.
Привлекаем команду контроля качества
Над пользовательскими сценариями обычно работают координатор или менеджер проекта, а также UX- и UI-разработчики. Специалисты по контролю качества (QA, Quality Assurance) или, попросту говоря, тестировщики привлекаются не всегда, хотя именно они знают каждый кейс и каждое условие (позитивное или негативное) с точки зрения пользователя. С их помощью вы будете писать более точные сценарии.
Когда речь заходит о сценариях, обычно это означает необходимость протестировать продукт или данные. Вам нужно убедиться, что ваш продукт готов, прежде чем вы сделаете его доступным широкой публике. Тестировщики должны стать вашими первыми клиентами. Перед началом тестирования такому профессионалу нужно передать максимум информации о продукте и как можно больше сценариев.
Почему этот шаг действительно важен?
Ваш продукт попадет в руки многих людей. Существует много способов использования продукта или сервиса, и вы должны подготовить все возможные сценарии. Не только QA, но вообще каждый профессионал, участвующий в разработке, должен осознавать важность пользовательского сценария. Сценарии помогают вам генерировать идеальное решение проблем и делать хорошие, по-настоящему полезные продукты.
Каждый участник команды должен представить себя на месте пользователя. Не одного пользователя, а многих, разных пользователей. Как только все вживутся в роли, переходите к следующим шагам:
1. Изучите своих пользователей, их привычки и потребности.
2. Начните сами использовать продукт всеми возможными способами. Представьте, что вы и есть тот самый пользователь, который при этом хочет сделать что-то на вашем сайте или в приложении.
3. Разбейте процесс на несколько частей. Например, создайте пользовательские сценарии для случаев входа в систему и для оплаты или добавления товаров в корзину.
4. Разделите каждый сценарий на позитивный и негативный вариант. Возьмем попытку входа в качестве примера. Позитивный кейс: ввод пользователем имени и пароля, приводящий к успешному входу в систему. Негативный: пользователь забыл свой юзернейм и не смог войти в систему.
5. Придумайте как можно больше негативных кейсов. Такой подход позволяет обнаруживать больше пробелов.
6. Подключите всю команду. Попросите всех ваших коллег собраться вместе, составить список сценариев и завершить их с помощью продукта. Наличие разнообразных точек зрения поможет при дальнейшей разработке.
7. Создайте карту сценариев — документ, содержащий все ваши сценарии, тогда вы избежите повторений. На такой карте будет удобно наблюдать все имеющиеся сценарии и отмечать те, которые вы уже проработали.
8. Подумайте о том, как помочь пользователям следовать обозначенному вами сценарию. Experrto — это платформа для адаптации пользователей к интерфейсу и взаимодействию с вашим продуктом. С помощью индивидуально настроенных визуальных интерактивных подсказок Experrto позволяет выстроить онбординг таким образом, чтобы пользователь мог максимально эффективно добиться своей цели на сайте и завершить свой сценарий.
Прежде чем приступить к дизайну пользовательского пути, дизайнер накидывает базовый сценарий. Затем приглашает QA-специалистов для окончательной его проработки. Шаги повторяются до тех пор, пока вы не получите завершенный пользовательский сценарий — лишь затем можно переходить к следующим стадиям разработки.
Убедитесь, что вы следуете всем пунктам из представленного выше алгоритма, уделяя особое внимание негативным кейсам.
Разработка личного кабинета пользователя: улучшаем интерфейс
Заключение
Пользовательские сценарии важны, поскольку они позволяют экспертам по юзабилити и разработчикам проникнуть в сознание потенциальных пользователей. В сценариях основное внимание уделяется потребностям людей, а не аспектам дизайна. Еще одним преимуществом пользовательских сценариев является то, что они написаны на языке, который понимают все члены команды, независимо от специализации.
Изучите все возможные точки зрения. Разбирайте отдельные моменты снова и снова, фиксируя в своих заметках полученные инсайты. К этому и сводится процесс создания сценариев, пользовательских историй и примеров использования.
Подписывайтесь на нашу группу в фейсбуке и канал в телеграм, чтобы следить за обновлениями.
Прокачайте свой онбординг!
По материалам: interaction-design.org , uxknowledgebase.com , uxplanet.org
Как написать пользовательский сценарий?
Во-первых, стоит сказать, что интерфейс – не для заказчика, и не для вас. Интерфейс для человека, который будет им пользоваться и иногда бывает так, что сделанная вами работа нравится только вам и через пару часов или дней и это ощущение проходит. То есть картинки по началу нравились, потому что вы влюблены в проект, но ощущение пропадает, потому что вы спустя какое-то время начинаете уже менее влюбленно на него смотреть и понимаете, что за ним нет никакого смысла, пользы, а проста пустота, картинки и ничего больше.
Сценарий–это сжатое описание способов применения интерфейса для достижения цели. Сценарий нужен, чтобы сформулировать тот стержень, который будет в вашем продукте.
Из чего состоит сценарий:
- Цель, которую мы преследуем.
- Основной сценарий.
- Альтернативные сценарии, дополнительные.
- Конечный результат.
Не буду рассказывать теорию, я об этом рассказываю в курсе. Сейчас просто на конкретном примере я поясню и расскажу как пишется сценарий.
Во-первых, на примере приложения для РЖД(рис.1)
Цель этого приложения — попасть на поезд без бумажного билета.
Рис.1 Приложение РЖД
Рис.2. Шаг первый
Кстати, рекомендую посмотреть прямо сейчас:
Все начинается с того, что человек просто покупает билет на сайте РЖД (рис.2).
Рис.3 Шаг второй
Следующим шагом пользователь должен увидеть эту поездку в приложении (рис.3). Он видит активные элементы, с датами, городом и временем.
Рис.4. Шаг третий
Дальше на человек на вокзале должен найти свой поезд, путь и вагон (рис.4). Видно поезд, время, путь (определяется непосредственно на вокзале), вагон, место. То есть человеку не нужно распечатывать и доставать бумажные билеты и вся информация, которая ему нужна в данной ситуации видна на экране.
Рис. 5 Альтернативный сценарий
Во-вторых, может быть альтернативный сценарий (рис.5). Человек может захотеть вызвать такси до вокзала и здесь есть ссылка на такси. И может получить push-уведомление, чтобы не пропустить поезд за какое-то время.
Рис.6 Шаг четвертый
Дальше, следующий шаг по основному сценарию. Человек у вагона может показать проводнице штрих-код, чтобы проводница прямо с экрана телефона может считать этот штрих-код, провести идентификацию и пропустить человека дальше в поезд.
Рис.7 Шаг пятый
Дальше мы уже в поезде. Человек может найти свое место в поезде.На последнем экране, что важно (рис.7).
Рис.8 Шаг шестой
Есть альтернативный сценарий (рис.8). То есть мы заботимся о человеке больше и думаем не только о том, как ему добраться до дома, т.к. это его конечная цель, в свою квартиру, отель и т.д. И мы даем альтернативный сценарий: сообщить по смс друзьям,родственникам, что все ок и где, во сколько будет встреча. Можно вызвать такси с вокзала. И подключить вайфай. То есть заботимся о человеке чуть больше, делая следующий шаг. И даем ему с комфортном добраться домой (рис.9).
Рис. 9 Шаг седьмой
Важно развивать лишь те сценарии ,которые позволяют продвигаться вперед и не плутать в излишних деталях.
Здесь (рис.9) немного деталей, некоторый вещи можно еще глубже детализировать (каждый альтернативный сценарий,например). Сценарий не должен быть громадным и подробным, необходимо помнить про ключевые точки. Помнить о контексте, откуда человек попадает в приложение, где она находится в данный момент, в какой ситуации. Наше приложение не кончается на поиске места в вагоне, а помнит о следующем шаге.
Сценарий –стратегия. Описывайте ключевые точки процесса глобально, от начала до конца.
Когда какая-либо IT-компания начинает разработку программного продукта, ей приходится задумываться о том, как быстрее и проще начать реализацию проекта и создать прототип, с помощью которого можно передать все функциональные возможности ПП. Что такое Use Case, для чего он нужен, чем он может помочь в разработке — расскажет наша статья.
Что такое Use Case
Use Case — это сценарный план взаимодействия пользователя с программным продуктом, в котором четко прописаны шаги для достижения того или иного результата. Последовательность действий, при этом, может быть расписана не для одного, а для нескольких юзеров.
В юзеркейсах для программных продуктов прописываются разные манипуляции. Это может быть покупка товаров через мобильное приложение, отправка данных, рассылка электронных писем и так далее.
Главной задачей юзеркейса является улучшение коммуникации среди членов команды при разработке программы или мобильного приложения. Пишутся эти кейсы на этапах проектирования и при планировании внедрения каких-либо функций.
Вообще, отвечать за составление юзеркейсов должны системные аналитики, имеющие опыт в ведении переговоров с заказчиками и проведении анализа ЦА. Но так как у многих компаний бюджет не всегда позволяет нанимать для этого сторонних специалистов, разработкой Use Case могут заниматься тестировщики, дизайнеры, разработчики ПП и даже продакт-менеджеры.
В каких ситуациях может помочь Use Case
Грамотно составленный юзеркейс может помочь в тех случаях, когда:
- при проведении подготовительных работ разработчики не могут правильно составить ТЗ;
- после долгих обсуждений функциональных возможностей команда отклонилась от первоначальной идеи продукта;
- команда разработчиков неправильно поняла начальный сценарий взаимодействия юзера и ПП;
- команда разработчика неправильно внедрила ту или иную функцию;
- в процессе тестирования программы появляется много непредвиденных ошибок;
- к команде подключились новые специалисты, которых нужно в кратчайшие сроки посвятить в курс дела.
Также Use Case незаменим в тех случаях, когда один и тот же кейс по-своему реализован в разных местах, тем самым затягивая процесс разработки ПП.
В чем польза юзеркейса
Качественно составленный Use Case может решать разные задачи. Например:
- облегчение коммуникации между разнопрофильными членами команды (дизайнеры, тестировщики, разработчики, менеджеры, аналитики);
- фиксирование принятых решений, что позволяет в дальнейшем не сбиваться с курса;
- быстрое возвращение к заданному сценарию с целью проверки его корректности на разных этапах разработки;
- упрощение порядка передачи информации между членами команды;
- определение самых важных аспектов сценария взаимодействия.
Use Case играет важную роль, когда необходимо подготовить прототип ПП, который покажет особенности и преимущества проекта.
Из каких элементов состоит Use Case
В зависимости от сложности сценария, юзеркейсы могут содержать порядок действий следующих лиц:
- Actor — человек, который пользуется созданной системой. В качестве примера можно привести какой-нибудь интернет-магазин, где в качестве actor выступают продавцы, покупатели, поставщики и все те, кто взаимодействует с этим интернет-магазином.
- Primary actor — это человек, у которого получается достигнуть поставленных целей с помощью созданного программного продукта. Если вернуться к тому же интернет-магазину, то primary actor в нем может быть производитель вещей, у которого получается реализовывать эти вещи с помощью функционала онлайн-площадки.
- Stakeholder — человек, который заинтересован в том, чтобы созданы ПП выполнял те или иные действия. В интернет-магазине это может быть какой-нибудь партнер, получающий доход от приведенных покупателей, или подключенная к магазину платежная платформа, через которую совершаются онлайн-платежи.
Также к элементам юзеркейса относятся:
Арбитраж трафика на крипту [2022] — ОПРОС ЭКСПЕРТОВ
- понятный заголовок, содержащий конечный результат Use Case;
- описание последовательности действий;
- результат, к которому должен привести юзеркейс;
- предусловия — это то, что должно произойти до или после запуска кейса;
- триггеры, влияющие на запуск кейса.
А еще в любом Use Case должны быть прописаны альтернативные пути — события, к которым прибегают в том случае, если кейс не сработал.
Какими должен качественный быть Use Case
Высокое качество юзеркейса определяют следующие критерии:
- Правильная детализация. При составлении Use Case нет смысла описывать каждый шаг пользователей и состояние элементов ПП в этот момент. Главная задача юзеркейса — всего лишь дать общую картину.
- Простота изложения. Чтобы содержимое юзеркейса было понятным даже новым членам команды, его необходимо писать максимально простым языком. Не стоит использовать для Use Case сложные термины и вставки кода.
- Единый стиль. Старайтесь использовать для всех юзеркейсов один и тот же шаблон. Это поможет сэкономить время на изучении ПП.
- Важен контекст. В каждом юзеркейсе должны быть уточнения по поводу тех или иных действий. Так разработчики смогут разобраться в том, какая задача перед ними стоит.
- Целенаправленность. Не стоит использовать юзеркейса для того, чтобы описать весь путь пользователя. Лучше представить конкретные шаги (регистрация, покупка, отправка заявки и так далее).
Когда сценарий будет обновляться, не стоит забывать о своевременном внесении изменений в юзеркейс.
Какую пользу несет Use Case для определенных специалистов в команде
Для каждого из участников команды юзеркейс несет свою ценность. Например, для заказчика Use Case полезен тем, что на простой языке отображает конечную бизнес-ценность. Как правило, сценарий взаимодействия составляется таким образом, чтобы даже далекие от программной разработки пользователи могли понять, что написано в кейсе. Чем проще для заказчика будет составлен юзеркейс, тем быстрее он с ним ознакомиться и даст добро на продолжение разработки.
Для разработчика же ценность заключается в другом. В первую очередь речь идет о структурированных блоках информации, что упрощает создание ПП. Особенно это касается сложных проектов с жесткими требованиями. Также структурированная информация привязывается к конечному результату, благодаря чему разработки гораздо проще понять, что должно получиться в итоге.
Польза в юзеркейсах есть и для разработчиков. Во-первых, благодаря Use Case они могут тестировать программные продукты по заранее заданному сценарию. Это экономит время и избавляет от необходимости искать способы проверки на ошибки. Во-вторых, грамотно составленный кейс помогает находить в программе минусы, которые вряд ли удастся найти с помощь unit-тестирования.
Как составить Use Case
Как говорилось ранее, составлять юзеркейсы нужно на этапах проектирования ПП. Также кейс пересматривается в тот момент, когда команда начинает внедрять новые или улучшать уже имеющиеся фичи. При этом писать юзеркейсы стоит только после того, как будет составлен путь пользователя.
Чтобы составить юзерйкейс, необходимо выполнить следующие действия:
- В первую очередь определяем, какие пользователи будут работать с программным продуктом. Помочь в этом может обычный анализ рынка и ЦА.
- Выявляем определенную группу пользователей, которые будут работать с ПП.
- Рисуем портрет группы пользователей и приблизительно определяем, что они будут делать разрабатываемой программе. Каждое действие в рамках ПП — потенциальный Use Case.
- Определяем последовательность действий для каждого юзеркейса.
- Приблизительно описываем основной путь пользователя.
- Прогнозируем ответ системы на действия пользователя.
- Разрабатываем альтернативные пути для расширения юзеркейса.
- Повторяем перечисленные шаги для каждой группы пользователей.
Есть пара советов, которые помогут в составлении юзеркейсов. Во-первых, для экономии времени следует разработать шаблон. Такой подход позволит выработать единый стиль и экономить время при разработке других кейсов.
Во-вторых, если идет работа над Use Case под узкоспециализированный продукт, тогда необходимо разработать словарь с терминами. Также это может помочь в том случае, когда члены команды часто используются определенные термины, требующие расшифровки.
Чтобы читатели могли ознакомиться с приблизительным видом кейсов, мы решили разобрать несколько примеров.
Пример 1: регистрация на сайте
Результат кейса: пользователь создает аккаунт с личным кабинетом.
| Номер шага | Действующее лицо | Действие |
| 1 | Пользователь | Пользователь нажимает на кнопку регистрации |
| 2 | Система | Открывает форма регистрации |
| 3 | Пользователь | Пользователь заполняет форма, указывает данные, подтверждает регистрацию |
| 4 | Система | Идет проверка корректности заполнения, пользователь вносится в базу данных, на почту отправляется письмо со ссылкой для активации акк |
| 5 | Пользователь | Пользователь открывает письмо, переходит по ссылке |
| 6 | Система | Система активирует аккаунт, высылает инструкцию по работе с сервисом |
Это из самых простых кейсов. Как правило, большая часть юзеркейсов имеют более сложно схему взаимодействия.
Пример 2: регистрация в интернет-магазине по сложной схеме
- цель: зарегистрироваться в интернет-магазине;
- действующее лицо: незарегистрированный пользователь;
- триггер: пользователь увидел рекламу интернет-магазина и решил зарегистрироваться;
- результат: у пользователя появляется аккаунт с бонусной системой.
Шаги юзеркейса выглядят следующим образом:
- Пользователь нажимает на кнопку регистрации.
- Система открывает форму регистрации, запрашивает контактные данные и платежные реквизиты.
- Пользователь заполняет поля, отправляет на проверку.
- Система проверяет инфу на корректность, вносит пользователя в базу, отправляет письмо со ссылкой активации.
- Пользователь открывает письмо, переходит по ссылке.
- Система активирует аккаунт.
Также может указываться переход к юзеркейсу. Например, с главной страницы.
Пример 3: кейс по взаимодействию с сайтом вуза на примере диаграммы
Некоторым специалистам проще делать юзеркейсы в виде диаграммы. Они удобны и практичны, однако в них нельзя отследить последовательность действий. Один из примеров – диаграмма юзеркейса, в котором прописаны шаги разных групп пользователей в рамках сайта ВУЗа.
Как видно на рисунке, студенты могут просматривать темы и записываться на курсовые проекты. Руководители могут просматривать уже имеющиеся и вносить новые темы. Система же отвечает за предоставление информации и внесения указанных сведений в базу данных.
Эксперты отвечают
ССергей Галоген
Что такое сценарий Use Case?
Сценарий или спецификация ВИ (use case scenario or specification) – тестовое формальное описание последовательности действий, которые происходят внутри ВИ для достижения некой цели актера.
ЮЮрий Булуй
Можно ли считать юзеркейс фукнцией?
ВИ – это не функция, это некая последовательность действий, которая приносит пользу для основного актера, инициирующего данный ВИ. ВИ – это скорее цель Пользователя, чем отдельная функция. ВИ теоретически может быть разбит на несколько функций, и как правило не является одной лишь функцией.
Вывод
Use Case — это инструмент, созданный для упрощения взаимодействия с разрабатываемым ПП. Перед созданием этого инструмента стоит тщательно изучить все материалы, заранее подготовить список разделов и обсудить все шаги с членами команды. Если юзеркейс будет составлен правильно, появится возможность не только наладить коммуникации, но и упростить процессе ведения технической и пользовательской документации.
Приходилось сталкиваться с Use case?
1 голос
Да — 100%
Нет — 0%
Пользовательские сценарии рассказывают об историях и образах покупателей, взаимосвязях между юзерами и позитивным клиентским опытом. Благодаря сценариям можно понять, почему люди попадают на сайт и как достигают своих целей: совершают покупки, делают заказ по телефону, сравнивают товары, разговаривают с консультантами.
Как разработать пользовательский сценарий для вашего продукта — разбираемся.
Что такое пользовательские сценарии
Пользовательский сценарий (User Scenario) — это схема, которая позволяет определить, почему покупатели оказываются на сайте и как реализуют свои планы с помощью вашего продукта.
Чаще всего такие сценарии создаются в формате коротких рассказов о некоем эталонном пользователе, цель которого — удовлетворить свою потребность посредством вашего сайта или приложения.
Чтобы создать сценарий, необходимо сфокусироваться на образе вашего пользователя. Кто он? Какой у него характер, бэкграунд, зачем он пришел на веб-ресурс? Как будет вести себя на сайте, с какой страницы начнет, на что будет нажимать? Продумать все вероятные линии поведения клиента невозможно — поэтому пользовательские сценарии, как правило, учитывают образы и мотивации юзеров, которые часто встречаются в определенной сфере.
Важно! Сценарии пишутся до этапа техработ по созданию сайта/приложения, они сфокусированы на действиях и потребностях пользователей. Техническим нюансам (стекам, инструментам, интерфейсу) в этом процессе места нет.
Зачем нужны пользовательские сценарии?
- изучить и лучше осознавать предпочтения юзеров
- анализировать пользовательский опыт
- спроектировать интерфейс так, чтобы он соответствовал традиционным для клиентов паттернам и позволял достичь цели, потратив минимум сил и времени
- найти самые важные моменты, которые необходимо учесть в ходе разработки UX
- определить, на каких этапах процесса пользователям потребуется дополнительная помощь
- понять ключевые потребности и побуждения клиентов
Хотите получать дайджест статей?
Одно письмо с лучшими материалами за неделю. Подписывайтесь, чтобы ничего не упустить.
Спасибо за вашу подписку!
Важно! Сценарий описывает текущую ситуацию. Но уже в процессе его создания у вас возникнут идеи, которые позволят улучшить юзабилити продукта — упростить, добавить новые функции или подсказки.
Какими бывают пользовательские сценарии
Самая популярная классификация пользовательских сценариев принадлежит Дэвиду Беньону, Сьюзан и Филу Тернерам, авторам учебника по взаимодействию компьютера и человека (HCI — human-computer interaction).
В книге Designing Interactive Systems — People, Activities, Contexts, Technologies они выделяют 4 вида сценариев:
- пользовательские истории
- концептуальные сценарии
- конкретные сценарии
- варианты применения
Визуализировать это разделение можно так:
Чтобы проработать в пользовательском сценарии все важные для покупателя моменты, необходимо пройти все 4 этапа, от создания истории — до кейса.
#1. Пользовательские истории
Пользовательские истории (User Stories) — база для сценариев. Это синопсис, краткое содержание «легенды» юзера и его потребностей относительно вашего продукта.
Отличительные черты пользовательских историй:
- небольшой размер
- максимальная детализация: содержат подробности о человеке и его бэкграунде, мотивах, стремлениях, привычках и нуждах
- от лица юзера описывается потребность, которую закрывает ваш продукт
Разберем все 4 этапа на примерах пользовательских сценариев для создания сайта маркетплейса.
Пример: На этой неделе коллега пригласила меня на юбилей. Я ее почти не знаю, но другие сотрудники посоветовали подарить ей что-нибудь для дома — набор текстиля или посуды. Мне сложно выбрать, поскольку я слабо ориентируюсь в этих вещах и переживаю, что могу купить дорогой подарок плохого качества или даже бесполезный.
Хорошо бы получить совет от кого-нибудь, кто в этом разбирается. А то я не знаю, на что ориентироваться, кроме цветов. Это должен быть интернет-магазин с большим количеством отзывов на товары и либо с точкой выдачи недалеко от работы, либо с доставкой домой в вечернее время. Кроме того, нужна оплата картой, потому что я не хочу возиться с наличкой.
Было бы неплохо, если бы сразу в магазине могли красиво упаковать подарок и мне не пришлось бы тратить время еще и на это.
#2. Концептуальные сценарии
Несколько историй и характеров потенциальных покупателей объединяются в один концептуальный сценарий. Conceptual Scenarios создаются на основе пользовательских историй путем упрощения. Все малозначительное отбрасывается, похожие «легенды» объединяются в одну. Финальное описание практически полностью лишено технических подробностей.
Этот этап необходим для генерации идей и выявления ключевых требований. Когда в процессе обсуждения концепта возникает определенная система, с которой взаимодействует юзер, идея перерастает в конкретный сценарий.
Пример: Пользователь заранее планирует бюджет на покупку, ищет товар через поиск, сразу применяет фильтры, несколько дней принимает решение, сомневается и сравнивает продукты в корзине. Затем оставляет заказ, выбрав наиболее подходящий вариант оплаты и способ доставки.
#3. Конкретные сценарии
На этапе создания конкретного сценария важно сегментировать аудиторию, для каждой из категорий прописать персонажа — и уже исходя из усредненных характеристик ЦА обрисовать путь достижения цели. В этот блок работы можно также включить ограничения: например, пользователь делает заказ с ПК, мобильной версии сайта или из приложения.
Concrete Scenarios уже включают в себя детали реализации проекта и технические подробности. Конкретные сценарии пишутся от третьего лица.
Пример: Добавляем ограничение — заказ будет сделан через мобильную версию сайта.
Клиент Х хочет приобрести покрывало в подарок коллеге на этой неделе. Бренд должен быть «проверенным» (т. е. его качество подтверждают отзывы других покупателей и фильтр популярности). Необходимо, чтобы у товара была красивая упаковка, чтобы впечатлить коллегу во время поздравления.
Клиент Х выбирает покрывало с телефона, стоя в пробке по дороге домой и параллельно отвлекаясь на другие дела. Ему точно не хочется заполнять слишком много полей. Оплатить заказ лучше через Apple Pay на сайте, поскольку он почти не носит с собой наличку.
Определившись с подарком, клиент выберет праздничную упаковку и доставку после 20:00. Ему важно, чтобы товар привезли точно в указанное время, поскольку он приедет домой в 19:45, а в 20.30 отправится на встречу.
Чтобы проработать весь процесс взаимодействия покупателя с сайтом, важно создать нескольких персонажей, продумать для каждого из них историю, концепт и конкретный сценарий. После этого конкретные сценарии объединяют по главному признаку — в нашем примере это заказ через мобильную версию сайта. Конечный вариант, который получился после такой интеграции, называется сценарием применения или кейсом.
#4. Сценарии применения
Пример или кейс применения (Use Case) — пошаговое описание взаимодействий пользователей и системы. Это технический план, в фокусе которого находятся функции, а не чувства и мысли юзера, некий список деталей контактов человека с системой. Действующее лицо уже не персонаж, а абстрактная усредненная пользовательская роль — новый юзер, администратор магазина, зарегистрированный клиент.
На этом этапе следует описать user experience по шагам: кто, что, как и в какой последовательности делает.
Пользовательские истории и концептуальные сценарии нужны для понимания основных мотивов юзеров и погружения в мир клиента. Конкретные сценарии и варианты применения уже могут использоваться для проектирования информационной архитектуры, интерфейсов, а также при проведении тестов и исследований юзабилити.
Пример: Заказ покрывала
Хотите получать дайджест статей?
Одно письмо с лучшими материалами за неделю. Подписывайтесь, чтобы ничего не упустить.
Спасибо за подписку!
На сегодняшний день разработка мобильных приложений перестала быть уделом только лишь умудренных опытом специалистов. Все чаще результат работы разработчика-самоучки становится намного интереснее и гораздо полезнее для конечного пользователя, о чем свидетельствует высокие рейтинги продуктов независимых программистов в сторах. Удачный выбор идеи все еще остается основополагающим фактором успеха приложения. Кроме того, в наше время создать успешное мобильное приложение может даже человек, весьма далекий от программирования, поскольку для этого существует аутсорсинг.
Процесс разработки мобильного приложения состоит из нескольких последовательных этапов. Первоначальным и в итоге во многом определяющим конечный результат является написание User Story.
Что такое User Story?
User Story в первую очередь — это руководство к действиям по созданию, оптимизации и продвижению продукта. Во-вторых, это возможность еще раз оценить перспективы продукта. В большом WEB и среди разработчиков ПО функции User Story успешно заменяют функциональные спецификации.
Три довода в пользу User Story по сравнению с спецификациями при разработке мобильного приложения:
- Во время создания пользовательской истории разработчики продумывают, как решать ряд задач еще до стадии начала процесс разработки. User Story отлично помогает взглянуть на всю систему целиком.
- Пользовательские истории являются результатом работы команды, в отличие от спецификаций. Обычно последние пишутся одним или несколькими людьми в команде. Как предмет коллективной работы, пользовательские истории помогают выявить все слабые стороны продукта и решить все проблемы в реализации идеи до разработки в формате живого общения.
- User Stories создаются в том числе для тестировщиков. Они содержат пользовательские сценарии, которые станут основой тестирования после сдачи проекта.
Как было сказано выше, правильно написанная пользовательская история позволяет избежать множества распространенных проблем, главная из которых — неправильное представление конечного продукта разработчиком. Ситуация, кстати, достаточно распространенная. И в интересах издателя, чтобы результат разработки мобильного приложения полностью соответствовал требованиям и ожиданиям пользователя, а значит, созданию User Story следует уделить особое внимание.
Какие требования выдвигаются к написанию пользовательских историй?
В первую очередь необходимо, чтобы при написании пользовательской истории присутствовало максимальное количество заинтересованных людей. Написание хорошей User Story — коллективный труд, в котором важна командная работа, целью которой является продумывание всех нюансов. Этот тот самый случай, когда две головы лучше одной.
В случае создания мобильных приложений разработчик должен хорошо представлять основные требования, которые пользователь будет выдвигать к создаваемому приложению. На основе этих требований и следует формировать пользовательскую историю. Она должна вести виртуального пользователя по всем страницам приложения, решая на каждом этапе совершенно конкретную задачу. В итоге шаги трансформируются в разделы, а решения — в функционал.
Начинать User Story лучше всего с описания целевой аудитории. Самый важный момент на этой стадии — четкое обозначение ролей в приложении. Далее следует расписать каждую роль в зависимости от действий в приложении, которые приводят к определенному результату. Схема выглядит примерно так:
В качестве… (описание представителя ЦА, его роль в приложении), он получает… (действия в приложении) для… (цели его действий в приложении).
Без наличия хотя бы одной из описанных характеристик теряется пользовательская ценность истории, что в итоге может привести к разногласиям в момент приемки. Проработка всех возможных сценариев очень важна, поскольку такой подход позволяет избежать некоторых достаточно неприятных сюрпризов на последующих этапах создания мобильного приложения.
Окончательная формулировка истории должна быть лаконичной и точной. Если сформулированная заказчиком история содержит сложные расплывчатые понятия, ее следует переписать. В идеале User Story должна быть:
- Внутренне независимой;
- Структурно изменчивой;
- Ценностно-ориентированной;
- Учитывающей критерии оценки каждого этапа;
- Оптимизированной по времени (рассчитанной на 1 неделю);
- Проверяемой (легко оценимой в результате)
Рекомендации для написания правильных User Story
- Написание пользовательской истории – это своеобразный «мозговой штурм», который следует использовать с максимальной выгодой для продукта. Во время ее написания должны быть заданы все вопросы и получены все ответы. Менять что-то на стадии разработки и тем более после сдачи проекта крайне сложно и затратно.
- Вместо одной большой пользовательской истории лучше написать несколько более мелких и точных. Т.е. крупные и громоздкие истории необходимо фрагментировать с учетом конкретики задач, разбивать на более детализированные и мелкие.
- Оптимальный размер User Story (следует ли ее разбивать на под-этапы или же объединять несколько в одну) определяется просто: на разработку должно уходить от 0,5 до 4 «идеального дня». Если уходит больше четырех, то имеет смысл фрагментировать. Если меньше – надо объединять.
- Обязательно прописывайте в истории критерии приемки, поскольку при их наличии тестировать соответствие готового продукта и истории намного легче.
- Хотя в большинстве случаев формат пользовательской истории должен соответствовать основным требованиям, но в некоторых случаях, если, к примеру, речь идет о дизайне, можно ограничиться более свободным форматом в виде скетчей или набросков.
- Следующий совет может кого-то и удивит, но его практическая польза подтверждалась неоднократно. В процессе работы над созданием User Story желательно использовать небольшие бумажные карточки. При командной работе этот метод просто незаменим, поскольку способствует динамике процесса. Готовую пользовательскую историю также не следует убирать с глаз долой в недра ноутбука или письменного стола. Повесьте их на стену, это будет очередной мотиватор для выполнения поставленной задачи.
Что делать не стоит?
- Чрезмерно детализировать. Из-за слишком подробной, описанной в деталях User Story, процесс ее обсуждения командой может быть сведен к минимуму, что не всегда хорошо для поиска оптимального решения поставленной задачи. Всегда нужно оставлять место для творчества, а формальный подход с ним, как известно, несовместим.
- При всех соблазнах сделать это пропускать обсуждение ни в коем случае не стоит. Даже если, на первый взгляд, все совершенно очевидно. Именно в процессе обсуждения можно, как говорится, расставить все точки над і.
- Формат User Story не предполагает наличие технических задач.
Необходимо отметить, что User Story не является чем-то нерушимым и не приемлющим каких-либо изменений. В принципе, при необходимости заказчик может добавлять новые пользовательские истории, менять приоритеты и т.д. Это вполне допустимо. При этом разработчик со своей стороны обязан объяснить заказчику, чем чревато будет предложенное изменение или добавление. Живое общение на этой стадии — залог успеха в будущем. Ведь создание успешного мобильного приложения – это блестящая идея + не менее блестящее ее воплощение. А для последнего значение правильно написанной User Story вряд ли можно переоценить.
Мы посоветовались с экспертами в области мобильной разработки и выяснили, как с их точки зрения лучше работать с историей.
Анна Минникова, Гиперболоид, сертифицированный Scrum Professional, работала продакт и проджект менеджером в крупнейших геомобильных приложениях СНГ, сейчас занимается lean коучингом.
1. Как правильно написать User Story?
Командой. Причем команда обязательно должна включать в себя менеджера продукта/клиента/стейкхолдера или даже конечных пользователей вашего продукта. Пишите user story не для того, чтобы получить формальные «требования», а чтобы вытащить на свет все важные для вашего продукта, бизнеса и пользователей нюансы.
Обязательно формулируйте персоны вашего продукта до начала работы над user story. Это поможет вам лучше прочувствовать пользовательские нужды/боли/желания и лучше понять, для кого вы проектируете ваш продукт.
Ваша идеальная история должна быть написана по такому образцу:
Как, <роль пользователя>, я <что-то хочу получить>, <с такой-то целью>
Сейчас вы сформулировали бизнес-ценность для пользователя вашего продукта. Но прелесть пользовательской истории в том, что она формулирует не только бизнес-ценность, но и требования для разработки и тестирования. К этой простой формулировке вы можете добавить критерии приемки, технические заметки, описание обработки ошибок, которые суммируют все задачи, которые вам нужно сделать.
Вот как в укороченном виде выглядела пользовательская история в одном из моих проектов:
Как водитель с загоревшейся лампочкой бензина я хочу быстро найти ближайшую хорошую заправку, чтобы заправиться качественным бензином.
Критерии приемки:
- Как водитель с загоревшейся лампочкой я могу просмотреть все ближайшие заправки.
- Как … я могу выбрать заправки подходящих мне брендов АЗС.
- Как … я могу видеть ближайшие заправки выбраннах брендов списком.
- Как … я могу видеть ближайшие заправки выбранных на карте.
Обработка ошибок:
1. При выключенной геолокации пользователя необходимо дать ему информацию о том, где ее включить.
Технические заметки:
1. Заправки в списке должны обновляться при изменении местоположения пользователя на 100 метров.
Такая формулировка задачи помогает разработчикам и тестировщикам не пытаться сравнивать готовую задачу с ui требованиями, которые быстро устаревают, а смотреть на основные проблемы, которые должны быть решены в рамках задачи. Дополненная прототипами, такая история легко становится задачкой в джире или бейскемпе, которую можно делать даже без финального дизайна.
Вот как выглядели экраны, относящиеся к этой истории, в итоговом приложении:
2. Как объективно оценить ее полезность и востребованность?
Пользовательские истории полезны, если вы понимаете, что с написанием пользовательской истории для самого простого проекта вы ступили на тяжелый путь сомнений: «зачем мы делаем наш продукт»?, «точно ли нужна эта фича в продукте?», «да пользователей с такими потребностями днем с огнем не сыщешь», «кто будет пользоваться тем, что мы делаем?». Эти вопросы не очень приятны, но честные ответы на них помогут вам спроектировать лучший продукт.
3. Чего делать не стоит при работе с User Story?
Писать их в гордом одиночестве или поручать написать пользовательские истории, к примеру, менеджеру проекта. Если, конечно, вы не являетесь конечным core пользователем продукта, который вы разрабатываете 
Также не очень здорово писать объемные, большие истории. Если ваша история не вмещается в стандартную итерацию вашей команды (я надеюсь, что это максимум 4 недели:), то она слишком велика и стоит задуматься, как можно ее поделить на несколько.
И самые главные грабли – писать пользовательские истории, которые пойдут в разработку, до того, как вы прошли через процесс customer development. Хорошо сделать это для общего понимания того, что пользователь, по вашему мнению, будет делать с продуктом.
Но пользовательские истории нужно писать не только для того, чтобы выразить ваше мнение о продукте или мнение заказчика. Они должны выражать мнение тех, кто будет покупать и пользоваться продуктом (не забудьте о том, что это не только конечные пользователи, но и те, кто оказывают влияние на совершение покупки. К примеру, конечными пользователями игр часто являются дети, но покупают их родители).
Поэтому для того, чтобы написать ценную и реалистичную пользовательскую историю, вам нужно получить максимум информации о ваших будущих пользователях:
- считают ли они проблему, которую решает ваш продукт, достаточно серьезной (к примеру, все игры решают серьезную проблему – убийство времени и побег от скуки);
- как они решают свои проблемы сейчас;
- какие заменители или конкуренты есть у вашего продукта;
- и еще массу важных моментов, которые стоит узнать до того, как вы написали гору кода :).
Это самый большой и объемный пункт, поэтому очень хочу порекомендовать к прочтению 2 книги:
Four Steps to the Epiphany – библия customer development, которая даст вам фундаментальное понимание об этапе создания продуктов, которые вам нужно пройти перед тем, как написать пользовательские истории.
User Stories Applied – самая лучшая и полная книга о том, как писать, оценивать, тестировать и принимать пользовательские истории.
Евгений Плохой, CEO at CapableBits, Founder of CBLabs.mobi
Я бы сказал, что user story – это инструмент. Инструмент этот обычно используют outsourcing компании. Он позволяет начать диалог с клиентом и работать в одной карте понимания задачи. Так что чаще всего user story пишет заказчик. Сам формат user story, который выглядит так «As !WHO! I want !WHAT! so that !WHY!» предполагает, что её пишет пользователь/заказчик, который объясняет ЧТО он хочет и ЗАЧЕМ. Мы разрабатываем продукты для глобального рынка и разрабатываем продукты самостоятельно, поэтому таким инструментом, как user story мы не пользуемся. Для нас более актуальными являются сценарии использования, которые мы в том числе используем для QA продукта.
1. Как правильно написать User Story?
Хорошая User Story должна соответствовать модели INVEST.
2. Как объективно оценить ее полезность и востребованность?
Объективно оценить её полезность и востребованность достаточно сложно, т.к. непосредственно в процессе разработки она не участвует, а служит отправной точкой. Это способ начать диалог без понятных маркеров его завершения. Субъективно для нас этот инструмент бесполезен.
3. Чего делать не стоит при работе с User Story?
- Использовать историю для выполнения которой требуется более одной итерации
- Писать громоздкие истории.
- Использовать жаргон.
- Сразу привязывать историю к конкретному интерфейсу.
User story от Юлии Козловой, PR & Event Manager в Touch Instinct
1. Как правильно написать User Story?
Не важно то, как она будет написана и оформлена. Главное – насколько правильно и точно она описывает потребности пользователя. В Touch Instinct мы проговариваем пользовательскую историю с клиентом устно, во время переговоров. Делаем заметки. Кто пользователи, чего они хотят? Мы выясняем формализованные потребности: мгновенная покупка, удобное чтение новостей, бронирование мест, заказ билетов и т.д., из которых прорабатываем детальные требования к сценариям использования будущей программы. «Я как пользователь хочу сортировать товары по цене, чтобы выбрать лучшее из одной ценовой категории». «Я как пользователь хочу сохранять музыку в кэш, чтобы слушать без интернета». Далее на основе юз кейсов строим интерфейс, на этом этапе мы понимаем, от какого функционала стоит отказаться, например, нужны ли комментарии к фотографиям или нет.
2. Как объективно оценить ее полезность и востребованность?
Заказчик хорошо знает свой продукт и потребителя. На переговорах мы стараемся вытянуть из него максимальную информацию о том, чего хочет пользователь. Полезность юзер стори прежде всего в том, что они помогают разработчику лучше понять область, продукт, аудиторию заказчика. Мы не совершаем действий ради действий. Востребованность юзер стори оценивается обнаружением и проработкой пользовательских потребностей, на выходе продукт их должен удовлетворять.
3. Чего делать не стоит при работе с user story?
Не стоит зацикливаться и затягивать с проработкой. Зафиксировали ключевой функционал, держите его в фокусе, перед глазами, но не воспринимайте как инструкцию. Юзер стори достаточно гибкая вещь, в которую можно вносить изменения.
Наталия Давыдова, менеджер Heads and Hands
User Story обычно используется при гибких методологиях разработки. В нашей компании часть проектов ведется по такой методологии. Обычно мы организуем встречу с клиентом, на которой просим его описать обычным пользовательским языком пожелания к функционалу сайта или мобильного приложения. На основе этого мы составляем конечное описание работ для итерации (беклог). Правильный пользовательский сценарий, на наш взгляд, должен быть:
- понятным для всех участников проекта (и конечного пользователя);
- коротким, чтобы можно было оценить сроки его выполнения, но при этом с достаточно точным описанием;
- сценарий должен совпадать по смыслу и идее с основным проектом (чтобы очередная итерация «не выпадала» из общей идеи проекта. Это как раз слабое место гибких методологий, потому что при большом количестве итераций порой забывается основная идея и смысл проекта, он обрастает дополнительным и не всегда нужным функционалом, превращаясь в громоздкого «Франкенштейна»)
Объективно можно оценить полезность в том случае, если по user story можно сформировать удобный и понятный конечному потребителю продукта интерфейс.
При написании user story нужно стараться придерживаться максимально простого описания (без ухода в технические детали). Учитывать роли пользователей при работе с продуктом. Стараться не увеличивать размер истории. Она должна вписаться в одну итерацию, которая при гибких методологиях длится не более двух недель.
Если вы нашли опечатку — выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.