Usability Testing від А до Я: докладний гід

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

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

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

Найчастіше юзабіліті-тестування проводиться у два етапи: проходження користувачем N-го кількості завдань (кількісні або якісні тести), а також бесіда, заповнення опитувальників або глибинні інтерв'ю з користувачем (якісне дослідження).

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

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

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

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

Визначення мети

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

Що для вас у дослідженні буде важливим? Які ролі користувачів або їх конкретні завдання прагнете протестувати?
Що сподіваєтеся зафіксувати в нотатках? Приміром, хочете використовувати відеозйомку, а в протоколах позначати цікаві моменти з прив'язкою до відео для швидкого пошуку та обробки зворотного зв'язку.
Чи плануєте вивчити робочий простір користувачів? Є випадки, коли воно впливає на організацію інтерфейсу.
Чи є необхідність у фото - або відеозйомки у процесі спостереження за користувачем? Можливо, якісь сценарії простіше записати на відео. Наприклад, при проектуванні моніторингової системи свердловин необхідно зрозуміти, з якими пристроями передачі даних взаємодіє Service Supervisor і яка кількість моніторів він використовує.
Які метрики будуть використані у тестуванні? Кількісні та/або якісні? Це залежить від того, що вам в дослідженні цікаво і що перевіряєте. Якщо працюєте над додатком, призначеним для робочого процесу користувача, навряд чи вас буде цікавити ступінь його залучення. Ви, ймовірно, будете зацікавлені в швидкості проходження сценаріїв, кількості користувальницьких помилок, виконаних сценаріїв і ступеня задоволеності користувача.

Створення плану тестування

Для формування плану тестування потрібно насамперед визначити:

Який продукт або продукти плануєте вивчити? Наприклад, закрита Product Experience Management веб-платформа, що забезпечує управління всією інформацією про товар/виріб.
Що буде предметом тестування? Приміром, та ж веб-платформа або клікабельний адаптивний прототип її нової версії.
Які типи пристроїв будуть використані? Наприклад, персональний комп'ютер (ПК), планшет і мобільний телефон.
Які ролі та функції користувачів будуть протестовані? Припустимо, роль: PDM-адміністратор. Функції/завдання: створення шаблону для товару або вироби, перевірка шаблону товару, затвердження шаблону.

Якщо є кілька продуктів, такі як мобільний web - і desktop-додаток, і ви хочете протестувати кожен з них, то краще робити це в різний час. Так отримаєте більш точні відгуки і уникнете змішаних почуттів від тестування всіх продуктів відразу.

Для спостереження я, як правило, готую документ для кожного користувача — дорожню карту, яка розповідає, що і як робити і на які питання відповідати. Документ називається UX testing plan & script і складається з таких елементів:

вступ;
занурення в контекст користувача розв'язуваних завдань;
опис завдань і список кроків з можливістю занесення коментарів щодо кожного з них;
список питань до кожної задачі;
заключний раунд запитань.

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

Зазвичай при формуванні завдань проводжу їх декомпозицію. Що це таке? Я заміняю рішення однієї задачі на серію дрібних простих і пов'язаних між собою підзадач з конкретною метою в кожній.

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

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

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

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

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

Завдання для якісних досліджень: знайдіть на сайті звіт за перший квартал 2019 року.

Завдання для кількісних досліджень:

А. Використовуючи глобальний пошук на сайті, знайдіть звіт за перший квартал 2019 року.
Ст. Використовуючи розділ Reports на сайті, знайдіть звіт за перший квартал 2019 року.

У якісних дослідженнях ми зрозуміємо користувальницьке перевагу user-flow, а в кількісних — роз'яснимо, всі кроки конкретного user-flow зрозумілі користувачеві. Якісні і кількісні дослідження повинні доповнювати один одного, а не протиставлятися.

Як може виглядати задача, пов'язана з авторизацією на сервері.

Приклад сценарію: клієнт попросив вас підготувати звіт, і ви хочете почати з пошуку інформації в межах сайту www.sample.com .

Завдання: будь ласка, увійдіть в систему, використовуючи свій логін і пароль.

Кроки:

Відкрити браузер.
Ввести в адресний рядок www.sample.com .
Ввести електронну пошту в полі Email.
Ввести символи у полі Password.
Натиснути кнопку «Вхід».

Альтернативні кроки:

Відкрити браузер.
Ввести в адресний рядок www.sample.com .
Натиснути посилання «Забули пароль».
Ввести свою електронну пошту.
Відкрити поштовий клієнт.
Знайти лист від сервера авторизації.
Перейти за посиланням.
Ввести новий пароль.
Повторити пароль.
Натиснути кнопку «Змінити пароль».

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

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

Визначення кількості дослідників

Для якісного проведення спостереження необхідно мати наступні ролі:

Інтерв'юер — проводить юзабіліті-тестування, використовуючи UX testing plan & script. Часто така роль дістається самому проектувальнику інтерфейсу.
Спостерігач — уточнює деталі і поглиблюється в них по мірі протікання тестування. У даній ролі можуть виступити продакт-оунер, експерти предметної області або проектувальники інтерфейсу.
Модератор — повинен дотримуватися таймінгу і стежити за тим, щоб всі сценарії були відтворені користувачем. З цим добре справляються проджект - і продакт-менеджери, скрам-майстри. Ще запрошують на цю роль проектувальника інтерфейсів.

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

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

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

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

Визначення цільової аудиторії

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

Наприклад, ви працюєте над фінансовим продуктом і плануєте вивчити діяльність брокера в рамках створення CLO (collateralized loan obligation) бізнесу на американському ринку. В даному випадку потрібно зрозуміти алгоритми взаємодії інвест-банкіра з іншими фінансовими ролями.

Визначитися з цільовою аудиторією допоможуть попередні опитувальники. Їх створюють як на безкоштовних сервісах, наприклад Google Forms, так і у платних — SurveyMonkey, Typeform та інших.

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

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

Правила створення таких опитувальників дуже прості:

Точно формулюйте запитання. Як правило, люди розуміють одні і ті ж фрази по-різному. Використовуючи недостатньо точні формулювання, ми не можемо бути впевнені, що користувач правильно зрозумів питання.
Не питайте у респондентів те, що вам заздалегідь відомо. Наприклад, його ім'я, вік або посаду.
Використовуйте закриті питання скрізь, де є можливість. Користувачам набагато простіше вибрати варіант відповіді, ніж писати свій.
Переконайтеся, що ви включили всі відповідні варіанти відповідей для закритих питань, в тому числі «Інше» або «Свій варіант» на випадок, якщо жоден із запропонованих користувачеві не підходить.
Завжди ставте нумерацію питань.
Показуйте сумарна кількість питань та прогрес-бар, заздалегідь орієнтуючи людини, де він знаходиться і скільки відповідей йому належить дати.

Можна використовувати дихотомические питання ("так"/"ні" відповіді), щоб визначити, на якій наступне запитання буде відповідати респондент. Це нескладно робиться, наприклад, з допомогою Google Forms .

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

У разі ковзної шкали варіанти 6-9 належать категорії «частково згоден», проте немає можливості зрозуміти, чим вони відрізняються. Тут варто уникати великої кількості відповідей без потреби.

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

Вибірка користувачів залежить від багатьох факторів:

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

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

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

На сьогодні є калькулятори для обчислення кількості користувачів. Вони базуються на середньої ймовірності виявлення помилки в одному дослідженні. Однак проблема в тому, що різні дослідники отримують різні показники цієї ймовірності. Приміром, Якоб Нільсен у свій час отримав значення , рівне p=0.31, в той же час дослідження Спула і Шредера приводять до результату p=0.16.

Вибір ймовірності — це завжди великий ризик. Ви можете покладатися на свої дослідження і провести розрахунок своєї ймовірності або використовувати значення p=0.31 для простих сценаріїв і p=0.16 для складних і різноманітних, покладаючись на дослідження інших.

При аналізі різних досліджень випливає один очевидний факт — чим більше користувачів ви протестуєте, тим більше отримаєте точні результати. Але що робити, коли ви обмежені кількістю кінцевих користувачів?

До цих пір в світі сперечаються про те, яке ж мінімальну кількість учасників підходить для тестування. На думку Якоба Нільсена, це 5 осіб, а на думку Лаури Фолкнер — 10.

Я рекомендую починати з 5-10 тестувань одного прототипу для перевірки гіпотез у якісних дослідженнях і 10-20 тестувань — для кількісних. Якщо помилки починають повторюватися, це свідчить про те, що вибірка користувачів однорідна. Також допускається використовувати метод итеративных змін RITE, коли правки вносяться в інтерфейс по мірі виявлення проблем. Проводиться тестування одного користувача.

Якщо група дослідників впевнена, що розуміє суть виявлених проблем, то вона приймає рішення виправляти їх чи ні. Якщо ж немає, вона продовжує тестувати поточний інтерфейс, поки не буде ясна суть. Після внесення правок тестування починається заново. Зазвичай підхід RITE вимагає 5-6 ітерацій.

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

Отримання згоди користувача

Перед початком тесту необхідно отримати дозвіл на участь користувача в конкретному дослідженні. Важливо прописати абсолютно всі умови, за яких воно буде проводитися (приклади умов нижче). Це буде гарною страховкою на предмет використання всіх даних, які ви отримаєте в процесі дослідження.

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

Між тим у кількох випадках у мене була відмова з боку користувачів на застосування будь-яких записів і доводилося документувати сесію вручну.

Приклад:

Я даю свою згоду (назва компанії) на участь у додатковому тестуванні з використанням ноутбука/веб-сайту. Я поінформований(а) і розумію свою роль у проведенні дослідження. Під час сеансу мене попросять знайти інформацію або виконати завдання, використовуючи сайт-прототип, і попросять заповнити анкету після тестування. Сеанс буде знято, але тільки для цілей записи моїх відповідей (записи голосу) та для перевірки моєї поведінки (відео), наприклад, що я натискаю і де на веб-сайті. Моє обличчя буде видно інтерв'юеру і дослідникам під час фізичної присутності, але не буде присутній на відео.

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

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

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

У мене було достатньо часу для прийняття рішення, чи брати участь у цьому дослідженні.

Я розумію, що можу прийняти рішення відмовитися від участі або припинити участь у будь-який час.

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

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

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

Організація доступу

Організуйте доступ до потрібного ПЗ, встановіть обладнання для запису сеансу. Спостереження повинно проходити в природному середовищі для користувача. Аналіз робочого простору важливий, а в конкретних випадках вкрай необхідний.

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

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

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

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

Проведення спостереження

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

Деякі дії складно описати. Якщо я запитаю, як ви катаєтеся на велосипеді, ви напевно не згадайте, з якого боку підходите до велосипеда, якою ногою відштовхуєтеся від поверхні, щоб видертися на нього і так далі. Вам простіше взяти його і продемонструвати вміння.
Деякі описи можуть конфліктувати з реальним поведінкою. На питання, як часто перевіряєте пошту, люди зазвичай відповідають, що роблять це на робочому місці раз на півгодини. Однак, якщо ви біжите по коридору і колега просить вас відповісти на лист, відправлений двома хвилинами раніше, ваша рука потягнеться за телефоном і ви несвідомо перевірити пошту. Але цей факт згадаєте не одразу, і це нормально. Справа в тому, що користувачі не пам'ятають або не знають деталі своїх дій, які можуть бути важливими для дослідників.

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

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

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

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

Уникайте навідних питань. В них містяться підказки, і ви можете несвідомо впливати на результати. Уточніть всі деталі, якщо людина не зрозуміла завдання відразу.

Неправильно:	Правильно:
Наскільки нова версія сайту краще старої?	Порівняйте нову і стару версію сайту. Яку ви віддасте перевагу?

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

Неправильно:	Правильно:
Вас зацікавили можливості сервісу?	Яка з можливостей сервісу здається найцікавішою? Чому?

Не використовуйте питання про майбутньому, так як вони можуть викликати замішання у користувачів і призвести до помилкових результатів.

Неправильно:	Правильно:
Це буде корисним у вашій роботі?	Розкажіть, як це можна застосувати до вашої роботи.

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

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

Робіть нотатки з допомогою попередньо підготовленої структури. У UX testing plan & script зазвичай використовую колонку для запису користувальницьких коментарів до кожного кроку сценарію. Під час виконання завдань роблю невеликі замітки у вигляді «пройшов/не пройшов сценарій», «виникали/не виникали складності». Ці нотатки можна прив'язати до відповідних моментів відео, і ви зможете легко повернутися до них пізніше.

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

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

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

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

Аналіз

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

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

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

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

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

Метод RBT складається з наступних показників:

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

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

Як це робиться? Ми аналізуємо першу задачу одного користувача і фіксуємо конкретні зауваження та цитати на стікерах. На кожному стікері написані імена учасників. Розміщуємо їх на стіні або дошці. Далі наступний користувач вносить свої дані. Після кількох тестів з'являються загальні питання і проблеми.

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

Задайте рейтинг знайденим проблем (Thorn) за шкалою:

Критична помилка. Не працює якась кнопка, якщо це не виправити, користувачі не зможуть завершити сценарій. Наприклад, людина шукає готелі на сайті-посередництва, але не може залогуватися або не відображається результат.
Серйозна помилка. Користувачі будуть засмучені, якщо ми не виправимо помилку. Також є ймовірність, що вони здадуться і не пройдуть сценарій. Наприклад, видача пошуку на сайті бронювання готелів займає 10 секунд. Багато юзери не заходять чекати і підуть на інші ресурси.
Мінорна помилка. Користувачі будуть роздратовані, але це не завадить їм завершити сценарій. Наприклад, очікування відображення результатів скоротиться до 5 секунд. Це продовжить дратувати, але людина, швидше за все, залишиться на сайті, так як він вже витратив свій час і не піде шукати інший сайт, незважаючи на те, що очікування результатів на ньому може бути трохи меншим.

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

В процесі аналізу також будьте готові отримати цікаві факти, які не були пов'язані з тестуючими сценаріями. Наприклад, при тестуванні сценарію «створення чату» в Microsoft Teams веб-версії ви зрозумієте, що у користувача кілька різних робочих акаунтів. Йому доводиться бути авторизованим в системі під різними акаунтами в різних вкладках браузера. Зробити таке desktop-версії неможливо, відповідно, ви отримаєте новий інсайт про те, як користувачі з різними обліковими записами «вирішують» цю задачу, використовуючи ваш продукт.

При аналізі зворотного зв'язку варто замислитись над такими питаннями:

Що або скільки бізнес придбає, якщо прислухається до користувача і впровадить зміни? Приміром, можливість розширення горизонтів бізнесу або лідерство в конкурентному середовищі.
Який відсоток незадоволених користувачів готовий піти від замовника, якщо не буде почутий? Скільки грошей при цьому втратить бізнес?

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

Висновок

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

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

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

Опубліковано: 18/06/20 @ 10:00
Розділ Різне

SEO Блог