Подивитися на продукт очима користувача. Як провести юзабіліті-тестування — 4 кроки

У продуктових IT-компаніях для валідації гіпотез найчастіше використовують A/B тести. Вони дозволяють дізнатися, які оновлення принесуть більше користі. Однак кількісне тестування дає відповідь на питання, що краще. Та не відповідає — чому.

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

У своїй колонці UX researcher в продуктовій IT-компанії Universe Богдана Рущак розповідає про один із методів дослідження — юзабіліті-тестування. Розгляньмо його переваги, а ще як впроваджувати та як перетворювати «болі» користувачів на можливості розвитку продуктів. 

Ad fontes. До джерел

Юзабіліті-тестування (Usability Testing) — це процес визначення, наскільки зручним і простим у використанні є ваш продукт для користувача. 

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

Види юзабіліті-тестування

Є два основні види юзабіліті-тестування: модероване та немодероване.

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

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

• Немодероване юзабіліті-тестування проводиться без участі модератора. Респондент самостійно виконує низку завдань, а його дії записуються для аналізу. Перевага такого тесту в швидкості. Респондент сам обирає, коли йому зручно пройти тест (для цього варто використовувати платну платформу для проведення UX-досліджень). Також немодеровані тести зазвичай вдвічі дешевші за модеровані. 

Недоліки цього тесту: 

• немає можливості ставити уточнювальні питання; 
• респондент може не дати відповіді на всі питання або зробити це в дуже стислій формі. 

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

Структура аналізу даних

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

Спойлер: ця схема відточена до деталей для наших продуктів. Для ваших продуктів/сервісів її можна доповнити або видозмінити. 

Структура аналізу складається з таких частин:

1. Аналіз кожного тесту за методом RTB.
2. Аналіз пріоритетності проблем — Problem priority analysis.
3. Pains to gains Від труднощів до переваг Pains (досл. болі) — негативний досвід, проблеми та ризики, з якими стикається клієнт у процесі взаємодії з продуктом. Gains (досл. вигоди) — переваги, на які очікує та яких потребує клієнт. .
4. Рекомендації.

Тепер детальніше про кожну зі складових.

Аналіз за методом RTB

Уявімо ситуацію: ви провели модерований юзабіліті-тест вашого мобільного застосунка «X». Далі відбувається розшифровка. Її можна робити в спеціальній програмі (наприклад, Dovetail) або на платформі, де проводите тестування (у моєму випадку — Userlytics). Опісля — розпочинається UX magic. Цей термін мій власний. Він передає усю чарівність процесу, коли на білому фреймі в Figma по одному з’являються стікери, що розповідають про досвід користувача, його проблеми та поради.

Під час аналізу важливо звернути увагу на ситуації, коли користувач:

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

Як аналізувати ці дані? 

Найефективніше — за методом RTB. Він передбачає такі індикатори: 

• Rose — зелений стікер — позначаємо усе, що працює добре. Зазвичай, у UX-аналізі саме зеленим позначають усі сильні сторони продукту.
• Bud — синій стікер — стосується користувацького досвіду.
• Thorn — червоний стікер — позначаємо усі проблеми користувача, усе негативне і те, що не працює.

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

Перед кожним аналізом тесту на рожевому стікері прописую, що означає кожен колір. Так кожен член команди зможе швидко орієнтуватися в аналізі та знайти саме те, що йому важливо.

Аналіз пріоритетності проблем 

Цей етап передбачає взаємодію дослідника із замовником дослідження. У моєму випадку це завжди product-менеджер. Відбувається все так:

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

Я категоризую всі знайдені проблеми та помилки. Наприклад у блоці «Home screen» — усі болі та проблеми, які були на основному екрані й так далі. 

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

Pains to gains

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

Наприклад, ми в Universe одразу ж з командою перетворюємо ці завдання на задачі в Jira та встановлюємо зону відповідальності працівників, які працюють над продуктом. 

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

Рекомендації

Для замовника цінно й важливо почути: 

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

Рекомендації як категорію можна поділити на три підкатегорії:

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

Зразок того, як краще структурувати рекомендації:

Презентація результатів дослідження

Отже, ви провели аналіз отриманих результатів і готові презентувати команді продуктові рішення. Та як краще це зробити, щоб разом перетворювати «pains to gains»? 

• Self-check. Дуже важливо перед тим, як надсилати/презентувати результати аналізу, самостійно вичитати та перевірити усі дані. 
• Проведення воркшопу зі стейкхолдером та командою. Перший етап проведення воркшопу в Universe — це презентація результатів дослідження тільки для стейкхолдера. 

Одного разу Head of Operations в Universe — він же стейкхолдер — запропонував поділитися результатами з усією командою, яка працює над продуктом. Власне для них і проводилося дослідження. І було надзвичайно цінно й важливо бачити, що колегам не просто цікаво. Їм хотілося зрозуміти, звідки та як був отриманий той чи інший інсайт, і як будемо перетворювати pains to gains. 

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

• Share через Slack. Після проведення дослідження всі результати з ключовими проблемами, інсайтами та рекомендаціями поширюються ще у відповідний канал у Slack. Оскільки ключові кроки варто тестувати ще й у текстовому форматі. Тоді кожен в зручний для нього час зможе ознайомитися з результатами та поставити уточнювальні питання, а також отримати натхнення на нові ідеї та тести. 

Про цінність воркшопу

Юзабіліті-тестування найефективніше проводити на етапі розробки чи імплементації фічі/сервісу. Це дозволяє зекономити не тільки час, але й позитивно вплине на фінансові та продуктові метрики. 

Як сказав мій менеджер: «У тебе є один момент, щоб презентувати результати дослідження для команди».

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

Підсумую цей текст гаслом нашої компанії від СЕО Universe Ярослава Морозова: «Треба тестувати». Успішного тестування та впровадження нових ідей!