Тестування придатності має незаслужену репутацію дороговизни та повільності. Коли люди чують "дослідження користувачів", вони малюють односторонню дзеркало, модератора з папкою та двотижневий графік. Ця версія тестування існує та має свої методи — але це не версія, яка більшості команд продукту потребує більшість часу.
Версія, яка потребує більшості команд, простіша: п'ять користувачів, прототип Figma або середовище тестування, дзвінок за відео та 45 хвилин за сеанс. При правильному виконанні це вскриває більшість серйозних проблем придатності до відправлення. При послідовному виконанні — навіть раз на спринт — це виробляє складене покращення якості продукту, яке ніякі пост-запуск аналітики не можуть відтворити.
Ось як це запустити з нуля.
П'ять учасників — це правильне число для більшості тестів придатності. Дослідження Якоба Нільсена встановило, що п'ять користувачів виявляють близько 85% проблем з придатністю з зменшенням повернення після цього. Проведення трьох сеансів з п'яти користувачів у різних точках процесу дизайну є більш цінним, ніж один сеанс з п'ятнадцяти.
Критерії залучення мають більше значення, ніж число. Тест придатності з п'ятьма людьми, які тісно відповідають вашій цільовій персоні, виявить реальні проблеми. Тест з п'ятнадцяти людьми, які не відповідають, генеруватиме шум. Визначте два або три критерії скринінгу — роль, контекст використання, технічна комфортність — та дотримуйтеся їх.
Найшвидший маршрут залучення для більшості команд — надіслання електронною поштою існуючим користувачам, які дали дозвіл контакту. Пропонуйте скромний стимул — подарункова карта на 20 фунтів стерлінгів достатня для 45-хвилинного сеансу. Намагайтесь запланувати сеанси в межах того ж тижня; чим довша прогалина між залученням та тестуванням, тим вищий показник невиходу.
Найпоширеніша помилка написання сценарію — написання завдань як інструкцій: "Натисніть Параметри, потім перейдіть до Сповіщень та змініть ваше попереднє встановлення на..." Це говорить користувачу, що робити, що означає, що ви тестуєте, чи можуть вони слідувати вказівкам, а не чи інтерфейс інтуїтивний.
Замість цього напишіть завдання як сценарії: "Уявіть, що ви отримували занадто багато сповіщень і хочете отримувати сповіщення лише тоді, коли хтось прямо згадує вас. Покажи мені, що ти робиш би." Це дає користувачу реалістичну мету та дозволяє вам спостерігати, як вони насправді навігують — включаючи де вони збиваються.
Найважча частина модерування тесту придатності — це опір щодо допомоги. Коли користувач збивається, кожна інстинкт говорить стрибнути та показати їм де натиснути. Але збентеження — це дані. Користувач, який борється, говорить вам, що щось не так з інтерфейсом — та момент, коли ви втручаєтеся, ви втрачаєте сигнал.
Попросіть користувачів думати вголос протягом сеансу: "Коли ви йдете, просто скажіть мені, що ви дивитеся та що ви думаєте." Це виробляє безперервний потік даних про їхню психічну модель. Зауважте не просто помилки, але коливання — користувач, який пауза три секунди перед натисканням на правильну кнопку, все одно виявив проблему дизайну, навіть якщо вони врешті-решт досягли успіху.
Крок синтезу — це місце, де створюється більшість цінності — та де більшість команд скорочують кути. Сирі примітки з п'яти сеансів — це не висновки. Вони стають висновками, коли ви дебрифуєте як команду, групуєте спостереження за темою та призначаєте рейтинги серйозності.
Зробіть дебриф на тому ж дні, що й сеанси, поки спостереження свіжі. Групові питання в три відро: критичні (користувачі не могли завершити завдання), помірні (користувачі завершили завдання, але зі значною складністю чи помилкою) та незначні (тертя, яке не запобігло завершенню). Критичні питання повинні бути виправлені перед запуском. Помірні питання слід пріоритизувати в наступному спринті. Незначні питання йдуть до невідкладних.
Напишіть висновки на одній сторінці: три найвищі критичні питання, з доказами від щонайменше двох учасників кожен, та пропонований зміст дизайну для кожного. Все, що потребує більше місця, ніж це, належить окремому документу.