Сценарии использования мобильного приложения

Денис Нарижный, руководитель интернет-агентства «Студия 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) Сюда присылай.

— Отправила. Всё. Можете ехать по своим делам.

Реальность

<…>

До этого этапа мы не добрались.

А выводы?

В начале статьи мы задались целью показать, как использовать сценарии для оценки и создания приложений. У нас не было задачи найти все возможные ошибки в «Помощнике ОСАГО».

Наш сценарий — это то, что мы ожидали от приложения. Разумеется, мы не претендуем на единственное правильное мнение. Да и вообще на правильное. И да, мы могли придумать другой сценарий. Но взяли этот для примера.

Главное, что мы хотели сказать: фиксировать сценарий — важно.

Вот как еще можно использовать сценарий.

А вывод такой: для «приложений одной задачи» сценарий — важный этап работы над продуктом. Возможно, даже главный. И уж точно — один из самых-самых первых.

Доля мобильных устройств в структуре интернет-трафика продолжает расти. Согласно исследованию аналитического агентства We Are Social и крупнейшей SMM-платформы Hootsuite по России этот показатель увеличился за 2017 год на треть, в то время как доля десктопного трафика за тот же период снизилась на 5 %.

Программа минимум — удобная адаптивная версия веб-сайта. Второй вариант — мобильное приложение, которое сделает взаимодействие клиентов с брендом еще проще и комфортнее.

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

Какие задачи может решать компания с помощью своего мобильного приложения

Задачи — это первое о чем стоит подумать, собираясь заказывать разработку приложения. Продукт, созданный потому что «вон же “Рога и копыта” сделали, чем мы хуже» не принесет пользы ни бизнесу, ни клиентам. Поэтому сначала задайте себе вопрос: «Зачем нам мобильное приложение? Какие задачи оно поможет решить компании?»

Ответы могут быть такие.

Повысить продажи

В первом квартале 2018 года международная рекламная платформа Criteo провела глобальное маркетинговое исследование поведения пользователей и покупок на сайтах 5 000 ритейлеров в 80 странах мира и пришла к следующим выводам:

• Приложения генерируют 47 % всех продаж с мобильных устройств.
• Конверсия в приложениях в среднем в 3 раза выше, чем на мобильных сайтах.
• За год число продаж в приложениях выросло на 22 %.

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

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

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

Стимулировать повторные покупки

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

Кроме того, иконка приложения на смартфоне привлекает внимание. Человек заглянул в телефон, чтобы посмотреть время, увидел иконку «Додо»… а дальше все как в тумане — очнулся, отдавая деньги курьеру. Я, конечно, утрирую, но вы и сами замечали, что логотипы на экране смартфона привлекают внимание и могут напомнить о покупке.

Ну и, наконец, пуш-уведомления — дешевый и эффективный способ сообщать клиентам об акциях, напоминать о брошенных корзинах и другими способами возвращать их внимание к вашему бренду.

Увеличить средний чек

Эта задача решается за счет того, что приложения имеют более высокую конверсию и меньший процент отказов на стадии завершения покупки. Кроме того, в приложениях чаще всего покупают авторизованные пользователи. Зная о них больше, вы можете делать им более персональные предложения, в том числе — и апп-сейл. Это подтверждается и исследованиями Criteo.

Повысить лояльность клиентов

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

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

Автоматизировать бизнес-процессы

Для автоматизации бизнес-процессов существует множество софта и веб-сервисов, в том числе — и отраслевых: для HoReCa, ритейлеров, отельеров. Еще 10-15 лет назад такие решения даже для десктопов казались прорывом. Мобильные приложения для решения внутренних задач компании — следующий этап.

Рабочие процессы компании могут автоматизировать не только внутренние решения, но и приложения, созданные для клиентов. Так, например, основная функция приложения такси — быстрый и удобный вызов машины. В то же время оно автоматизирует прием, обработку и распределение заказов. Без приложения заказы поступают по телефону или с сайта. Их обрабатывает живой оператор, выбирает ближайшего водителя, отправляет на адрес. В том же Яндексе эти функции выполняет приложение. Все это автоматизация.

Упростить коммуникации с клиентами

Наличие мобильного приложения для iOS или Android по сути делает ненужной рассылку сообщений и e-mail — клиентам, у которых стоит приложение. Всю необходимую информацию можно доставлять прямо на экран гаджета через пуши — скидки и акции, готовность заказа, доставка в пункт выдачи, напоминание о записи на сеанс, коды подтверждения для банковских и платежных сервисов.

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

Принимать платежи

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

Анализировать аудиторию

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

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

Тем не менее системы статистики собирают важные для маркетинга данные и помогают составить довольно полный портрет аудитории. Например, Google Analytics для Firebase собирает такую информацию о пользователях приложений:

Сократить расходы

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

В первом случае вы экономите за счет того, что:

• сможете отказаться от некоторых штатных единиц, например, операторов кол-центра — их функции заменит приложение;
• некоторые операционные процессы будут выполняться быстрее за счет автоматизации → людей потребуется меньше

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

Сценарии использования мобильных приложений

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

Мобильная точка продаж

Самый очевидный для интернет-магазинов, сервисов доставки, билетных агентств, некоторых видов услуг и других бизнесов сценарий. Мобильная точка продаж — это витрина, средства коммуникации с покупателями, канал доставки рекламных сообщений и онлайн-касса в смартфоне клиента.

В зависимости от конструкции мобильного приложения оно может включать следующие функции:

• каталог предложений;
• акции и скидки;
• чат с оператором;
• вишлист;
• корзина;
• оформление заказа;
• прием платежей;
• пуш-уведомления;
• отслеживание статуса доставки;
• оформление возвратов и другие.

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

Девушка, а вы мне нравитесь! – двойной тест приложения для знакомств

Система лояльности

Когда бизнес-модель не предполагает удаленную продажу товаров или бюджет не позволяет реализовать в приложении полноценный интернет-магазин, можно ограничиться системой лояльности.

Так, например, сделали в «Детском Мире». В их приложении нельзя оформить заказ, оплатить покупку и даже посмотреть каталог. Зато можно изучить список актуальных акций и воспользоваться картой постоянного покупателя. Чтобы во время покупки продавец начислил или списал бонусные баллы, нужно показать ему QR-код в приложении.

Казалось бы устанавливать на телефон лишнее приложение, чтобы получить скидку, это слишком — есть же пластиковые карты. Не знаю как у вас, а у меня работает закон подлости — когда я захожу в «Детский Мир», чтобы купить что-то ребенку, карты никогда нет с собой. Телефон же всегда в кармане.

Возможно, у «Детского Мира» это временное решение и скоро появится большое удобное приложение для покупок со смартфона. Но и в таком виде оно довольно полезно и актуально для родителей, которые регулярно закупаются в этом магазине.

Поддержка пользователей

Такое приложение будет полезно операторам связи, интернет-провайдерам, разработчикам ПО, интернет-сервисам и другим бизнесам, которым нужно регулярно поддерживать связь с клиентами и решать их проблемы.

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

Хороший пример — приложение техподдержки кемеровского оператора связи Goog Line. Ребята пошли дальше и помимо средства коммуникации с пользователями разработали умного бота Лену, которая решает простые задачи — оформляет заявки на выезд мастера, проверяет связь и т. д. Если проблема пользователя сложная или нестандартная к чату подключается «живой» оператор.

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

Полезный контент

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

Полезный контент не влияет напрямую на продажи и средний чек, но может повысить лояльность клиентов и стимулировать их установить приложение. Так, например, в приложении сервиса покупки и продажи автомобилей Auto.ru есть раздел «Учебник для покупателей». В нем содержатся подробные и обстоятельные ответы на вопросы, возникающие у человека, который покупает машину.

Подумайте, какую информацию, связанную с вашей сферой деятельности, клиентам было бы полезно держать под рукой? Для фитнес-клуба это может быть таблица калорийности или справочник по ЗОЖ, для юридической консультации — инструкции по составлению документов, для репродуктивной клиники — рекомендации по подготовке к беременности.

Интерактивный сервис

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

Первое направление подойдет компаниям, для которых сервис — основное направление деятельности. В качестве примера можно привести обучалки вроде LinguaLeo, облачную бухгалтерию, таск-менеджеры, сервисы учета личных финансов, электронные библиотеки, облачные хранилища, сервисы поиска работы, недвижимости, подержанных вещей и многое другое. Их приложения дублируют основной веб-сервис или программу и упрощают взаимодействие с ними со смартфонов.

Во втором случае в приложении создается дополнительный полезный сервис, который помогает пользователям решать какие-либо задачи. Таким сервисом может стать список покупок в приложении с акциями и распродажами, конструктор луков в мобильном магазине одежды, планировщик тренировок в приложении фитнес-клуба и т. д. Так, интернет-аптека Piluli.ru включила в свое приложение сервис-напоминалку о приеме лекарств и витаминов. Как человек, который все время забывает об этом, могу сказать — очень удобно.

Такие сервисы работают на лояльность клиентов и заставляют их возвращаться к приложению компании снова и снова, а значит — увеличивают вероятность повторных покупок.

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

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

Навигация

Навигация — частный случай сценария с полезными сервисами. Этот инструмент помогает клиентам быстро найти ближайшее представительство компании и проложить маршрут на карте. Функцию стоит рассматривать скорее как дополнительную — мало кто будет скачивать приложение только ради навигации, когда под рукой «Google Карты» и «Яндекс.Навигатор».

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

Геймификация и развлечения

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

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

Крупные бренды могут себе позволить создавать отдельные геймифицированные приложения, направленные на пользу для клиента. Такие продукты работают на лояльность потребителей к бренду. Пример — приложение Nike Run Club от известного производителя спортивных товаров создано для любителей бега. В нем пользователи отслеживают свои результаты — скорость, время, дистанции — ведут дневники тренировок, делятся достижениями и соревнуются друг с другом.

Внутренние корпоративные инструменты

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

Первое, что приходит в голову, — приложения для водителей вроде Яндекс.Такси, которые подбирают заказы, прокладывают маршруты и считают стоимость поездки. По тому же принципу работает приложения для курьеров службы Dostavista и некоторых других курьерских контор. Они автоматизирует распределение заказов, отчетность, коммуникацию с отправителями и получателями, а также частично — оплату заказов и взаиморасчеты с курьерами.

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

Что важно помнить, планируя разработку приложения

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

«Мобильное приложение стоит делать только тогда, когда есть четкое понимание, что вложенные в него инвестиции окупятся. Проверить это можно на мелких тестах. Например, посмотреть, какой процент покупателей пользуется сайтом интернет-магазина с мобильных. Если заходов со смартфонов много, приложение делать стоит, потому что конверсия приложения будет выше, чем с сайта просто потому, что оно удобнее технически.»

2. Если вы планируете разработать приложение для клиентов, подумайте, чем оно будет им полезно.

«Польза — главный критерий популярности приложения. Надо сразу понимать, насколько приложение, которое разрабатывает бренд, будет полезно для пользователей, какие задачи они смогут решать. Если приложение решает много задач, которые без него делать долго и неудобно, оно становится популярным.»

3. Еще на этапе идеи подумайте, как вы будете продвигать приложение — откуда люди узнают о нем.

«Разработать хорошее приложение недостаточно. Нужно сделать так, чтобы о нем узнали. У крупных брендов такой проблемы нет — у них как минимум есть своя база, которая может скачать, новая аудитория тоже нарабатывается довольно быстро — продумывается рекламная кампания, и приложение продвигается точно так же, как и сайт.»

Как мы синхронизировали сайт и приложение – кейс «Ломбардиста»

А вы задумывались о разработке мобильного приложения? Чего хотите добиться с его помощью и какие функции реализовать? Если приложение уже запущено — делитесь опытом в комментариях

Центром любого дизайн-проекта является пользователь.

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

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

Содержание статьи

Что такое пользовательские сценарии?

Зачем нужны сценарии?

Как создать пользовательский сценарий

Отличие пользовательского сценария от пользовательской истории

Привлекаем команду контроля качества

Заключение

Что такое пользовательские сценарии?

По сути, пользовательские сценарии (User Scenarios) — это короткие рассказы о пользователях, представленных в виде образов идеальных пользователей (персон), пытающихся достичь своих целей в своем контексте в ходе взаимодействия с вашим сайтом или приложением. Как правило, сценарии разрабатываются для продуктов и сервисов, только планируемых к запуску.

Создание сценариев требует особого мышления: необходимо сосредоточиться на целях пользователей. Чего они будут пытаться достичь на вашем сайте или в приложении? Будет ли ваш продукт им полезен? Также важно подумать о сопровождающем их контексте (нюансы поведения и использования продукта, условия, влияющие на UX), их предыдущих знаниях и опыте.

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

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

Зачем нужны сценарии?

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

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

Пользовательские сценарии также применяются для определения наиболее важных для юзабилити-тестирования областей, они позволяют понять, как именно должен проводиться каждый тест.

Благодаря сценариям мы можем определить:

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

Как создать пользовательский сценарий

Как вы уже поняли, предварительным условием является создание персон. Разработав образы идеальных пользователей, вы можете переходить к следующему плану:

1. Решите, какие сценарии создавать, отталкиваясь от наиболее значимых действий каждого вида персон.

2. Напишите правдоподобную историю, содержащую:

• сюжет (триггеры, действия, достигнутая цель);
• контекст использования (где? когда? каковы окружающие пользователя условия?);
• мотивации, причины;
• ответ на вопрос: как продукт/сервис помогает достигнуть конечной цели?

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 

17-10-2021

Как написать пользовательский сценарий?

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

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

Из чего состоит сценарий:

1. Цель, которую мы преследуем.
2. Основной сценарий.
3. Альтернативные сценарии, дополнительные.
4. Конечный результат.

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

Во-первых, на примере приложения для РЖД(рис.1)

Цель этого приложения — попасть на поезд без бумажного билета.

Рис.1 Приложение РЖД

Рис.2. Шаг первый

Кстати, рекомендую посмотреть прямо сейчас:

Все начинается с того, что человек просто покупает билет на сайте РЖД (рис.2).

Рис.3 Шаг второй

Следующим шагом пользователь должен увидеть эту поездку в приложении (рис.3). Он видит активные элементы, с датами, городом и временем.

Рис.4. Шаг третий

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

Рис. 5 Альтернативный сценарий

Во-вторых, может быть альтернативный сценарий (рис.5). Человек может захотеть вызвать такси до вокзала и здесь есть ссылка на такси. И может получить push-уведомление, чтобы не пропустить поезд за какое-то время.

Рис.6 Шаг четвертый

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

Рис.7  Шаг пятый

Дальше мы уже в поезде. Человек может найти свое место в поезде.На последнем экране, что важно (рис.7).

Рис.8 Шаг шестой

Есть альтернативный сценарий (рис.8). То есть мы заботимся о человеке больше и думаем не только о том, как ему добраться до дома, т.к. это его конечная цель, в свою квартиру, отель и т.д. И мы даем альтернативный сценарий: сообщить по смс друзьям,родственникам, что все ок и где, во сколько будет встреча. Можно вызвать такси с вокзала. И подключить вайфай. То есть заботимся о человеке чуть больше, делая следующий шаг. И даем ему с комфортном добраться домой (рис.9).

Рис. 9 Шаг седьмой

Важно развивать лишь те сценарии ,которые позволяют продвигаться вперед и не плутать в излишних деталях.

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

Сценарий –стратегия. Описывайте ключевые точки процесса глобально, от начала до конца.

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

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

Что такое User Story?

User Story в первую очередь — это руководство к действиям по созданию, оптимизации и продвижению продукта. Во-вторых, это возможность еще раз оценить перспективы продукта. В большом WEB и среди разработчиков ПО функции User Story успешно заменяют функциональные спецификации.

Три довода в пользу User Story по сравнению с спецификациями при разработке мобильного приложения:

1. Во время создания пользовательской истории разработчики продумывают, как решать ряд задач еще до стадии начала процесс разработки. User Story отлично помогает взглянуть на всю систему целиком.
2. Пользовательские истории являются результатом работы команды, в отличие от спецификаций. Обычно последние пишутся одним или несколькими людьми в команде. Как предмет коллективной работы, пользовательские истории помогают выявить все слабые стороны продукта и решить все проблемы в реализации идеи до разработки в формате живого общения.
3. User Stories создаются в том числе для тестировщиков. Они содержат пользовательские сценарии, которые станут основой тестирования после сдачи проекта.

Как было сказано выше, правильно написанная пользовательская история позволяет избежать множества распространенных проблем, главная из которых — неправильное представление конечного продукта разработчиком. Ситуация, кстати, достаточно распространенная. И в интересах издателя, чтобы результат разработки мобильного приложения полностью соответствовал требованиям и ожиданиям пользователя, а значит, созданию User Story следует уделить особое внимание.

Какие требования выдвигаются к написанию пользовательских историй?

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

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

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

В качестве… (описание представителя ЦА, его роль в приложении), он получает… (действия в приложении) для… (цели его действий в приложении).

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

Окончательная формулировка истории должна быть лаконичной и точной. Если сформулированная заказчиком история содержит сложные расплывчатые понятия, ее следует переписать. В идеале User Story должна быть:

1. Внутренне независимой;
2. Структурно изменчивой;
3. Ценностно-ориентированной;
4. Учитывающей критерии оценки каждого этапа;
5. Оптимизированной по времени (рассчитанной на 1 неделю);
6. Проверяемой (легко оценимой в результате)

Рекомендации для написания правильных 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. Как водитель с загоревшейся лампочкой я могу просмотреть все ближайшие заправки.
2. Как … я могу выбрать заправки подходящих мне брендов АЗС.
3. Как … я могу видеть ближайшие заправки выбраннах брендов списком.
4. Как … я могу видеть ближайшие заправки выбранных на карте.

Обработка ошибок:

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.

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

Что такое пользовательский сценарий?

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

Зачем нужны пользовательские сценарии?

Пользовательские сценарии — это очень удобный инструмент для разработки пользовательских интерфейсов. Ведь важно не только «познакомиться» с пользователем, но и понять его цели. Только тогда, когда мы поймем, кто и что делает на нашем сайте, а также то, как и зачем они это делают, мы сможем четко определиться с требованиями дизайна, которые нам предстоит удовлетворить. Так что нам нужно сжать контент веб-сайта до определенных целей, а затем представить всё это в виде сценариев.

Когда нужны пользовательские сценарии?

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

Как выглядит хороший пользовательский сценарий?

Хороший пользовательский сценарий краток и точен. Он дает ответы на следующие вопросы: Кем является мой пользователь? Что этот пользователь хочет получить от моего сайта? Как он планирует достичь этой цели? Почему этот пользователь пришел именно на мой сайт, а не на какой-нибудь другой? Давайте рассмотрим эти четыре вопроса по отдельности. Также, я приведу краткие примеры.

Кем является мой пользователь?

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

Питер (32 года, не женат) работает в департаменте корпоративных коммуникаций компании Daimler Chrysler. Поначалу, он любил эту работу, но теперь, она не кажется ему такой интересной. Однако, он боится что-то менять, поскольку его статус и финансовое положение очень важны для него. Питер очень организован, и не выносит хаоса или неудобств. В свободное время он много читает. Книги помогают ему занять ум, а профессиональная литература дает ему задачи, которых не может предложить работа. Последние несколько недель, Питер увлекся книгами по медицине. Из-за семейной истории, его особо интересуют болезни почек.

Что этот пользователь хочет получить от моего сайта?

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

Питер ищет книгу, которая могла бы простыми словами рассказать о различных болезнях почек, включая симптомы, методы лечения, и возможные долгосрочные эффекты. Он планирует потратить на эту книгу не более $30, и, поскольку он хочет сэкономить, не откажется от подержанной. Чтобы найти то, что ему нужно, он заходит на Amazon.com.

Как он планирует достичь своей цели?

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

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

Почему этот пользователь пришел именно на мой сайт?

При написании пользовательского сценария, точно отвечайте на вопрос «почему?». Например, сравнение товаров, и непосредственная покупка — это две разные мотивации. Переход на сайт из-за позитивного прошлого опыта, и по совету друга — также отличаются. Для каждой их этих мотиваций, нужны свои сценарии. Пример:

Раньше, Питер ходил в местный книжный магазин. Ему нравилось ходить по городу после работы. Потом, друг посоветовал ему Amazon.com. Его другу очень понравился функционал сайта, и его удобство. Питер заинтересовался, и решил попробовать. Ведь покупать книги не отходя от стола, намного удобней, чем в магазине. Он решил попробовать, и заказать книгу онлайн.

Заключение

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

Перевод статьи Сабины Айдлер