Основи проектування цифрових продуктів

5. Аналіз результатів дослідження
 

Принципи проектування
та збір інформації

Що розглянемо?

Expierence map

Персона

JTBD

Карта шляху користувача (CJM)

Service Blueprint
 

Expierence map

Expierence map

загальна карта досвіду, що не прив'язана до якогось конкретного сервісу чи інтерфейсу.  

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

Персона

Персона (Persona)

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

Коли варто використовувати:
- проєктування нового продукту.

Сама перона може бути "прото" чи "робочою" персоною.

Складові опису персони:


- блок емпатії (фото, імя, демографія, бекграунд тощо);

- мотиваційний блок (мотив, цілі, задачі);

​- блок опису "ідеальної взаємодії" (Success story);

-  блок мотиваторів та ризиків;

- інше...

Емпатія

До даного блоку слід віднести інформацію, що допоможе покращити сприйняття та емпатію до ЦА,
а саме: фото, ім'я, демографія, бекграунд тощо.                                                           

 

Ім'я та фото зроблять персону більш реальною)

Обираючи ім'я та фото враховуйте специфіку проєкту
та реальних респондентів, ЦА, соц.-культурні
та географічні фактори тощо.

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


 Варто вказати:

- вік;
- стать;
- місцезнаходження;
- сімейний стан;
- рівень доходу/достатку тощо.

У передісторії (background) описують попередній досвід ЦА використання продуктів або послуг для закриття їхніх потреб.

Не варто його деталізувати та "роздувати" наводимо лише те, що стосується суті.

Мотиваційний блок

Даний блок містить основоположну інформацію:


- мотиви (чому?);

- цілі (навіщо?);

- завдання (як?).
                                               
 

Мотив - "чому?"              

маємо знайти/встановити саме глобальну мотивацію котристувача.

Чому він це робить, яка основоположна причина?

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

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

Цілі - "навіщо?"              

Самі цілі формуються мотивом.

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

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

Завдання - "як?"              

Завдання формуються цілями.

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

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

Завдання завжди пов'язані з якоюсь метою.

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

Тереп якщо виникне певна ідея про нову фічу, її вже можна співвіднести із нашим списком)

І якщо вона не відображається в цілях, то її необхідність сумнівна.

Success story

"Ідеальна взаємодія"            

ментальна модель користувача, яка формується виключно на основі реально проведених інтрев'ю.

Формування бачення реального користувача суттєво допомагає обгрунтовувати прийняті рішення при проєктуванні продукту.

А сама модель може бути використана як перший крок у прототипуванні.

Мотиватори та ризики

Мотиватори           

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

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

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

Ризики           

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

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

Зразок

JTBD

JTBD

методологія опису потреби (проблеми) та формування "роботи", яку майбутній продукт буде вирішувати.   

Користувачі "наймають" продукт для виконання певної роботи.

Фокус із характеристик персони зміщуємо більше до контексту.

Job story

Коли [потреба-ситуація], я [дія-бажання], для того, щоб [вигода]

Коли [забула судочок вдома і не можу піти у кафе], я [хочу швидко, смачно-корисно поїсти], для того, щоб [не вмерти з голоду]

Customer
Journey
Map

Карта користувацького шляху (CJM)

покрокова візуалізація взаємодії користувача (клієнта) із продуктом/сервісом із детальним їх кроків, думок та відчуттів на кожному етапі взаємодії.   

Це необхідно для:

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

Що потрібно для формування CJM:

- зібрати інформацію;

- сформувати/обрати персону;

- визначаємо етапи шляху;

- описуємо етапи;

Як збирати інформацію:

- якісні дослідження (інтерв'ю, спостережження, тестування);

- кількісні дослідження (аналітика, статистика, опитування);

- активності із стейкхолдерами, експертами (штурми, воркшопи, обговорення);

- desk research.

Обираємо ключову (найпріоритетнішу) персону
та її основі якої і будеємо CJM.

Це дозволить конкретизувати даний артефакт
та зробити його робочим)


За потреби далі пропрацьовуються й інші персони, для кожної формується виключно своя CJM, але, як правило, не більше 2-3 персон на проєкт.

Визначення етапів шляху

Кількість етапів залежисть від складності продукту/сервісу чи його масштабу.


Крім власне кроків взаємодії із продуктом, також дуже бажано врахувати кроки "до" (виявлення потреби, аналіз, використання конкурентів) та "після" (фідбек, рекомендація, замовлення супутніх послуг).

Опис етапів шляху складається із:


- кроків користувача;

- цілей користувача;

- бар'єрів, перепон, проблемних місць тощо;

- емоцій;

- ідей та рекомендацій.

Що далі:


- формування CJM для інших персон;

- детальне вивчення проблемних зон;

- пріоретизація проблем та рекомендацій;

- підтримка актуальної версії карти;

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

Service
Blueprint

Service Blueprint

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

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

User Flow

Дякую за увагу!