Перетворюємо бачення на роадмап

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

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

Рівні деталізації:

1. Зведений роадмап компанії («роадпам роадмапів»)
2. Загальний роадмап відділу
3. Окремий роадмап кожної з команд

Роль роадмапу є відрізняється на різних рівнях зрілості бізнесу

• Рівень №0: Роадмапа відсутня Прим.: для стартапів на ранніх, «гаражних» стадіях це допустимо.
• Рівень №1: Пріоритезований список фіч які СЕО хоче зробити за 1 рік. Прим.: однак з часом стартап потребуватиме якогось плану, тому CEO складає список всього функціоналу який бажає бачити в продукті.
• Рівень №2: Пріоритезований список фіч які пропонують кожен з відділів на 1 рік. Прим.: з часом команда починає пропонувати створити фічі, які потрібні тільки їм. Тому пріоретизований СЕО список фіч перетворюється на пріоретизований список побажань всієї команди. Однак, часто це не дуже життєздатний підхід, Бо в обох випадках бізнес намагається створити продукт який збирається продати, а не продукт який користувачі очікують купити.
• Рівень №3: Пріоритезований список побажань від користувачів на 1 рік. Прим.: через деякий час команда починає розуміти що це дорога в нікуди, адже користувачі не купують чи взаємодіють з продуктом так, як очікувалось. Тому найочевиднішим кроком буде спитати у користувачів що їм потрібно. І перетворити пріоретизований список побажань команди на пріоретизований список побажань користувачів. Іноді це можуть називати customer development, але на жаль це є помилкою. Бо часто те, що користувачі кажуть що вони хочуть не є насправді тим, що їм потрібно.
• Рівень №4: Виконання стратегії досягнення короткострокових бізнес результатів задовольняючи потреби які вже відомі користувачам (1 рік). Прим.: врешті-решт, команда поступово приходить до розуміння що попередні підходи не працювали. Тому бізнес починає писати перші стратегії досягнення короткострокових результатів за рік та вчитися використовувати OKRи. Для нас, дизайнерів, мислення бізнесу на цьому рівні схоже послідовність запитань Lean UX Canvas.
• Рівень №5: Виконання стратегії досягнення середньострокових бізнес результатів задовольняючи потреби які вже відомі користувачам (2-3 роки). Прим.: після того, як бізнес побачив ефект від такого підходу, їх лідери починають розширювати вікно стратегічного планування на 2-3 роки від сьогодні.
• Рівень №6: Виконання стратегії досягнення довгострокових бізнес результатів передбачуючи задоволення потреб про які ще не відомо користувачам (5-8 рік). Прим.: на останок, найуспішніші та найбільші бізнеси мають потреби та ресурси, щоб займатися довгостроковим плануванням. Створюючи рішення для проблем, про які користувачі навіть не здогадуються що вони в них виникнуть через 5-8 чи більше років від сьогодні.

Роадмап дизайнерів є невід’ємною частиною продуктового роадмапу

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

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

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

Створення плану розвитку продукту

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

Однак ми не можемо реалізувати одразу наше бачення користувацького досвіду через 18 місяців від сьогодні. Тому нам варто вибрати якийсь проміжний майлстоун. Скажімо, за 9 місяців від сьогодні.

Як наслідок ми отримаємо три версії продукту:

1. Версія №1 — «робимо зараз»
2. Версія №2 — «робимо потім»
3. Версія №3 — «робимо в майбутньому»

Після того як ми створили три версії продукту, там варто створити план еволюції користувацього досвіду.

Для прикладу подивіться на план розвитку інтернет магазину.

Але в якому порядку ми маємо проектувати функціонал з цього списку?

Для цього нам допоможе фреймворк RICE. В ньому ми використовуємо чотири параметри:

• Охоплення (Reach): яку кількість користувачів торкнуться зміни за певний проміжок часу? Прим. №1: якщо продукт вже існує, то для вирахування охоплення можна використовувати дані з сервісів аналітики (Google Analytics, Mixpanel, Hotjar, Amplitude тощо). Прим. №2: якщо продукту ще не існує, то показник охоплення можна ігнорувати, використовуючи спрощену версію фреймворку під назвою ICE.
• Вплив (Impact): який вплив це матиме на користувача / бізнес? → наскільки суттєво ми змінюємо користувацький досвід? Наприклад: значний (3x), великий (2x), середній (1x), низький (0.5x), мінімальний (0.25x).
• Впевненість (Confidence): наскільки впевнені ми в результатах? Наприклад: висока = 100%, середня = 80%, низька = 50%. Прим: тут мається на увазі наша внутрішня впевненість у тому що наше рішення, технологія чи паттерн буде працювати так як ми очікуємо. Наприклад, якщо ми додамо на чекаут форму можливість доставки через Укрпошту, то наша впевненість буде «високою». В цьому нічого немає складного, бо процес відомий та існує документація. Якщо ми будемо додавати підтримку голосового помічника Siri, то в нас виникне багато ризиків як технологічного характеру, так і ризиків які стосуються користувацького досвіду. Тому наша впевненість буде «низькою», адже як команда ми до цього нічого подібного не робили. Однак, якщо ми пізніше будемо додавати підтримку голосового помічника Alexa, то наша впевненість в цій ініціативі буде «середньою». Адже ми раніше мали справу зі схожим помічником Siri.
• Зусилля (Effort): скільки часу потребує створення цього функціоналу? Прим.: краще рахувати в людино-годинах, тижнях чи місяцях. Наприклад, «для створення цієї фічі потрібен 1 дизайнер який буде працювати плюс-мінус 1 місяць» тощо.

Формула RICE

Калькулятори:

1. Компанія Intercom створила калькулятор для Google Slides [посилання] та Excel [посилання].
2. Розробник Кріс МакКормік зробив веб-версію калькулятора від Intercom [посилання].

💡

Оцінка зусиль для роадмапи має бути дуже приблизною. Це дуже добре описує ідеома «прикинути на око». Для цього я раджу використовувати футболки, які можна посортувати у шість кошиків за розміром: від дуже маленького (XS) до величезного (XXL). Оцінка кожного з розмірів є дуже приблизною. Ви можете використовувати як тлумачення з прикладу нижче. Так і адаптувати цей підхід до специфіки та часових рамок вашого продукту.

Прим: в середньому в місяці 21 робочий день.

Приклад пріоретизації версії №2 інтернет магазину вказаного вище.

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

Створення роадмапи

Для створення плану розвитку продукту нам потрібно розуміти основи проектного менеджменту. Це виходить за рамки даного курсу. Однак раджу звернути увагу на цю програму від Coursera.

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

1. 15 днів на дослідження
2. 23 дні на дизайн
3. 1 день на написання текстів
4. 1 день на підготовку макетів для передачі в розробку

Якщо ми повернемо цю діаграму на 90 градусів, в нас вийде приблизно така діаграма Ґанта ↓

Зверніть будь ласка увагу, що кроками 2 та 3 проілюстрована залежність — ми не можемо [передати макети розробтикам] поки [не напишемо до них тексти].

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

Як наслідок, наша команда може працювати над декількома ініціативами одночасно. Створюючи роадмапу, таку можливість також треба враховувати.

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

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

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

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

Практичне завдання

Це практичне завдання не є обов’язковим, але спробуйте потренувати стратегічне мислення.

Частина №1: вирахувати бізнес-стратегію продукту над яким ви працюєте

1. Який тип компанії та бізнес модель?
2. Як бізнес конкурує на ринку?
3. Якими [ми припускаємо] є дороговказна та контрметрики?

Частина №2: створити бачення користувацького досвіду за 18 місяців від сьогодні

1. Описати це бачення за допомогою сторіборду чи прес-релізу [приклад прес-релізу по методології Working Backwards від Amazon та інструкція знаходиться в цьому пості на LinkedIn (англ)]
2. Вибрати проксі-метрику та контрметрику дизайну (за необхідності)
3. Переконатися що бачення відповідає стратегії бізнесу

Частина №3: створити роадмап втілення майбутнього бачення

1. Створити список функціоналу для досягнення майбутнього бачення за 18 місяців від сьогодні (версія №3 / «робимо в майбутньому»).
2. Створити, оцінити та пріоретизувати список необхідних робіт та функціоналу для досягнення проміжного майлстоуну за 9 місяців від сьогодні (версія №2 / «робимо потім»).
3. Створити графік створення дизайну для версії №2, проілюструвавши його діаграмою Ґанта в будь якій зручній програмі (Google Sheets, Miro, Notion, Trello, Jira тощо). Прим: якщо ви створюєте продукт з нуля, то до пунктів 2 та 3 додайте версію №1 або ж «робимо зараз».