Як провести юзабіліті-аудит та визначити проблеми сайту

Звідки взялася рекомендація про п'ять учасників

У 2012 році Якоб Нільсен опублікував у Nielsen Norman Group матеріал How Many Test Users in a Usability Study?.

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

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

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

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

Крім того, коли продукт має принципово різні аудиторії, тестувати лише одну групу недостатньо.

Чого не можна довести п'ятьма тестами

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

Це корисний сигнал: із фільтром, імовірно, є проблема, яку варто дослідити й виправити.

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

Саме тому юзабіліті-тестування не варто плутати зі звичайним опитуванням про вподобання.

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

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

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

Чому автоматичний аудит не замінить людей

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

У Web Almanac 2025 дослідники використовували Lighthouse та axe-core для аналізу доступності мільйонів вебсторінок. Автори окремо наголошують: автоматичні перевірки охоплюють лише частину критеріїв доступності.

Тому хороший результат у Lighthouse ще не доводить, що всім людям буде зручно користуватися сайтом.

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

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

Не менш важливий контент для сайту. Заміна розмитого напису «Далі» на «Перейти до оплати» іноді допомагає більше, ніж зміна кольору кнопки.

Де проходить межа між зручністю та доступністю

У жовтні 2023 року W3C опублікував WCAG 2.2 — оновлені рекомендації з вебдоступності.

Версія додала дев'ять нових критеріїв, зокрема щодо видимості фокуса, розміру інтерактивних елементів і доступності допомоги.

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

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

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

Яким має бути результат юзабіліті-аудиту

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

Із таких формулювань незрозуміло, що саме потрібно виправити.

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

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

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

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

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