Рекомендації бізнесу за результатами досліджень

Презентація про рішення

Найкращим способом прокомунікувати результати нашого дослідження — створити презентацію.

Ми рекомендуємо дотримуватись такої структури:

Аудиторія

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

Ми рекомендуємо почати з трьох груп стейкхолдерів:

1. Топ-менеджер: як я створю конкурентну перевагу?

• Типові ролі: СЕО, С-level менеджери та (часто) клієнти.
• Мета: створити та реалізувати довгострокову стратегію розвитку бізнесу.
• Відхиляють: рішення, які акцентують увагу на минулому (проблеми).
• Шукають: рішення що допомагають розвинути бізнес (можливості).
• Рівень деталізації: читають лише стислі висновки та резюме.

2. Менеджер: як я покращу продукт?

• Типові ролі: project manager, product owner, product manager тощо.
• Мета: зробити погоджений обсяг робіт вчасно та якісно.
• Відхиляють: довгі історії з великою кількістю технічних подробиць.
• Шукають: рішення що допоможуть досягти зміни продуктових метрик.
• Рівень деталізації: читають основні тези щоб прийняти рішення (тобто «по-діагоналі»).

3. Виконавці: як я зроблю цей функціонал?

• Типові ролі: розробник, дизайнер, SEO-спеціаліст тощо.
• Мета: детально зануритись у проблему, щоб зрозуміти що треба зробити.
• Відхиляють: абстрактні історії, які не зрозуміло як застосувати на практиці.
• Шукають: чіткого скоупу робіт написаного зрозумілою їм мовою.
• Рівень деталізації: менше історій, більше фактів та подробиць.

8-12 слайдів є оптимальним розміром презентації

1. Титульна сторінка
2. Зміст
3. Сторінка про авторів
4. Резюме (executive summary)
5. Опис проблеми / можливості
6. Опис рішення
7. Наступні кроки / вартість та тривалість робіт (для комерційної пропозиції)
8. Слайд подяки / контакти (для комерційної пропозиції)

Секція №1: Відкриття презентації

Ми завжди починаємо описувати наші результати з резюме (анг. executive summary) довжиною не більше 3-4х речень. Найближчою аналогією є пітч.

Структура резюме:

1. Проблема: Яку проблему ми вирішували / можливість виявили, що про неї дізналися та чому вона важлива?
2. Рішення: Як рішення працює (з точки зору спостерігача, етік)?
3. Результат: Що зміниться для користувачів та бізнесу після запуску цього рішення?

Приклад №1:

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

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

Як наслідок, ми очікуємо збільшення коефіцієнту залученності наших користувачів з 0.5% до 1.5% за квартал після релізу.

Приклад №2:

Ми дізналися, що ⅓ звернень до служби підтримки становлять дзвінки з уточненням часу доставки замовлення. Тому ми пропонуємо додати до форми замовлення можливість вказати дату та час доставки. Як наслідок, це допоможе нам знизити операційні витрати на службу підтримки приблизно на (100/8)×$75 = ~$1000 на місяць.

Секція №2: Опис проблеми

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

[Кількість респондентів/користувачів] [дієслово] [спостереження] тому що [виявлена причина].

Приклад №1 (проблема, кількісні дані):

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

Приклад №2 (можливість, якісні дані):

10 з 12 респондентів на останньому раунді інтерв’ю розповіли що їм важко дивитися відео в дорозі тому що стабільний та швидкий інтернет доступний не скрізь.

Пріоритезація проблем

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

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

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

Однак, давайте розглянемо 4 групи функціоналу якими оперує ця модель:

1. Функціонал, очікуваний користувачем.
2. Функціонал, що впливає на продуктивність користувача.
3. Функціонал, що приваблює користувача.
4. Функціонал, на який користувачу байдуже.

Якщо стисло, то функціонал потрапляє в ці категорії після співставлення відповідей респондентів на два запитання:

1. Як ви ставитесь до того, що [цей функціонал] присутній в продукті?
2. Як ви ставитесь до того, що [цей функціонал] відсутній в продукті?

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

Модель захоплення Дани Чіснел

Але що означає функціонал який приваблює користувача? Як ми це можемо застосувати до нашої роботи?

В цьому нам допоможе модель захоплення, запропонована Даною Чіснел, відомою американською дизайнеркою та менеджеркою. Вона пропонує розділяти «задоволення» на три категорії:

1. Задоволення (Pleasure): спроектовані елементи та функціонал задовольняють потреби та перевищують очікування користувача.
2. Взаємодія (Flow): оптимізація взаємодії з продуктом що суттєво покращує досвід користувача. Ми це робимо шляхом покращення двох аспектів:
• Час досягнення мети: час, який користувач витрачає на отримання результатів, яких він очікує від продукту чи сервісу. Інакше кажучи, час подорожі персони мапою клієнтського шляху.
• Час використання продукту: відсоток часу, який користувач витрачає на взаємодію з продуктом, що не стосується досягнення мети. Наприклад: реєстрація, онбординг, повторне введення інформації яку система вже знає чи може отримати з інших джерел самостійно.
3. Зміст (Meaning): спроможність користувача викликати заздрість у оточення за допомогою продукту чи сервісу.

Накладаючи модель захопдення Дани Чіснел на модель Kano, ми отримуємо збірник тактичних комбінацій для проектування користувацького досвіду та його комунікації з різними групами стейкхолдерів:

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

Секція №3: Опис рішення

Стейкхолдери будь якого рівня приймають рішення на емоціях, на відміну від виконавців.

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

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

Три кроки для побудови історії

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

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

Крок №3: опишіть як працюватиме ваше рішення з точки зору користувача (емік), та як воно дозволить користувачу досягти своєї мети.

Візуалізацією історії є сторіборд, наприклад 3×3, що поєднує подорож героя, контекст та екрани застосунку.

Шість правил переконливих історій

1. Розглядайте користувацький досвід цілісно та на всіх точках взаємодії.
2. Дотримуйтесь 3х-актної структури історії.
3. Прив’язуйте історію до мапи клієнтського шляху.
4. Посилюйте презентацію кількісними даними.
5. Використовуйте словник, що зрозумілий вашій аудиторії.
6. Завжди пропонуйте наступні кроки.

Секція №4: Опис результатів

Для опису результатів можна перетворити гіпотезу яку ми перевірили у щось накшталт такого:

1. Якщо ми [запустимо це рішення], то [вирішимо проблему / створимо можливості]. 
2. Як наслідок, ми очікуємо [отримати ці відгуки від користувачів / досягти бізнес-результатів].

Приклад №1:

1. Якщо ми додамо доставку товарів на вказаний день та час, то зменшимо навантаження на службу підтримки з ~300 годин → ~200 годин.
2. Як наслідок, це допоможе нам знизити витрати на службу підтримки на (100/8) × $75  = ~$1000 / місяць.

Приклад №2:

1. Якщо ми запустимо функціонал завантаження відео на мобільних застосунках, то користувачі зможуть переглядати фільми в дорозі чи при відсутності інтернету.
2. Як наслідок, ми очікуємо збільшення коефіцієнту залученності з 0.5% до 1.5% за квартал після релізу.

Секція №5: Опис наступних кроків

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

Приклад №1:

Якщо ми додамо доставку товарів на вказаний день та час, то зменшимо навантаження на службу підтримки з ~300 годин → ~200 годин. Як наслідок, це допоможе нам знизити витрати на службу підтримки на (100/8) × $75 = ~$1000 на місяць.

Нашими наступними кроками будуть:

1. Якщо ви згодні, то ми плануємо зустрітися з менеджером служби доставки [коли?], щоб зрозуміти як ми можемо реалізувати цю послугу.
2. Ми плануємо зустрітися з тімлідом розробників [коли?], щоб оцінити скільки часу займе для додавання цього функціоналу на сайт.
3. Після цього нам потрібно 2-3 дні щоб передати дизайн в розробку.

Приклад №2:

Якщо ми запустимо функціонал завантаження відео на мобільних застосунках, то користувачі зможуть переглядати фільми в дорозі чи при відсутності інтернету. Як наслідок, ми очікуємо збільшення коефіцієнту залученності з 0.5% до 1.5% за квартал після релізу.

Нашими наступними кроками будуть:

1. ми підготуємо моки, тексти та передамо їх розробникам в цьому спринті;
2. тімлід розробників попередньо оцінював роботу в 2-3 спринти щоб додати підтримку фічі на бек-енді та 1 спринт щоб оновити мобільні застосунки. Якщо ви згодні, [хто розробникам поставить задачу]?

Фреймворк для роботи зі зворотнім зв’язком

Подякуйте → підсумуйте → підготуйте відповідь

• Подякуйте: покажіть повагу до стейкхолдерів та подякуйте їм. «Дякую, що розповіли про цей важливий аспект. Ми не досліджували проблему з цієї сторони».
• Повторіть: стисло підсумуйте сказане, щоб показати що ви слухаєте. «Якщо я правильно вас розумію, то можуть виникнути складнощі з доставкою товару на вказаний час та дату. Адже ми користуємось послугами партнерської логістичної компанії».
• Підготуйте відповідь: покажіть що ви готуєтесь відповісти. «Згоден, це може ускладнити реалізацію цього функціоналу. Тому давайте повернемось до слайдів з проблемою щоб разом з вами знайти рішення».