Привіт, мене звати Богдана (Bohdana Muzyka, Lead Business Analyst в TechMagic), розвиваю напрям бізнес-аналізу в компанії 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 та різноманітної термінології, але мета статті не в цьому, тому наведу лише ті категорії, якими керуюсь на практиці.
- За способом візуалізації:
- Flow charts — User Flows з використанням лише графічних елементів та тексту;
- Wireflows — User Flows з використанням wireframes (схематичного зображення) чи дизайнів.
- За обсягом:
- 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
- Наявність зайвих кроків на шляху користувача, які не мають жодного функціонального навантаження.
- Пропущені кроки, які не дають можливості користувачу продовжити свій шлях.
- Dead ends — неможливість користувача повернутись чи змінити свій вибір.
- Опрацювання помилок, валідаційні повідомлення;
- Опрацювання empty states (коли не має інформації для зображення: не заповнені дані, відсутність результатів пошуку тощо).
Застосування User Flows під час роботи над новим продуктом
Ситуація. На одному з проєктів вимоги до продукту (програми для оформлення замовлень у магазині) формувались так: замовник спілкувався з потенційними клієнтами (кінцевими користувачами), далі влаштовував «мозковий штурм» з дизайнером на своїй стороні, який після цього малював екрани. Враховуючи те, що дизайнер працював паралельно ще над кількома проєктами та не був експертом у галузі, до екранів виникало чимало питань у команди розробників, таких як: «Куди потрапить користувач, якщо клікне на цю кнопку? Чому це поле зображене як dropdown, а на цій сторінці це вже як звичайне текстове поле? Як виглядатиме ця сторінка, якщо список буде порожній?».
Взяти участь у «мозковому штурмі» не було можливості через різницю в часі, а надати доступ до кінцевого користувача замовник відмовився. Як наслідок, розробники витрачали час і нерви на обговорення того, як і що має працювати.
Що зробила я:
- Визначила основні ролі користувачів майбутнього продукту (Shop Assistant, Customer).
- Сформувала перелік цілей, які ці користувачі хочуть досягти за допомогою продукту — вони лягли в основу User Flows (Register a new customer, Shop for Products, Fulfill an Order тощо).
- Підтвердила список цілей у замовника.
- Переглянула наявні дизайни та візуалізувала User Flows спершу для однієї ролі (Shop Assistant).
- В кожному User Flow виокремила такі моменти та обговорила їх із замовником і командою:
- відсутні empty states;
- відсутні валідаційні повідомлення та екрани з повідомленнями про помилку;
- незрозуміла або відсутня навігація;
- суперечливі елементи (різні типи одного й того ж поля на різних сторінках);
- dead ends — коли користувач не має змоги повернутись назад.
Результати
- Більш ефективний спосіб обговорення вимог і дизайнів із замовником.
- Зменшення часу, який витрачали розробники на розуміння того, що потрібно реалізувати.
- Можливість донести замовнику ідеї для поліпшення продукту з погляду UX.
- Можливість побачити big picture і розглянути різні сценарії користувача, що складно або неможливо, якщо працювати лише з окремими сторінками.
User Flow: Add product to Shopping Cart
Застосування User Flows під час роботи над продуктом, розробленим кимось іншим
Ситуація. Часто доводилось працювати над проєктами, де команди отримують у спадок продукт і часто скаржаться на те, що ніде не задокументовано, як він працює, який має функціонал. У результаті багато часу йшло на те, щоб зрозуміти, що і як функціонує, що вважати багом, а що фічею, де шукати те чи інше налаштування. Так було й на одному з останніх проєктів, де займаємося мобільним застосунком. Тут не лише для нас як розробників продукт був новим, а й для замовників, які перейняли його від попередніх власників.
Що зробила я:
- Дослідила продукт і визначила User Flows (Register, Sign In, Make a Top-up, Change Profile Settings тощо).
- Прописала усі User Flows та їхні розгалуження (наприклад, User Flow ‘Sign In’, можливі розгалуження: користувача немає в системі, він забув пароль. User Flow ‘Make a Top-up’, можливі розгалуження: користувач перевищив денний ліміт поповнень, він не має достатньо грошей на рахунку, зв’язку з банком немає тощо).
- Візуалізувала User Flows за допомогою скриншотів продукту.
- У кожному User Flow виокремила таке:
- dead ends, коли користувач не має змоги повернутись чи змінити свій вибір;
- незрозумілі повідомлення з помилкою, відсутня опція звернутись у підтримку;
- незрозуміла чи відсутня навігація;
- відсутність потрібної інформації (наприклад, користувач може підключити функцію регулярних платежів і при цьому обрати день, коли буде здійснюватись платіж, проте після під’єднання в застосунку ніде не показана дата наступного платежу).
Результати
- І команда, і замовники краще зрозуміли продукт і його функціонал.
- Вдалось визначити та усунути проблемні місця: і в процесі реєстрації нового користувача, і у використанні різних функцій.
- Впроваджуючи новий функціонал, разом із замовником тепер можемо пройтись по User Flows і зрозуміти, де потрібно внести зміни.
- Зникла потреба щоразу, коли виникало питання «а як воно виглядає на тій сторінці, коли користувач натискає кнопку…», заходити в застосунок і проходити весь сценарій. Тепер можна просто відкрити потрібний User Flow і знайти те, що цікавить.
User Flow: Onboarding
Застосування User Flows під час discovery-фази
Ситуація. Багато проєктів, які ми стартуємо, починаються з так званої discovery-фази, коли потрібно зрозуміти, які проблеми буде вирішувати майбутній продукт, який він матиме вигляд і що буде входити в першу версію. Я була залучена у велику кількість discovery-фаз, часто стикалася з ситуацією, коли замовник настільки захоплювався візуалізацією свого продукту чи навіть певних сторінок, що після кількох тижнів співпраці в нас не було чіткого розуміння, а яким же має бути основний сценарій користувача. Як наслідок, discovery-фаза тривала довше, ніж заплановано, замовник продовжував вносити правки у вигляд тої чи іншої сторінки, а команда не могла оцінити обсяги робіт і відповідно спланувати подальші кроки.
Що зробила я:
- Запропонувала перед тим, як починати роботу над візуалізацією концепту продукту, пропрацьовувати основний User Flow.
- В основу User Flow взяли розроблений разом з клієнтом story map (перелік User Stories, які формують основний сценарій використання продукту).
- User Flow візуалізуємо за допомогою недеталізованих wireframes або взагалі схематично.
- Після затвердження основного User Flow з клієнтом починаємо роботу над візуалізацією продукту.
Результати
- З’явилось загальне розуміння основного шляху користувача як у клієнта, так і в команди.
- Зменшились витрати часу, тому що в процесі дизайну зменшилась кількість змін в User Flow, оскільки він був визначений за допомогою недеталізованих скетчів.
- Виникла можливість побачити та виправити проблемні місця в User Flow ще до того, як створено повноцінні дизайни.
- Легше визначити обсяг робіт та оцінити витрати часу на реалізацію.
Концептуальний User Flow для Asset Management модуля
Переваги застосування User Flows
- Можливість побачити загальну картину та можливі варіанти взаємодії користувача з продуктом.
- Візуалізація шляху користувача та його проговорення із замовником і командою.
- Ідентифікація прогалини в шляху користувача та можливість зробити його досвід взаємодії з продуктом кращим.
Особливості застосування 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 і перевірити, якою буде реакція. В будь-якому разі в процесі формування шляху користувача ви точно зможете дізнатися щось нове про продукт та отримати можливість зробити його трішки кращим.