Аудит UX/UI сайту

Аудит UX/UI сайту

Аудит UX/UI — структурований аналіз інтерфейсу, що виявляє невідповідності між поточною поведінкою користувачів та проектними намірами. Результат — не список «що некрасиво», а конкретні проблеми з приоритетами та рекомендаціями по усуненню. Різниця між аудитом та редизайном в тому, що аудит відповідає на запитання «чому не працює», а не «як зробити красиво».

Що входить в аудит

Аудит покриває кілька шарів, які не можна змішувати:

Евристичний аналіз — перевірка інтерфейсу за набором принципів (10 евристик Nielsen, WCAG 2.1, guidelines платформи). Делається експертно без залучення користувачів. Виявляє структурні проблеми: непослідовна термінологія, відсутність зворотного зв'язку, порушення ієрархії.

Аналіз даних — робота з кількісними метриками: показники відмов по розділах, теплові карти (Hotjar, Microsoft Clarity), записи сесій, воронки конверсії в GA4. Дані показують де проблема, але не чому.

Технічний UX — швидкість завантаження (Core Web Vitals: LCP, CLS, INP), стабільність рендера, поведінка на різних пристроях та браузерах, коректність форм.

Accessibility — відповідність WCAG 2.1 рівням A та AA. Автоматичне сканування через axe-core, Lighthouse, WAVE; ручна перевірка keyboard navigation та screen reader (NVDA + Firefox, VoiceOver + Safari).

Процес аудиту за етапами

Етап 1: Збір контексту (1–2 дні)

До аналізу необхідно отримати:

• доступ до GA4 / аналітичної платформи за останні 3–6 місяців
• записи сесій (мінімум 50–100 по ключових сценаріях)
• дані Customer Support: топ звернень, пов'язаних з навігацією або функціональністю
• бізнес-цілі сторінок/розділів, які попадають в аудит
• конкурентний ландшафт (2–3 сайти, які використовуються як орієнтир)

Без цього аудит перетворюється на суб'єктивні зауваження.

Етап 2: Автоматизований технічний аналіз

# Lighthouse CI для кількох сторінок
npx lighthouse-ci autorun --collect.url="https://example.com" \
  --collect.url="https://example.com/catalog" \
  --collect.numberOfRuns=3

# axe-core через CLI
npx axe https://example.com --save axe-results.json

Інструменти:

• Lighthouse — Core Web Vitals, accessibility score, best practices
• axe DevTools / axe-core — WCAG-порушення з точними селекторами елементів
• WebPageTest — waterfall-аналіз завантаження, filmstrip рендера
• Chrome DevTools Coverage — невикористаний CSS/JS

Етап 3: Експертний аналіз

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

1. перший візит → пошук товару → додавання в корзину → оформлення
2. повернення користувача → улюблене → повторне замовлення
3. мобільний сценарій (тач-навігація, розмір цілей касання)

Кожна проблема документується за шаблоном:

Етап 4: Аналіз теплових карт та записів сесій

При переглядi записів сесій ищемо паттерни:

• rage clicks — повторні клики по нереагуючому елементу
• u-turn — користувач заходить на сторінку та відразу назад
• dead scrolling — прокрутка без взаємодії через весь екран
• form abandonment — на якому полі уходять з форми

У Hotjar це настроюється через фільтри: rage_clicks > 2 або exit_page = /checkout.

Етап 5: Формування звіту

Структура звіту:

1. Executive summary — 3–5 критичних проблем з найбільшим впливом
2. Детальний список проблем, згрупованих за severity та розділах
3. Матриця приоритетів: Impact × Effort
4. Конкретні рекомендації з візуальними прикладами (скриншоти + аннотації, не макети)
5. Метрики для верифікації після внедрення

Типичні знахідки

На більшості сайтів аудит виявляє передбачувані класи проблем:

Навігація та орієнтація

• відсутність breadcrumbs на глибоких сторінках
• нема індикації поточного розділу в меню
• пошук спрятаний або повертає нерелевантні результати

Форми

• валідація тільки при submit (замість inline по blur)
• нечитабельні повідомлення про помилки («Поле обов'язково» замість «Укажіть email в форматі [email protected]»)
• автозаповнення (autocomplete атрибут) не настроєно

Мобільна версія

• tap targets менше за 44×44px (Apple HIG) / 48×48dp (Material)
• горизонтальний скролл з-за фіксованих ширин
• модальні вікна не адаптовані для віртуальної клавіатури

Продуктивність сприйняття

• відсутність skeleton loaders при асинхронній завантаженні
• нема optimistic UI при відправці форм
• CLS через зображення без width/height або aspect-ratio

Deliverables аудиту

• PDF/Notion-звіт з аннотованими скриншотами
• Таблиця завдань в Jira/Linear з готовими описаннями та приоритетами
• Опціонально: відео-огляд критичних проблем (10–15 хвилин, для команди)

Строк реалізації

Аудит лендинга або сайту-візитки (5–10 сторінок) — 3–4 дня. Корпоративний сайт або інтернет-магазин (20–50 шаблонів сторінок) — 7–12 робочих днів. Якщо в обсяг входить користувацьке тестування з живими учасниками — окрема оцінка +5 днів.