Колонка
User: stories, scenarios, journey, flow. У чому різниця?
30 березня, 2021
Даша Дьяченко
Продуктова дизайнерка в «Нова Пошта»
Стати автором

Продуктова дизайнерка Даша Дьяченко в колонці для Telegraf.Design, розбирається, який метод із приставкою -user краще обрати після проведення інтерв’ю, тестування та збору цікавих фактів і знань про користувачів.

User stories, -scenarios, -journey, -flow – це все методи структуризації інформації, яку ви отримали після якісних досліджень. Вони допомагають перенести факти з вашої голови в чіткі формулювання та схеми, щоби потім спиратись на них у процесі розробки продукту та ділитися з усіма учасниками.

Перш ніж почнемо розбиратися докладніше в методах, пропоную перекласти їх на нашу рідну мову. Англомовні терміни – це, звісно, база, ще й круто звучить. Але зазвичай цю термінологію розуміють далеко не всі. Не забуваємо, що дослідження та результати треба буде передати команді, а, можливо, й продати замовнику. Вчимося пояснювати.

  • User stories – користувацькі історії
  • User scenario – користувацькі сценарії
  • User journey / user journey map / customer journey map – мапа шляху користувача
  • User flow – мапа сценаріїв користувача (незовсім дослівно, але відображає суть)

Користувацькі історії

Стандарт для формулювання: як  <роль, персона>, я хочу <потреба, бажання>, щоб <користь>

Подивимось на прикладі додатку доставки їжі. 

Нехай однією з персон цільової аудиторії мого додатку буде фрілансер або віддалений працівник, який слідкує за своїм здоров’ям. Як фрілансер, я хочу швидко та корисно пообідати, щоби не витрачати час на приготування та тримати себе у формі. «Людською» мовою без будь-яких термінів та конкретних рішень описуємо потребу свого користувача.

До речі у формулюванні вище вказано дві потреби: швидко та корисно. Ось такі речі краще розділяти. Тобто, на нашому прикладі краще побудувати дві історії:

Як фрілансер, я хочу швидко пообідати, щоб не витрачати час на приготування.

Як фрілансер, я хочу корисно пообідати, щоб тримати себе в формі.

Навіщо ці історії та коли їх використовувати

Коли ви вже знаєте свого користувача (зазвичай після якісних досліджень): де й що в нього «болить», чого він хоче, історії – це швидкий спосіб ці болі та бажання зафіксувати, не розсіюючи увагу на рішення. От коли всі потреби будуть перед очима, можна генерувати рішення.

Наприклад, якщо потреба нашого фрілансера швидко, рішеннями можуть бути:

  • мінімальна кількість кліків для замовлення
  • автозаповнення всього, чого можна
  • підказки, які ресторани поруч, щоби їжа приїхала швидко
  • тощо

Плюс, такі історії допомагають всім учасникам проєкту розуміти те чи інше прийняте рішення в майбутньому, а дизайнеру – аргументувати свої пропозиції.

Порада: зручно записати всі історії на стікерах (одна історія – один стікер) та розмістити їх перед очима. Потім можна відсортувати їх за схожими потребами.

Користувацькі сценарії

Сценарії доповнюють історії та дозволяють подивитися, в яких умовах, за яких обставин може відбуватися та сама потреба. Вони корисні тим, що допомагають зрозуміти, наприклад, а звідки взагалі в наш продукт може прийти користувач. Його потреба вирішується «сидячи на стільці» чи «коли він біжить до метро».

Це розуміння може стати базою для стратегії маркетингу, генерування рішень командою, визначення приоритетних версій продукту (десктопна чи мобільна версія), особливостей елементів інтерфейсу (якщо потреба вирішується, коли користувач в русі, тримає однією рукою мобільний телефон, то це треба врахувати при проєктуванні продукту. Наприклад, зробити елемент доступним для пальця однією руки та достатньо великим, щоб не промазати).

Спробуємо скласти частину сценарію на нашому прикладі: 

Саша – фрілансер, працює вдома. Робота сидяча, тому для підтримання форми він слідкує за нормою калорій в день, дотримується часових проміжків між прийомами їжі та й узагалі слідкує за тим, що вживає. Коли час обіду вже близько, Саша починає гуглити ресторани, шукати доставку. Йому важливо, скільки треба чекати, яке меню пропонується, скільки калорій, які інгредієнти. Витрачає купу часу, щоби це все знайти. Як було би класно, якби ще в меню прописали кількість білків, жирів та вуглеводів. І далі розкриваємо потреби та умови, в яких перебуває користувач. Ми визначили потреби, умови. Ще й рішень нагенерували (або ні). Вступна частина для більш конкретних візуалізацій готова.

Мапа шляху користувача

Нагадаю, як виглядає цей метод візуалізації:

Важливо: під кожну окрему персону та роль має бути своя мапа. Шлях користувача завжди лінійний, варіантів розгалуження сценарію тут бути не може. Якщо є необхідність розібрати окремо кілька шляхів, зробіть кілька схем. Основа карти шляху – це послідовні кроки користувача, які він виконує при взаємодії з продуктом.

Для нашого прикладу шлях Саші-фрілансера може початися з: «Потрапив на лендінг» – «Відсканував QR-код» – «Завантажив додаток» – …

Корисно вказувати критичні моменти на кожному кроці, емоційний стан користувача. Ці рівні допоможуть знайти необхідні рішення для продукту. Наприклад, якщо у формі реєстрації в додатку користувач більше незадоволений, ми можемо в кінці форми підготувати для нього анімашку або підбадьорюючий текст. Застосувати емоційний дизайн.

Зручно, що можна не відволікатися на екрани, кнопки та поля введення, а зосередитися на ланцюжку дій – це і буде скелетом майбутніх прототипів.

Якщо продукт вже є, то можна побудувати карту шляху, який є зараз. Це допоможе більш масштабно, як то кажуть з висоти пташиного польоту (новомодна назва «bird view») подивитись на процеси та знайти прогалини, зафіксувати проблеми на кожному кроці, а потім їх лікувати. Чи є сенс в такій карті, коли продукт новий? Моя особиста думка – так.

На рівні користувача може бути ідеальний шлях, яким ви хочете його провести. Можна почати проєктування з більш глобальних кроків, а потім деталізувати кожний, щоб не загубитися.

На рівні критичних моментів можна вказати ті, які ви знаєте на своєму експертному досвіді або виявили під час інтерв’ю. Не переживайте, якщо здається, що ви не все врахували. Оскільки продукт буде розвиватись, з ним буде розширюватись та змінюватись мапа. Тому для початку немає потреби доводити схему до ідеалу.

Мапа сценаріїв користувача

Добре працює, коли в тебе вже є прототипи основних екранів. Можно, звісно, і з дизайн-макетами побудувати юзер флоу. Але краще починати працювати з прототипами. Так швидше, легше змінювати. Концентруєшся на функціоналі, а не гарних зображеннях.

Мапа сценаріїв – така собі блок-схема, що теж складається з кроків та дій користувача, але тут вже з’являються розгалуження.

Наприклад, реєстрація. В карті шляху вона за замовчуванням проходить успішно (в іншому випадку, наша мапа на цьому могла би і закінчитися). В карті сценаріїв ми можемо одну гілку повести по шляху успішної реєстрації, а другу – ні. При цьому користувач буде бачити різне та діяти за іншим сценарієм.

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

Найголовніше: ви можете знати та розуміти купу методів проведення досліджень та їх візуалізації. Але перед тим, як починати щось робити в цю сторону, поставте собі запитання: «Щоб що я на це зараз буду витрачати час?». Не робіть все заради процесу та бажання показати, як багато ви вмієте. Ваша експертність стає на рівень вище тоді, коли ви чітко розумієте, який метод підходить під проєкт, продукт. Який результат та користь вони принесуть.

Telegraf.Design працює за підтримки спільноти. Підтримуйте Telegraf.Design на Patreon.

avatar
Даша Дьяченко
Продуктова дизайнерка в «Нова Пошта»
Колонка

У нас є ще дещо для вас