Аудит UX/UI мобільної програми
Приложення працює, але конверсія в реєстрацію падає, а користувачі скаржаться на «незручність» не конкретизуючи що саме. Саме для цього існує UX/UI аудит — щоб знайти точки розриву до того, як вони стали причиною відтоку.
Що перевіряємо та як
Аудит — не «подивитися й написати що не подобається». Це структурована перевірка по кількох незалежних осях.
Відповідність платформним гайдлайнам
iOS: Apple Human Interface Guidelines — перш за все перевіряємо розмір touch target (мінімум 44×44 pt), використання системних компонентів (Navigation Bar, Tab Bar, sheets), поведення при safe area (notch, Dynamic Island, home indicator). Поширена помилка — контент під UITabBar при швидкому скролі через неправильний contentInset або відсутність safeAreaLayoutGuide. Ще одна — кастомний Navigation Bar, що конфліктує з жестом назад (UIScreenEdgePanGestureRecognizer) та повертає на неправильний екран.
Android: Material Design 3 гайдлайни — elevation, ripple ефекти, WindowInsets для edge-to-edge режиму. Часто зустрічаю приложення, які не підтримують gestural navigation (Android 10+): контент приховується за навігаційну панель або системні жести конфліктують із горизонтальним свайпом у приложенні.
Продуктивність сприйняття
Час до першого значимого контенту (LCP на mobile web, або час до viewDidAppear зі змістовним контентом у нативці). Якщо splash screen займає більше 2 секунд — проблема. Якщо список завантажується без skeleton-стану та користувач бачить пустий екран — проблема.
Перевіряємо: чи є loading states для всіх асинхронних операцій, чи є empty states (що бачить користувач у пустому розділі), чи є error states з actionable текстом (не «Помилка 500», а «Не удалось завантажити. Перевіьте з'єднання» + кнопка «Повторити»).
Жест-конфлікти та scroll
Горизонтальний scroll всередину вертикального — UIScrollView всередину UITableView — одна з найчастіших причин скарг на «незручність». UIScrollView.panGestureRecognizer.require(toFail:) або правильна настройка UIScrollViewDelegate.scrollViewShouldScrollToTop розв'язують частину проблем, але не всі. Перевіряємо вручну на реальному пристрої: швидкий скролл, початок свайпа в різних точках, двійний тап.
Accessibility
accessibilityLabel на всіх інтерактивних елементах без тексту (іконки, кнопки з тільки зображенням). Контрастність тексту — WCAG 2.1 AA вимагає 4.5:1 для звичайного тексту, 3:1 для великого. Перевіряємо через Xcode Accessibility Inspector або Android Accessibility Scanner. Динамічний розмір шрифту (Dynamic Type / SP units) — приложення не повинно ломатися при максимальному UIContentSizeCategory.accessibilityExtraExtraExtraLarge.
Навігаційні паттерни
Глибина навігації: якщо для ключової дії потрібно 4+ екрану — проблема. Хлібні крошки або заголовок з контекстом («Налаштування → Сповіщення») де потрібні. Кнопка «Назад» — тільки там, де має сенс назад йти; bottom sheet та modal мають закриватися по тапу на backdrop.
Інструменти аудиту
- Xcode Accessibility Inspector — перевірка accessibility без включення VoiceOver
- Android Accessibility Scanner — автоматичний звіт по проблемам
- Figma — оверлей гайдлайнів поверх скриншотів, вимірювання
- Lookback / Maze — якщо потрібно користувацьке тестування з записом сесій
- Firebase Performance — реальні дані по часу завантаження екранів
- Crashlytics — кореляція крашей з конкретними UI-сценаріями
Результат аудиту
Структурований звіт з приоритизацією по impact/effort. Критичні (блокують ключові сценарії), високі (помітно погіршують досвід), середні (дрібні невідповідності гайдлайнам), низькі (косметика). Для кожної проблеми — скриншот, опис, посилання на гайдлайн та конкретна рекомендація. Не «зробіть кнопку більшою», а «збільшіть touch target кнопки «Скасувати» до 44pt; поточний розмір 28pt визначений через CGRect(origin:, size: CGSize(width: 28, height: 28)) у рядку 47 ViewController.swift».
Термін: 2–3 дні залежно від кількості екранів та платформ. Приложення з 20+ екранами на iOS та Android одночасно — 3 дні.