Аудит UX/UI мобильного приложения
Приложение работает, но конверсия в регистрацию падает, а пользователи жалуются на «неудобство» не конкретизируя что именно. Именно для этого существует UX/UI аудит — чтобы найти точки разрыва до того, как они стали причиной оттока.
Что проверяем и как
Аудит — не «посмотреть и написать что не нравится». Это структурированная проверка по нескольким независимым осям.
Соответствие платформенным гайдлайнам
iOS: Apple Human Interface Guidelines — в первую очередь проверяем touch target size (минимум 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 дня.