Check Levi9 best QA positions to Backbase team!
×Закрыть

User Flows. Як ця техніка допомагає в роботі над проєктами

Привіт, мене звати Богдана, розвиваю напрям бізнес-аналізу в компанії TechMagic і в цій статті поділюсь власним досвідом застосування техніки User Flows на різних етапах існування проєкту. Читати варто всім, хто працює з виявленням і документуванням вимог, дизайном, розробкою та тестуванням продукту і хоче навчитись краще розуміти його.

Що таке User Flows

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

Компоненти User Flow:

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

Приклад побудови User Flow

На малюнку внизу зображено User Flow реєстрації на вебінар на навчальній платформі:

Під час візуалізації шляху користувача вдалось ідентифікувати два місця, де він може покинути платформу, на досягнувши своїх цілей: коли не знайшов потрібного вебінару і коли реєстрація на захід не активна. Розгляньмо варіант оновленого User Flow з поліпшеним досвідом користувача:

User Flow: Register for webinar (updated)

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

Види User Flows

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

  1. За способом візуалізації:
    • Flow charts — User Flows з використанням лише графічних елементів та тексту;
    • Wireflows — User Flows з використанням wireframes (схематичного зображення) чи дизайнів.
  2. За обсягом:
    • Task Flow — покриває лише шлях користувача для виконання якогось одного завдання (наприклад, Sign In);
    • User Flow — покриває шлях користувача для виконання комплексного сценарію (наприклад, User Flow ‘Purchase product’ може складатись з Task Flows ‘Sign in’, ‘Search for Product’, ‘Create an Order’, ‘Confirm Order’).

На практиці найчастіше створюю wireflows, на малюнку нижче зображено його приклад на основі сайту бронювання авіаквитків:

На що звертати увагу під час побудови User Flow

  1. Наявність зайвих кроків на шляху користувача, які не мають жодного функціонального навантаження.
  2. Пропущені кроки, які не дають можливості користувачу продовжити свій шлях.
  3. Dead ends — неможливість користувача повернутись чи змінити свій вибір.
  4. Опрацювання помилок, валідаційні повідомлення;
  5. Опрацювання empty states (коли не має інформації для зображення: не заповнені дані, відсутність результатів пошуку тощо).

Застосування User Flows під час роботи над новим продуктом

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

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

Що зробила я:

  1. Визначила основні ролі користувачів майбутнього продукту (Shop Assistant, Customer).
  2. Сформувала перелік цілей, які ці користувачі хочуть досягти за допомогою продукту — вони лягли в основу User Flows (Register a new customer, Shop for Products, Fulfill an Order тощо).
  3. Підтвердила список цілей у замовника.
  4. Переглянула наявні дизайни та візуалізувала User Flows спершу для однієї ролі (Shop Assistant).
  5. В кожному User Flow виокремила такі моменти та обговорила їх із замовником і командою:
    • відсутні empty states;
    • відсутні валідаційні повідомлення та екрани з повідомленнями про помилку;
    • незрозуміла або відсутня навігація;
    • суперечливі елементи (різні типи одного й того ж поля на різних сторінках);
    • dead ends — коли користувач не має змоги повернутись назад.

Результати

  1. Більш ефективний спосіб обговорення вимог і дизайнів із замовником.
  2. Зменшення часу, який витрачали розробники на розуміння того, що потрібно реалізувати.
  3. Можливість донести замовнику ідеї для поліпшення продукту з погляду UX.
  4. Можливість побачити big picture і розглянути різні сценарії користувача, що складно або неможливо, якщо працювати лише з окремими сторінками.


User Flow: Add product to Shopping Cart

Застосування User Flows під час роботи над продуктом, розробленим кимось іншим

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

Що зробила я:

  1. Дослідила продукт і визначила User Flows (Register, Sign In, Make a Top-up, Change Profile Settings тощо).
  2. Прописала усі User Flows та їхні розгалуження (наприклад, User Flow ‘Sign In’, можливі розгалуження: користувача немає в системі, він забув пароль. User Flow ‘Make a Top-up’, можливі розгалуження: користувач перевищив денний ліміт поповнень, він не має достатньо грошей на рахунку, зв’язку з банком немає тощо).
  3. Візуалізувала User Flows за допомогою скриншотів продукту.
  4. У кожному User Flow виокремила таке:
    • dead ends, коли користувач не має змоги повернутись чи змінити свій вибір;
    • незрозумілі повідомлення з помилкою, відсутня опція звернутись у підтримку;
    • незрозуміла чи відсутня навігація;
    • відсутність потрібної інформації (наприклад, користувач може підключити функцію регулярних платежів і при цьому обрати день, коли буде здійснюватись платіж, проте після під’єднання в застосунку ніде не показана дата наступного платежу).

Результати

  1. І команда, і замовники краще зрозуміли продукт і його функціонал.
  2. Вдалось визначити та усунути проблемні місця: і в процесі реєстрації нового користувача, і у використанні різних функцій.
  3. Впроваджуючи новий функціонал, разом із замовником тепер можемо пройтись по User Flows і зрозуміти, де потрібно внести зміни.
  4. Зникла потреба щоразу, коли виникало питання «а як воно виглядає на тій сторінці, коли користувач натискає кнопку...», заходити в застосунок і проходити весь сценарій. Тепер можна просто відкрити потрібний User Flow і знайти те, що цікавить.


User Flow: Onboarding

Застосування User Flows під час discovery-фази

Ситуація. Багато проєктів, які ми стартуємо, починаються з так званої discovery-фази, коли потрібно зрозуміти, які проблеми буде вирішувати майбутній продукт, який він матиме вигляд і що буде входити в першу версію. Я була залучена у велику кількість discovery-фаз, часто стикалася з ситуацією, коли замовник настільки захоплювався візуалізацією свого продукту чи навіть певних сторінок, що після кількох тижнів співпраці в нас не було чіткого розуміння, а яким же має бути основний сценарій користувача. Як наслідок, discovery-фаза тривала довше, ніж заплановано, замовник продовжував вносити правки у вигляд тої чи іншої сторінки, а команда не могла оцінити обсяги робіт і відповідно спланувати подальші кроки.

Що зробила я:

  1. Запропонувала перед тим, як починати роботу над візуалізацією концепту продукту, пропрацьовувати основний User Flow.
  2. В основу User Flow взяли розроблений разом з клієнтом story map (перелік User Stories, які формують основний сценарій використання продукту).
  3. User Flow візуалізуємо за допомогою недеталізованих wireframes або взагалі схематично.
  4. Після затвердження основного User Flow з клієнтом починаємо роботу над візуалізацією продукту.

Результати

  1. З’явилось загальне розуміння основного шляху користувача як у клієнта, так і в команди.
  2. Зменшились витрати часу, тому що в процесі дизайну зменшилась кількість змін в User Flow, оскільки він був визначений за допомогою недеталізованих скетчів.
  3. Виникла можливість побачити та виправити проблемні місця в User Flow ще до того, як створено повноцінні дизайни.
  4. Легше визначити обсяг робіт та оцінити витрати часу на реалізацію.


Концептуальний User Flow для Asset Management модуля

Переваги застосування User Flows

  1. Можливість побачити загальну картину та можливі варіанти взаємодії користувача з продуктом.
  2. Візуалізація шляху користувача та його проговорення із замовником і командою.
  3. Ідентифікація прогалини в шляху користувача та можливість зробити його досвід взаємодії з продуктом кращим.

Особливості застосування User Flows

Потрібно бути готовим до того, що User Flows, затверджені на етапі discovery-фази, можуть змінюватись під час роботи над продуктом. Як і будь-які специфікації чи дизайни, User Flows теж потрібно актуалізувати, інколи це трудомісткий процес.

Якщо продукт комплексний, краще створювати дрібні User Flows, а не намагатись візуалізувати весь шлях користувача в одному User Flow — інакше він стане перенасиченим і в ньому легко буде заплутатись. User Flows не замінюють документацію, вони її доповнюють.

Інструменти для візуалізації User Flows

Miro — онлайн-дошка для візуалізації, зокрема для побудови User Flows.

Draw — багатофункціональний редактор для моделювання, зручний для створення Flow charts.

Wireflow — вебплатформа, створена для побудови wireflows, є безкоштовна версія.

Figma — якщо на проєкті дизайни зберігаються в сховищі, яке дає можливість створювати User Flows, краще їх створювати там — можна просто для цього зробити окрему сторінку.

Підсумок

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

👍НравитсяПонравилось12
В избранноеВ избранном6
Подписаться на автора
LinkedIn

Похожие статьи




Підписуйтесь: iTunes | Google Podcast | YouTube


5 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Выглядит интересно и добавляет value команде, рекомендую посмотреть ещё в сторону Event Storming

Дякую, чула про Event Storming, планую випробувати на поточному проекті (там event-driven архітектура, тому особливо актуально)

Тоесть, это визуальное отображение юзер стори?

Один юзер флов може перекривати декілька юзер сторі. Наприклад, юзер сторі «Як юзер я хочу мати можливість оплачувати замовлення карткою» може бути частиною юзер флов «Юзер здійснює замовлення на сайті», який буде містити в собі всі кроки юзера, починаючи від моменту, коли він зайде на сайт, до оплати та підтвердження замовлення.

просто человек научился в блок-схемы ))

Подписаться на комментарии