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

Читайте також: 8 секретів професії цифрового продакт-дизайнера

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

• аналітики даних;
• дослідження користувачів;
• графічного та UX-дизайну;
• анімації;
• бізнес-стратегії.

Кожним напрямком можуть займатись окремі фахівці, однак всі ці речі належать і до зони відповідальності продакт-дизайнера.

Бізнес-аналіз

Business Analysis Body of Knowledge (або BABOK) — це професійний стандарт/сукупність знань з бізнес-аналізу, що розробляється Міжнародним інститутом бізнес-аналізу (IIBA).

Бізнес-аналіз — це діяльність, спрямована на зміни у компанії, визначення потреб і рекомендацію рішень, що забезпечують цінність для зацікавлених осіб.

Основні поняття бізнес-аналізу

Stakeholder: зацікавлена людина чи організація, яка розробляє бізнес-цілі та визначає стратегію.

Customer: учасник процесу, який користується продуктами і послугами, що їх надає організація

Business goal: умови, за яких бізнес повинен досягнути бажаного рівня (наприклад, вартості у 1000$). Цьому явищу підпорядковується поняття Business need — це те, що визначає задачу (чи справді мій бізнес повинен коштувати 1000$).

Requirements: вимоги, можливості й умови, необхідні для розв’язання проблем і досягнення мети.

Eliciation: отримання інформації або вимог від зацікавлених осіб, стейкхолдерів.

Validation: вибір оптимального рішення, що відповідає вимогам і цілям зацікавлених осіб.

Product scope: властивості та функції, які характеризують продукт, сервіс чи результат.

Use case: сценарій, за яким користувач взаємодіє з програмою, застосунком, щоб досягти конкретної мети.

User story: неформальні короткі описи рішень, які презентують бізнес-аналітики.

Product backlog: набір усіх пріоритетних user stories, вимог або властивостей.

MVP (minimum viable product): життєздатний продукт, який має мінімум потрібних функцій.

Release: випуск версії продукту, набір нових або модифікованих функцій, протестованих і рекомендованих до використання.

Вимоги за рівнем поділяються на:

• бізнес-вимоги: найвищий рівень, визначають цілі продукту;
• вимоги користувачів: визначають, що саме потрібно користувачам від продукту, і описують рішення цих задач;
• функціональні: опис усіх елементів функціоналу, який має бути у продукті, щоб він відповідав вимогам користувачів.

За типом:

• функціональні: описують безпосередньо функціонал продукту;
• нефункціональні: характеристики продукту, його оточення та обмеження. Наприклад: обмеження платформ та операційних систем, які підтримують продукт; вимоги щодо продуктивності, безпеки тощо.

Product Thinking

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

Product thinking — це нелінійний процес. Спочатку виникає ідея і ми вивчаємо ринок і користувачів. Тут важлива емпатія, потрібно відчути проблеми аудиторії та знайти способи їх розв’язати. Ми робимо висновки, створюємо умовний прототип, 2-3 варіанти і тестуємо їх на споживачах.

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

Процес product thinking:

• Визначаємо, яку проблему ми розв’язуємо і для кого.
• Формуємо бачення: навіщо ми це робимо і як? До цієї стадії ми повинні постійно повертатись, коли отримуємо нові дані.
• Створюємо стратегію: визначаємо мету (наприклад, певний показник KPI) і знаходимо способи її досягнення.

Зрештою ми отримуємо таку схему, з якою далі працюватимемо:

Методології

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

• Що потрібно?
• Навіщо?
• Коли?
• Де?
• Кому?
• Як?

Відповіді на них дадуть вам необхідну інформацію для подальшої роботи.

Ще один метод — розібрати  мету за кожним пунктом абревіатури SMART.

• Specific — мета має бути чітка;
• Measurable — вимірювана;
• Attainable — досяжна;
• Relevant — відповідна вимогам;
• Timely — своєчасна.

Метод Business Model Canvas:

Той самий метод на прикладі Uber:

Моделі взаємодії в команді

Waterfall: каскадна модель розробки — послідовне і швидке створення продукту з передбаченими витратами і термінами. Однак тут є ризик отримати не зовсім той результат, що потрібен, адже на процес майже не впливають нові дані. Ця модель добре працює для дуже маленьких проєктів, де є одна чітка позиція, на якій все базується.

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

Iterative: ітеративна, або повторювана, модель подібна на збирання пазлу. У вас є маленький фрагмент — частина функціоналу — від нього будується більша картинка і цей процес повторюється.

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

З чого складається методологія Scrum

Product backlog — список усіх вимог (user stories), які потрібно зробити взагалі.

Sprint backlog — список усіх вимог (user stories), які потрібно зробити найближчим часом (в найближчий sprint).

Sprint goal — опис того, для чого виконується певний sprint.

Sprint burndown chart — дослівно «діаграма згоряння», елементами якої є ресурси, людиногодини, story points тощо. Якщо щось іде не так, ми повинні це бачити.

Sprint planning meeting — команда обирає вимоги з Product Backlog і формує Sprint Backlog.

Daily meeting — щоденні зустрічі команди, відповіді на запитання: що ми робили вчора, чим займаємось сьогодні та які виникають проблеми?

Sprint review — після кожного спринту команда проводить демонстрацію отриманих результатів, показує демоверсію стейкхолдеру.

Restospective — обмін досвідом в команді, зустріч після Sprint Review, тут всі діляться ідеями, враженнями.

Маніфест AGILE

1. Люди і взаємодія важливіші за процеси й інструменти.
2. Продукт, який працює, важливіший за вичерпну документацію.
3. Співпраця із замовником важливіша за узгодження умов контракту.
4. Готовність до змін важливіша за початковий план дій.

Метрики і тестування

UX-методи:

Дизайн-стратегія: створення користувацьких journey-мап, personas, визначення ціннісних пропозицій (value proposition), опитування стейкхолдерів, дослідження конкурентів і ключових показників ефективності.

Формування концепції: брейнштормінг, сторіборди, user flow, мудборди.

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

Дослідження користувачів та валідація: рекрутинг фокус-групи, тестування юзабіліті, A/B-тестування, інтерв’ю, опитування користувачів.

Найкращий спосіб зрозуміти, що працює в інтерфейсі, а що ні — спостерігати, як ним користуються люди. Nielsen Norman Group

Дослідники стартапів з nea.com виявили, що компанії, які дбають і вкладаються в дизайн, отримують на 14% більше прибутку. Також їхній продукт на 44% краще запам’ятовується, має на 21% більшу залученість споживачів, а цикл продукції пришвидшується на 30%.

Раніше Telegraf.Design розповідав про те, у чому різниця між продуктовим та сервіс-дизайном.