Юзабіліті-тестування: як перевіряють зручність інтерфейсу на реальних користувачах
Автор: Український психологічний ХАБ · Опубліковано: 7 жовтня 2026 року · Редакційна політика
Юзабіліті-тестування — це емпіричне оцінювання інтерфейсу, під час якого представники цільових користувачів виконують реалістичні завдання, а дослідник спостерігає, чи досягають вони мети, де помиляються, що їх уповільнює, які підказки їм потрібні та як вони оцінюють взаємодію. ISO 9241-220:2019 визначає user-based evaluation як оцінювання за участю репрезентативних користувачів, які виконують завдання з системою для виявлення проблем людиноцентричної якості та/або вимірювання результативності, ефективності, задоволення чи інших аспектів користувацького досвіду.
Ключова особливість методу полягає в тому, що дослідник перевіряє не думку про макет у відриві від діяльності, а реальну взаємодію людини із системою. Людина намагається знайти інформацію, оформити замовлення, змінити налаштування, записатися на послугу, завершити робочий сценарій або виконати іншу значущу дію. Саме в цей момент стає видно розрив між задумом команди й тим, як інтерфейс насправді читається, розуміється та використовується.
Коротко: що перевіряє юзабіліті-тестування
Юзабіліті не є абсолютною властивістю екрана. За ISO 9241-11:2018 вона описує, наскільки визначені користувачі можуть досягати визначених цілей із результативністю, ефективністю та задоволенням у визначеному контексті використання. Тому тест має сенс лише тоді, коли відомо, хто користувачі, які їхні цілі й завдання, у яких умовах вони працюють і що в цьому контексті означає успішне виконання.
На практиці юзабіліті-тестування відповідає щонайменше на чотири групи запитань. Чи може людина завершити завдання? Скільки зусиль, часу, дій і виправлень для цього потрібно? Де саме виникають помилки, зупинки, хибні очікування або звернення по допомогу? Як користувач сприймає легкість, зрозумілість і контроль під час взаємодії? Поєднання поведінкових спостережень і суб’єктивних оцінок дає значно точнішу картину, ніж одне запитання «вам було зручно?».
Юзабіліті-тестування в системі UX і HCI
Юзабіліті-тестування є одним із методів оцінювання в ширшій дисципліні взаємодії людини з комп’ютером і людиноцентрованого проєктування. ISO 9241-210:2019 розглядає людиноцентрований дизайн як сукупність принципів і діяльності протягом життєвого циклу інтерактивної системи. Тестування входить у цей цикл як спосіб перевірити рішення на людях і повернути результати в наступну ітерацію проєктування.
Метод не охоплює весь користувацький досвід. UX може включати очікування до використання, емоційне ставлення, довіру, цінність, бренд, довгострокові наслідки та соціальний контекст. Юзабіліті-тестування фокусується передусім на тому, що відбувається під час виконання конкретних завдань і наскільки система підтримує досягнення мети. Воно може збирати дані про досвід, але не перетворює будь-яке інтерв’ю чи опитування на юзабіліті-тест.
Чим юзабіліті-тестування відрізняється від інших методів
Від експертного оцінювання
Під час евристичного оцінювання фахівці самі аналізують інтерфейс за принципами й критеріями. Під час юзабіліті-тестування взаємодіють цільові або близькі до цільових користувачі. Експерт може передбачити проблему, але тест показує, чи виникає вона в реальному сценарії, як саме проявляється і які наслідки має для виконання завдання. Обидва методи доповнюють один одного й відповідають на різні запитання.
Від інтерв’ю та опитувань
Інтерв’ю добре виявляє досвід, мотивацію, очікування та пояснення людини. Опитування дає стандартизовані самооцінки. Юзабіліті-тест додає поведінковий рівень: дослідник бачить, що учасник робить, а не лише що він пригадує або повідомляє. Різниця особливо важлива там, де користувач упевнено каже, що «все зрозуміло», але під час завдання систематично шукає потрібну функцію не там.
Від аналітики та A/B-тестування
Вебаналітика може показати, де люди залишають сторінку, скільки часу проводять на кроці або яка частка завершує воронку. A/B-тестування може порівняти варіанти за заздалегідь визначеним показником на достатньому трафіку. Юзабіліті-тестування пояснює механіку труднощів у конкретних завданнях: що людина очікувала побачити, що не помітила, як інтерпретувала напис і чому обрала хибний шлях. Воно особливо цінне до масштабного запуску, коли великих масивів поведінкових даних ще немає.
Від перевірки доступності
Відповідність вимогам доступності та тестування з людьми з інвалідністю мають перетин, але не замінюють одне одного. W3C WAI рекомендує поєднувати оцінювання відповідності стандартам із залученням реальних користувачів з різними інвалідностями й допоміжними технологіями. Окремий користувач не може підтвердити доступність для всіх груп, так само як автоматична перевірка не покаже всі проблеми реальної взаємодії.
Коли проводять юзабіліті-тестування
Тестувати можна на різних стадіях: від паперового або клікабельного прототипу до готового сервісу. Ранній тест дешевше виявляє проблеми структури, термінології, навігації та послідовності дій до того, як команда реалізує їх у коді. Тест робочого продукту дає змогу перевіряти повний сценарій, реальні затримки, помилки системи, інтеграції та поведінку в справжньому середовищі.
Для формувального тестування головна мета — знайти проблеми й зрозуміти, що потрібно змінити. Для підсумкового або порівняльного оцінювання головна мета — отримати показники, які можна зіставляти між версіями, продуктами чи моментами часу. GOV.UK Service Manual для юзабіліті-бенчмаркінгу радить обирати стабільні, поширені й однозначно оцінювані завдання та працювати з більшими вибірками, ніж у невеликому діагностичному тесті.
Модероване і немодероване тестування
У модерованому тесті фасилітатор присутній під час сесії, ставить нейтральні уточнювальні запитання, стежить за перебігом завдання й може попросити учасника пояснити незрозумілу реакцію. Такий формат особливо корисний для складних сценаріїв, ранніх прототипів, чутливих тем і ситуацій, де важливо зрозуміти причини поведінки. GOV.UK описує модероване тестування як спостереження за тим, як учасники намагаються виконати конкретні завдання, із чіткими й нейтральними інструкціями.
У немодерованому тесті учасник виконує завдання самостійно за інструкцією, а система збирає записи екрана, кліки, відповіді та інші дані. Формат легше масштабувати й використовувати дистанційно, однак дослідник не може в реальному часі уточнити, чому людина зупинилася або що саме вона мала на увазі. Вибір формату визначається дослідницьким питанням, зрілістю продукту, ризиком завдання та потрібною глибиною пояснення.
Як провести юзабіліті-тестування: повний процес
1. Сформулювати рішення, яке має підтримати дослідження
Починати варто не зі списку екранів, а з рішення. Наприклад: чи готовий новий процес реєстрації до запуску; який крок оформлення найбільше заважає завершенню; чи зрозуміють нові користувачі, як змінити налаштування приватності; чи зможуть оператори безпомилково відреагувати на критичний сигнал. Хороше дослідницьке питання визначає учасників, завдання, метрики й спосіб аналізу.
2. Описати користувачів і контекст використання
Потрібно визначити характеристики людей, від яких реально залежить взаємодія: досвід із подібними системами, роль, частоту користування, доменні знання, тип пристрою, мовний контекст, умови роботи, а за потреби — використання допоміжних технологій. Демографічні ознаки включають лише тоді, коли вони справді пов’язані з дослідницьким питанням. Репрезентативність у юзабіліті-тесті означає відповідність важливим характеристикам цільового користувача, а не формальну копію населення країни.
3. Визначити об’єкт і рівень готовності
Тестувати можна окрему функцію, критичний шлях, прототип, мобільний застосунок, сайт, робоче місце оператора або повну людино-технічну систему. Дослідник має чітко зафіксувати, що в цьому раунді доступне учасникові, які частини змодельовані, що працює умовно й де результат може залежати від недосконалості прототипу, а не від самої концепції інтерфейсу.
4. Добрати учасників
Учасники мають відповідати тим сегментам, для яких робиться висновок. Якщо продуктом користуються новачки й експерти, а їхня поведінка принципово відрізняється, одну змішану групу не слід трактувати як єдину однорідну вибірку. Для професійної системи випадкові люди з вулиці можуть демонструвати проблеми, яких не матиме навчений оператор, а надто досвідчені користувачі можуть обходити бар’єри, що критичні для новачків.
5. Створити реалістичні сценарії та завдання
Завдання мають описувати мету користувача, а не шлях, який задумав дизайнер. Формулювання «знайдіть кнопку “Експорт” і натисніть її» підказує рішення. Нейтральніший сценарій звучить так: «Ви завершили звіт і хочете надіслати його колезі у форматі PDF. Зробіть це так, як зробили б зазвичай». GOV.UK рекомендує, щоб завдання мали чітку мету, були правдоподібними й релевантними та не видавали учасникові відповідь.
6. Заздалегідь визначити критерії успіху і дані
До сесій потрібно зафіксувати, що вважатиметься успішним завершенням, частковим успіхом і невдачею; коли запускається й зупиняється вимірювання часу; що вважати помилкою або зверненням по допомогу; які суб’єктивні оцінки збираються після завдання. Це зменшує спокусу змінювати правила після того, як команда вже побачила результати.
7. Провести пілотну сесію
Пілот потрібен для перевірки самої процедури: чи зрозумілі інструкції, чи працює прототип, чи вистачає часу, чи завдання не містить прихованих підказок, чи записує система потрібні дані. Невдале формулювання сценарію може створити штучну проблему, яка буде помилково приписана інтерфейсу.
8. Отримати поінформовану згоду і захистити дані
Якщо сесія записується або збираються персональні дані, учасник має розуміти мету дослідження, що саме фіксується, хто матиме доступ до матеріалів, як вони використовуватимуться і чи може людина відмовитися від участі або окремих видів запису. GOV.UK Service Manual прямо вимагає поінформованої згоди до нотування й запису сесій та безпечного поводження з дослідницькими даними. Для юридично регульованих або чутливих досліджень потрібні правила конкретної організації та юрисдикції.
9. Провести сесію без навчання користувача
На початку учаснику пояснюють, що оцінюють систему, а не його здібності. Фасилітатор дає сценарій і спостерігає. Якщо людина запитує «а куди натискати?», автоматична підказка зруйнує саме спостереження, заради якого проводиться тест. Допомога допустима за заздалегідь визначеним правилом — наприклад, коли без неї сесія не може продовжитися, — але факт і момент допомоги потрібно зафіксувати.
10. Розділяти спостереження й інтерпретацію
Запис «учасник тричі відкрив меню профілю, потім повернувся на головний екран і попросив допомоги» є спостереженням. Запис «учасник не зрозумів інформаційну архітектуру» вже є інтерпретацією. Якісний аналіз зберігає цей розрив: команда спочатку фіксує поведінкові факти, потім перевіряє пояснення за словами учасника, повторюваністю між сесіями та іншими даними.
11. Синтезувати проблеми, причини й наслідки
Окремі нотатки об’єднують за завданнями й типами проблем. Корисний результат описує щонайменше контекст, спостережувану поведінку, інтерфейсний тригер, наслідок для мети користувача, частоту в межах вибірки та рівень упевненості в поясненні. Якщо учасник не побачив кнопку, це ще не доводить, що проблема викликана саме кольором: причиною може бути розташування, назва, очікувана структура, попередній крок або навантаження завдання.
12. Внести зміни і перевірити повторно
Юзабіліті-тестування найсильніше працює як цикл. Команда змінює інтерфейс, потім перевіряє нове рішення на наступній групі або в наступній ітерації. Зникнення одного симптома не гарантує, що система стала кращою: виправлення може створити іншу проблему, перенести складність на сусідній крок або поліпшити один сегмент користувачів за рахунок іншого.
Як створювати хороші завдання для тесту
Тестове завдання повинно мати однозначну користувацьку мету й водночас залишати спосіб її досягнення відкритим. Воно має бути достатньо конкретним, щоб дослідник міг визначити успіх, і достатньо природним, щоб учасник діяв так, як у реальному житті. Не варто вставляти в текст назви елементів інтерфейсу, які потрібно знайти, або повторювати точні слова з кнопок і меню.
Для порівняльних вимірювань важливо, щоб завдання були стабільними між хвилями тестування. GOV.UK guidance on usability benchmarking рекомендує обирати поширені сценарії з чітким правильним результатом, які залишатимуться релевантними в часі. Це дозволяє відрізнити реальну зміну юзабіліті від зміни самого завдання.
Що спостерігати під час сесії
Основні дані — не лише кліки. Дослідник фіксує, чи розпізнав учасник початок потрібного шляху; де зупинився; які альтернативи розглядав; що читав або пропускав; чи повертався назад; чи повторював одну дію; які помилки робив; чи помічав повідомлення про стан системи; чи міг відновитися після помилки; коли звертався по допомогу; як завершив завдання.
Важливі й невидимі на перший погляд сигнали: довга пауза перед вибором, перечитування одного напису, рух курсора між двома елементами, відкриття нового вікна через невпевненість, перевірка результату кількома способами. Такі події не завжди є проблемою самі по собі, але допомагають знайти місце, де інтерфейс вимагає більше пошуку, пам’яті або перевірки, ніж передбачала команда.
Основні показники юзабіліті
Успішність виконання завдання
Частка успішних завершень показує результативність: чи досяг користувач визначеної мети. Для складних сценаріїв іноді потрібні категорії повного й часткового успіху, але їх слід визначити до аналізу. У невеликій якісній вибірці відсоток не треба подавати як точну оцінку для всієї популяції: один учасник може змінити показник на десятки процентних пунктів.
Час виконання
Час на завдання корисний тоді, коли швидкість справді має значення і умови виконання достатньо зіставні. Повільніше не завжди означає гірше: у фінансовій, медичній або іншій відповідальній дії додаткова перевірка може бути бажаною. Тому час інтерпретують разом з успішністю, помилками, складністю сценарію та ціною наслідків.
Помилки, відхилення і допомога
Кількість помилок може бути інформативною лише за чіткого визначення, що саме вважається помилкою. Дослідник може окремо фіксувати неправильну дію, пропуск необхідного кроку, вибір хибної команди, повторне виконання, повернення, звернення по допомогу й неможливість завершити сценарій. У safety-critical системах особливо важливий не лише рахунок, а характер помилки та потенційні наслідки.
Суб’єктивна легкість і задоволення
Після завдання можна просити учасника оцінити легкість або впевненість, а після взаємодії з системою — загальне сприйняття юзабіліті. System Usability Scale (SUS), запропонована Brooke (1996), є коротким 10-пунктовим інструментом глобальної суб’єктивної оцінки. Її результат не слід трактувати як відсоток «реальної зручності».
Поведінкові й суб’єктивні показники не дублюють один одного. У дослідженні Peres, Pham і Phillips (2013) зв’язок між SUS і традиційними результатами юзабіліті був статистично значущим, але невеликим. Це підтримує використання стандартизованої самооцінки як окремого джерела даних, а не як заміни спостереження за виконанням завдань.
Скільки учасників потрібно
Універсального числа немає. Поширена формула «п’яти користувачів достатньо» може бути практичною відправною точкою для коротких ітеративних якісних раундів, однак не є загальним статистичним законом. Faulkner (2003) на даних 60 користувачів показала значну мінливість малих підвибірок: групи з п’яти учасників знаходили дуже різну частку проблем.
Критика «магічних чисел» у Schmettow (2012) підкреслює, що ймовірність виявлення проблем неоднорідна, а потрібна вибірка залежить від мети й вимог до повноти. Якщо завдання — швидко знайти грубі проблеми й повторювати тест після виправлень, невеликі хвилі можуть бути ефективними. Якщо потрібно оцінити частоту успіху, порівняти системи, встановити нормативний поріг або підтвердити безпечність, потрібен інший, зазвичай значно більший дизайн.
Для кількісного бенчмаркінгу GOV.UK як практичний орієнтир радить набирати 30–60 актуальних або ймовірних користувачів сервісу. Це не універсальна норма для кожного дослідження, а приклад того, як змінюється масштаб вибірки, коли мета переходить від пошуку проблем до стабільнішого вимірювання показників.
Метод «думати вголос»: корисний, але не нейтральний
Під час протоколу «думати вголос» учасника просять озвучувати те, що він помічає, очікує або намагається зробити. Це допомагає досліднику пов’язати дію з поточним розумінням інтерфейсу. Водночас вербалізація сама стає частиною ситуації тестування й може впливати на поведінку.
Метааналітичний огляд Hertzum (2024) порівняв 29 досліджень і 42 зіставлення одночасного та ретроспективного проговорювання. Одночасне проговорювання було пов’язане з довшим часом виконання завдань, тоді як ретроспективне давало більше пояснень, формулювань проблем і дизайнерських пропозицій. Отже, результати метрик часу та зміст словесних даних потрібно інтерпретувати з урахуванням обраного протоколу.
Як аналізувати результати без надмірних висновків
Юзабіліті-тестування добре показує існування й механіку проблеми в досліджених сценаріях. Воно значно слабше підтримує заяви на кшталт «73% усіх користувачів матимуть цю проблему», якщо вибірка мала й не була спроєктована для кількісного оцінювання. Частота проблеми серед шести людей — це частота в конкретному тесті, а не автоматично оцінка для всієї популяції.
Для показників завершення завдань, які є пропорціями, невеликі вибірки мають широку статистичну невизначеність. Sauro і Lewis (2005) показали, що звичні наближення довірчих інтервалів можуть бути особливо неточними на малих вибірках. Якщо команда збирається приймати рішення за різницею у відсотках, дослідження потрібно планувати як кількісне, а не просто додавати проценти до якісного тесту.
Корисно розрізняти факт, гіпотезу й рекомендацію. Факт: три учасники не помітили повідомлення після натискання. Гіпотеза: повідомлення недостатньо помітне в контексті завершення дії. Рекомендація: змінити спосіб зворотного зв’язку і протестувати новий варіант. Така структура робить звіт перевірюваним і не маскує дизайнерське припущення під емпіричний результат.
Як визначати пріоритет проблем
Пріоритет не варто виводити лише з того, скільки учасників зіткнулися з проблемою. Важливі частота в межах тесту, тяжкість наслідку, критичність завдання, можливість відновлення, помітність проблеми для самого користувача й потенційний масштаб у реальному використанні. Рідкісна помилка в оплаті, медичному пристрої чи системі керування може бути важливішою за частий косметичний дискомфорт.
У звіті корисно окремо позначати доказову основу кожного висновку: повторюване спостереження, одиничний випадок із високою ціною наслідків, коментар учасника, аналітичну гіпотезу команди або зовнішню вимогу стандарту. Це зменшує ризик, що яскрава цитата одного учасника отримає більшу вагу лише тому, що добре запам’яталася.
Доступність і різноманіття користувачів
Якщо продукт має бути доступним для людей з інвалідністю, їх необхідно включати в дослідження відповідно до цільової аудиторії й реальних способів взаємодії. W3C WAI наголошує на різноманітті досвіду, допоміжних технологій і стратегій використання. Один незрячий користувач, один користувач клавіатури чи одна людина з когнітивною інвалідністю не представляє автоматично всіх людей із подібною категорією потреб.
Тестування з користувачами також не скасовує перевірку відповідності WCAG або іншим стандартам доступності. Найсильніша схема поєднує технічну перевірку, експертне оцінювання й реальне використання різними людьми. Так команда бачить і формальну відповідність, і практичні бар’єри, які проявляються лише в конкретному контексті.
Юзабіліті-тестування в системах, де помилка може завдати шкоди
У медичних пристроях, транспорті, промисловому керуванні та інших системах із високою ціною помилки юзабіліті пов’язане з безпекою. Тут недостатньо запитати, чи було «зручно». Потрібно аналізувати критичні завдання, можливі use errors, умови середовища, відновлення після помилки й те, як інтерфейс підтримує або підриває безпечну дію.
Актуальне керівництво FDA з human factors та usability engineering для медичних пристроїв (2026) орієнтує виробників на зменшення помилок використання й пов’язаної з ними шкоди через системний процес людських факторів. IEC 62366-1:2015+A1:2020 встановлює процес аналізу, розроблення й оцінювання юзабіліті медичного пристрою в аспектах безпеки.
У таких системах формула «користувач помилився» є початком аналізу, а не його завершенням. Потрібно перевіряти, які властивості інтерфейсу, сигналів, процедур, автоматизації, навчання й середовища зробили хибну дію ймовірною або ускладнили своєчасне відновлення. Висновки з малих формувальних тестів не можна автоматично переносити на нормативне підтвердження безпечності.
Типові помилки під час юзабіліті-тестування
Перша помилка — тестувати не тих людей. Якщо критерії рекрутингу не відповідають реальній аудиторії, команда може оптимізувати інтерфейс під поведінку, якої в реальному продукті майже не буде.
Друга — підказувати шлях. Фасилітатор, який пояснює назви елементів, завершує фрази учасника або показує, куди натиснути, перетворює тест на навчання. Після цього неможливо сказати, чи впорався користувач сам.
Третя — ставити навідні запитання. «Вам сподобалася ця нова зручна панель?» створює очікувану відповідь. Нейтральніше запитати: «Що ви очікували побачити після цієї дії?» або «Розкажіть, що ви зараз намагаєтеся зробити».
Четверта — змішувати баги й проблеми юзабіліті. Технічний збій може заблокувати сценарій, але це інший клас проблеми, ніж незрозуміла назва чи слабкий зворотний зв’язок. У звіті варто розділяти дефекти реалізації, проблеми взаємодії та обмеження прототипу.
П’ята — перетворювати малу якісну вибірку на псевдостатистику. Формулювання «80% користувачів не розуміють меню» на основі чотирьох із п’яти учасників звучить точніше, ніж дозволяють дані. Коректніше описати спостереження в цій вибірці й, якщо потрібна популяційна оцінка, провести кількісне дослідження.
Шоста — збирати багато думок і мало поведінки. Людині легше сказати, що їй подобається колір, ніж пояснити, чому вона не змогла завершити завдання. Юзабіліті-тест має залишатися тестом взаємодії, а не фокус-групою про дизайн.
Сьома — завершити роботу списком проблем без повторної перевірки. Рекомендації є гіпотезами про поліпшення. Їхня якість підтверджується наступною ітерацією, а не впевненістю автора звіту.
Приклад короткого плану тестування
Уявімо сервіс, у якому людина хоче змінити адресу доставки. Дослідницьке питання: чи зможе чинний користувач самостійно знайти потрібне налаштування, змінити адресу й зрозуміти, до яких замовлень застосовано зміну. Учасники: люди, які вже користувалися сервісом і мають досвід онлайн-замовлень. Середовище: власний смартфон або стандартизований тестовий пристрій — залежно від мети.
Сценарій може звучати так: «Ви переїхали й хочете, щоб наступні замовлення надсилалися на нову адресу. Змініть адресу доставки й переконайтеся, що все налаштовано так, як вам потрібно». Дослідник заздалегідь визначає, що є успіхом, фіксує шлях, паузи, помилки, допомогу, час, а після завершення просить оцінити легкість завдання та пояснити найскладніший момент.
Після серії сесій команда не просто рахує, скільки людей завершили сценарій. Вона перевіряє, чи повторюється одна й та сама точка тертя, чи пов’язана вона з терміном «адреса доставки», розташуванням налаштування, неочевидним збереженням або незрозумілим повідомленням про застосування змін. Потім формулює гіпотезу виправлення й тестує її повторно.
Що має бути у звіті
Добрий звіт дозволяє іншій людині зрозуміти, що саме було перевірено й наскільки далеко можна поширювати висновки. Він містить дослідницькі питання, характеристики учасників, контекст і пристрої, версію продукту або прототипу, завдання, процедуру, правила допомоги, зібрані показники, основні спостереження, проблеми з доказами, обмеження та рекомендації для наступної ітерації.
Для кожної проблеми варто показати не лише скриншот і цитату, а зв’язок із завданням та наслідком: де виникла проблема, що зробив учасник, чи зміг відновитися, як це вплинуло на мету й чому команда вважає запропоновану зміну перспективною. Якщо пояснення є гіпотезою, його так і позначають.
Що юзабіліті-тестування може довести, а чого не може
Метод переконливо показує, що конкретні люди в конкретних умовах зіткнулися з конкретною проблемою, і допомагає розібрати механізм цієї проблеми. За відповідного дизайну він також може вимірювати результативність, ефективність і суб’єктивні оцінки. Сила висновку завжди залежить від вибірки, завдань, умов, якості вимірювання та того, наскільки вони відповідають реальному контексту використання.
Юзабіліті-тест не доводить, що один учасник представляє всю аудиторію; не перетворює суб’єктивну оцінку на поведінковий факт; не встановлює причинність лише тому, що фасилітатор почув переконливе пояснення; не гарантує доступність для всіх людей; не замінює статистично спроєктоване порівняння, якщо рішення залежить від малих відмінностей у показниках; і не є сам по собі сертифікацією безпеки.
FAQ
Чи достатньо п’яти користувачів для юзабіліті-тесту?
Для невеликої формувальної ітерації п’ять учасників можуть дати корисні проблеми, особливо якщо сегмент однорідний і команда швидко тестує наступну версію. Це не універсальна достатня вибірка. Для рідкісних проблем, кількох сегментів, кількісних оцінок, порівнянь або високоризикових систем потрібен інший розрахунок і часто значно більше учасників.
Чи можна тестувати прототип, а не готовий продукт?
Так. Прототипи дозволяють рано перевіряти структуру, послідовність дій, терміни, навігацію й очікування користувача. У звіті потрібно чітко відокремити проблеми концепції від обмежень самого прототипу.
Що краще: модероване чи немодероване тестування?
Формат визначається питанням. Модероване тестування дає глибші пояснення й контроль складних сесій. Немодероване легше масштабувати й стандартизувати. Для чутливих або критичних сценаріїв можливість спостерігати й уточнювати часто важливіша за масштаб.
Чи потрібно просити учасників думати вголос?
Не завжди. Протокол корисний для розуміння поточного міркування, але може впливати на час і характер виконання. Якщо час є головною метрикою, вплив вербалізації потрібно враховувати або використовувати інший протокол.
Чи можна залучити колег замість користувачів?
Колеги можуть бути корисні для пілоту й перевірки процедури. Вони стають повноцінними учасниками лише тоді, коли справді відповідають цільовому профілю й не мають знань про продукт, які роблять їхню поведінку нетиповою.
Чи достатньо одного показника, наприклад SUS?
Ні. SUS описує глобальне суб’єктивне сприйняття системи. Для юзабіліті потрібні також дані про виконання завдань: успіх, помилки, допомогу, час або інші релевантні показники. Суб’єктивна легкість і фактична поведінка можуть розходитися.
Чи замінює юзабіліті-тест перевірку доступності?
Ні. Тестування з людьми з інвалідністю показує реальні бар’єри, а перевірка відповідності стандартам оцінює ширший набір вимог. Ці підходи потрібно поєднувати.
Коли тестування потрібно повторювати?
Після суттєвих змін, появи нового критичного сценарію, зміни цільової аудиторії або контексту, а також тоді, коли аналітика чи звернення користувачів вказують на нові труднощі. Для ключових сервісів юзабіліті є регулярною частиною циклу вдосконалення, а не одноразовою перевіркою перед запуском.