Планування юзабіліті-тестування. Частина 1



Привіт, Хабр! Це Наталія Спрогіс з UX-лабораторії Mail.Ru Group. Сьогодні я розповім про плануванні і підготовці такого виду досліджень, як юзабіліті-тестування. Стаття розрахована в першу чергу на менш досвідчених дослідників і тих, хто збирається вперше проводити юзабіліті-тестування.

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

Точно потрібно тестування?


Для початку ви повинні бути впевнені, що на даному етапі проекту потрібно саме юзабіліті-тестування. Тому уточнюйте реальні цілі звернення до вас проектної команди. Юзабіліті-тестування не всемогутні, і вже на старті потрібно розуміти, що подібне дослідження реально може принести продукту. Відразу підготуйте проектну команду до того, на які питання ви зможете дати відповіді, а на які ні. У нас бували випадки, коли ми пропонували замовникам інший метод (наприклад, зараз краще підійдуть глибинні інтерв'ю або щоденникові дослідження) або навіть взагалі рекомендували відмовитися від дослідження, а замість цього зробити спліт-тест.

Наприклад, ми ніколи не беремося в якісних дослідженнях перевіряти «привабливість» якоїсь функції або варіанти дизайну. Ми можемо зібрати з користувачів відгуки, але занадто великий ризик, що на їх відповіді вплине соціальна бажаність. Люди завжди схильні сказати, що стали б користуватися навіть тим, чим користуватися не будуть. Та й маленький розмір вибірки не дозволяє довіряти таким відповідям. Так, наприклад, у нас був невдалий досвід тестування ігрових лендингов. Коли лендінгем, який обирали як найбільш привабливий на тесті, при A/B тестування відпрацював набагато гірше.

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

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

  • Важливі сценарії. Це ті користувальницькі сценарії (або завдання, або юзкейсы), які впливають на бізнес або пов'язані з метою тестування. Навіть якщо команда підозрює проблеми в конкретних місцях, часто варто перевірити основні кейси. При цьому важливими для тесту можуть вважатися наступні сценарії:

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

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

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

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

Метод збору даних


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

  • Спостереження. Під час виконання завдань респондент залишений наодинці з продуктом і веде себе так, як вважає за потрібне. Коментарі респондента збираються за допомогою опитувальників і спілкування з модератором після тесту. Це найбільш «чистий» метод, що забезпечує більш природне поведінка респондента і можливість коректно виміряти ряд показників (наприклад, час виконання завдання). Однак за кадром залишається багато корисних якісних даних. Бачачи те чи інше поведінку респондента, ви не можете зрозуміти, чому він так діє. Звичайно, можна запитати про це в кінці тесту, але, швидше за все, респондент буде добре пам'ятати тільки останнє завдання. Крім того, за час виконання завдань його думку про систему може змінюватися, і ви отримаєте тільки підсумкову картину, а не перші враження.

  • Think Aloud (Думки вголос). Довгий час цей метод використовувався в юзабіліті-тестування найчастіше. Якоб Нільсен у свій час називав його головним інструментом оцінки юзабіліті. Суть його в тому, що ви просите респондента озвучувати всі думки, які виникають у нього при роботі з інтерфейсом і коментувати всі свої дії. Це виглядає приблизно так: «Зараз я збираюся додати товар у кошик. А де ж кнопка? А, ось вона. Ой, я забув подивитися, який там був колір». Метод допомагає вам розуміти, чому користувач веде себе тим чи іншим чином, і які емоції викликає у нього поточний взаємодія. Він дешевий і простий, що з ним впорається навіть недосвідчений дослідник. Однак у нього є свої недоліки. По-перше, для людей не надто природно весь час «думати вголос». Вони будуть часто замовкати, і вам доведеться їм постійно нагадувати про те, що треба продовжувати говорити. По-друге, завдання при такому методі виконуються декілька довше, ніж у реальному житті. Крім того, частина респондентів починає більш вдумливо користуватися продуктом. Промовляючи причини своїх дій, вони намагаються діяти більш раціонально, та й просто не хочуть виглядати ідіотами. І ви можете не зловити якісь інтуїтивні моменти поведінки.

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

  • Retrospective think aloud (Ретроспектива). Це комбінація перших двох методів. Користувач виконує всі завдання без втручання, а потім перед нею відтворюється відеозапис його роботи, і він коментує свою поведінку і відповідає на питання модератора. Головний недолік методу — сильне збільшення часу тестування. Однак бувають випадки, коли він оптимальний. Наприклад, один раз перед нами постало завдання протестувати кілька видів мобів (ігрових монстрів) в одній RPG-грі. Природно, ми не могли не відволікати респондентів питаннями, ні змушувати їх коментувати свої дії під час бою. Це б унеможливило гру, де потрібна концентрація для перемоги. З іншого боку, згадати після серії сутичок, зауважив він загоревшуюся червоним сокиру у першій щури, користувач навряд чи зміг би. Тому в цьому тесті ми скористалися RTA. З кожним користувачем ми переглядали їхні бої і обговорювали, які ефекти монстрів вони помітили, як їх зрозуміли.
Вам вирішувати, який метод вам більше підійде. Однак моя порада: намагайтеся продумати, як ви можете отримати достатньо даних, зберігши максимальну природність поведінки респондента. Незважаючи на простоту й універсальність методу «думки вголос», який довгий час був найпопулярнішим в юзабіліті-тестування, ми намагаємося все частіше замінювати його на спостереження. Якщо модератор бачить цікаве поведінку респондента, що він почекає, поки той виконає завдання і задасть питання після. Відразу після завдання більше ймовірність, що респондент пам'ятає, чому він так зробив. Дуже допомагає в цьому питанні ай-трекер. Бачачи фокус поточного уваги респондента, ви можете, не задаючи зайвих питань, набагато краще зрозуміти його поведінку. Ай-трекер взагалі значно покращує якість модерування, і ця його роль, на мій погляд, не менш важлива, ніж можливість побудови хитмапов.

Метрики


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

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

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

    • впорався із завданням практично без проблем — 100%;
    • зіткнувся з проблемами, але виконав завдання самостійно — 50%;
    • не впорався із завданням — 0%.
    Тобто, якщо з 12 респондентів 4 впоралися із завданням легко, 6 з проблемами, а 2 зазнали фіаско, то середня успішність з цим завданням буде 58%. Іноді ви будете стикатися з ситуацією, коли в середню групу потрапляють дуже різні за ступенем «проблемності» респонденти. Наприклад, один респондент міг мучитися над кожним полем форми, а другий лише трохи помилитися в самому кінці. Ви можете давати оцінку на власний розсуд, в залежності від того, що сталося на тесті. Наприклад, 25%, якщо респондент тільки почав виконувати завдання або 80%, якщо припустився незначної помилки. Однак, щоб уникнути занадто великої суб'єктивності, продумайте шкали оцінок заздалегідь, а не вирішуйте для кожного респондента після тесту. Також вам варто подумати, що робити з помилками. Наприклад, ви дали завдання, купити квитки в кіно на проекті Кіно Mail.Ru. Один з респондентів випадково купив квиток не на завтра, а на сьогодні, і не помітив цього. Він упевнений, що впорався із завданням і справді має квиток на руках. Однак його помилка настільки критична, що призведе до того, що він не потрапить в кіно, тому я б поставила «0%», незважаючи на те, що квиток куплений. Відсоток успішності — це дуже проста і наочна метрика. І я рекомендую її використовувати, якщо у ваших завдань є чіткі цілі. Погляд на графік успішності за завданнями дозволяє швидко зрозуміти, де найбільш проблемні місця інтерфейсу.

  • Час виконання завдань. Ця метрика показова тільки в порівнянні. Як ви зрозумієте, добре чи погано те, що користувач виконує завдання за 30 секунд? А ось те, що час скоротилося в порівнянні з попередньою версією дизайну, вже добре. Або те, що реєстрація на нашому проекті займає менше часу, ніж у конкурентів. Є інтерфейси, де скорочення часу на виконання завдань критично. Наприклад, робочий інтерфейс співробітники колл-центру. Однак не для всіх задач ця метрика в принципі застосовна. Візьмемо, наприклад, задачу підбору товару в інтернет-магазині. Користувачі повинні швидко знаходити фільтри та інші елементи інтерфейсу, пов'язані з пошуком товарів, але сам процес вибору буде займати у них різний час. І це абсолютно нормально. Жінки при виборі туфель бувають готові подивитись 20 сторінок видачі. І це необов'язково означає, що на перших сторінках не було відповідних товарів або що вони не бачать фільтри. Часто їм просто хочеться побачити всі варіанти.

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

  • Суб'єктивна задоволеність. Це суб'єктивна оцінка користувачем зручності/комфорту роботи з системою. Виявляється вона за допомогою різних опитувальників, які респонденти заповнюють в процесі або після тестування. Є стандартні опитувальники. Наприклад, System Usability Scale (SUS), Post-Study Usability Questionnaire (PSSUQ) або Game Experience Questionnaire (GEQ) для ігор. Або ви можете скласти власний опитувальник. Докладніше про способи оцінки задоволеності у другій частині статті.
Це далеко не єдині можливі метрики. Ось, наприклад, список з 10 UX-метрик, які виділяє Джеф Сауро. Але для вашого продукту метрики можуть бути іншими. Наприклад, з якого рівня респонденти розбираються у правилах гри, скільки помилок припускаються при заповненні довгих форм та інше.

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

  • Єдині точки старту. Одні й ті ж завдання для різних респондентів повинні починатися з однієї і тієї ж точки інтерфейсу. Ви, наприклад, можете після кожного завдання просити респондентів повернутися на головну сторінку.

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

  • Порядок завдань. Щоб компенсувати вплив ефекту навчання в порівняльному тестуванні, обов'язково міняйте порядок знайомства з порівнюваними продуктами для різних респондентів. Нехай половина починає з вашого проекту, а половина — з конкурентного.

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

Джеф Сауро, експерт по статистиці у UX-дослідженнях, радить представляти метрики не середніми значеннями, а завжди вважати довірчі інтервали. Це набагато правильніше, особливо якщо в результатах респондентів присутній розкид. Для цього можна скористатися його безкоштовними онлайн-калькуляторами: успешностей і для часу виконання завдань. Також не обійтися без статистичної обробки і при порівнянні результатів.

Коли потрібні метрики
Далеко не кожен звіт про юзабіліті-тестування містить метрики. Їх збір і аналіз вимагає часу і накладає ряд обмежень на методи проведення тесту. У яких же випадках вони дійсно потрібні:

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

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

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

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

Спосіб фіксації даних


Здавалося б, чим поганий блокнотик і ручка або просто відкритий документ Word? У сучасному Agile світі розробки UX-дослідники повинні намагатися максимально швидко видавати команді результати своїх спостережень. Щоб оптимізувати час на аналіз, добре заздалегідь заготовити шаблон для введення ваших заміток в процесі тесту. Ми пробували робити це в спеціалізованому (наприклад, Noldus Observer або Morae Manager), але на практиці найбільш гнучкими і універсальними виявилися таблиці. Заздалегідь розмітьте в таблиці питання, які точно плануєте ставити, місця під enter проблем, виявлених у різних завданнях, а також гіпотези (ви будете позначати, підтвердилася вона чи ні на кожному респондента). Наші таблички виглядають таким чином:
Респондент 1 Респондент 2 Респондент 3 Респондент 4
Завдання 1
Помітив функцію А?
В якому місці шукав можливість Б?
Проблеми та спостереження за завданням
...
Ви також можете скористатися:

  • Usability Test Data Logger від Userfocus. Кастомизируемый шаблон Excel для введення спостережень по кожному респонденту. Є вбудований таймер для вимірювання часу виконання завдань і автоматично генеруються графіки часу і успішності.

  • Rainbow Spreadsheet від Томера Шерона з Google. Наочна таблиця для спільної роботи дослідника і команди. За посиланням стаття з описом методу, там же є посилання на Google-таблицю з шаблоном.
З досвідом більшість записів можна зробити прямо під час тесту. Якщо не встигли вчасно, краще записати все, що пам'ятаєте відразу після тесту. Бо якщо будете повертатися до аналізу через кілька днів, швидше за все, доведеться переглянути відео і витратити набагато більше часу.

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

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

  • Спосіб постановки завдань. Завдання може озвучувати модератор. Але в цьому випадку, незважаючи на єдиний протокол тестування, кожен раз текст завдання може вимовлятися трохи по-різному. Особливо це актуально, якщо тест веде кілька модераторів. Іноді, навіть невеликі відмінності у формулюваннях можуть поставити респондентів у різні початкові умови. Щоб уникнути цієї проблеми, можна або «надрессировать» модераторів завжди читати тексти завдання, або видавати завдання респондентам на листочках або на екрані. Відмінність формулювань не проблема для вас, якщо ви використовуєте гнучкий сценарій, при якому завдання формулюються в процесі тесту, на підставі інтерв'ю з модератором.

    Крім того, цікавим може бути варіант використання коштів продукту для постановки завдань. Так, наприклад, при тестуванні ICQ завдання респонденти отримували через вікно чату з модератором, а при тестуванні Пошти Mail.Ru вони приходили в листах. Такий спосіб постановки завдань був максимально природний для цих проектів, а ще ми багаторазово обкатували базові сценарії листування.

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

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

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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.