UX-аудит за один день: чеклист, который находит критические проблемы до пользователей

Большинство UX-проблем не нужно искать с помощью дорогих исследований и многонедельных тестов. Они видны невооружённым взглядом — если знать куда смотреть.

UX-аудит за один день — это не компромисс. Это конкретная техника: структурированный осмотр продукта по проверенным критериям, который выявляет 80% критических проблем без рекрутинга пользователей.

Оставшиеся 20% — нюансы, контекстные проблемы, неожиданные сценарии — да, нужны настоящие тесты. Но аудит за день даёт достаточно чтобы расставить приоритеты, обосновать редизайн и не тратить бюджет на исследование того, что итак очевидно.

## Подготовка: 30 минут до начала аудита

Аудит без подготовки — это просто прогулка по интерфейсу с ощущением «что-то не так». Подготовка превращает его в диагностику.

### Определи scope

Что именно проверяешь? Весь продукт сразу — плохая идея. За один день реально качественно проверить:

• Один ключевой флоу (онбординг, checkout, активация)
• Один раздел продукта
• Конкретный сценарий пользователя от начала до конца

Если продукт большой — выбери флоу с наибольшими потерями по данным аналитики. Нет данных — начни с онбординга. Там всегда что-то есть.

### Собери контекст

Прежде чем открывать интерфейс, зафиксируй:

• Кто основные пользователи (опытные / новички, возраст, устройства)
• Какая главная задача пользователя в этом флоу
• Какие данные о проблемах уже есть (жалобы в поддержку, drop-off в аналитике)

Это защищает от «аудита для дизайнера» — когда находишь проблемы, которые раздражают тебя, а не те, что мешают пользователю.

### Подготовь инструменты

Минимальный набор:

• Устройства: компьютер + смартфон (если мобайл важен)
• Способ фиксации: Notion, FigJam, или просто Google Doc
• Скриншоты: любой инструмент захвата экрана с аннотациями

Оптимальный набор: добавь тестовый аккаунт новичка (не залогиненный заранее) чтобы проходить флоу как первый пользователь.

## Блок 1: Первый экран и ориентация — 45 минут

Первое что видит пользователь определяет всё остальное. Здесь самая высокая цена ошибки.

### Правило 5 секунд

Открой главную страницу / первый экран и засеки 5 секунд. Потом закрой. Ответь на три вопроса:

• Что это за продукт?
• Для кого?
• Что нужно сделать дальше?

Если хоть один ответ неочевиден — проблема первого экрана. Это не субъективно — это провальный тест, который пройдёт и реальный пользователь.

### Чеклист первого экрана

• Заголовок объясняет что делает продукт (не «платформа нового поколения», а что именно)
• Видна целевая аудитория («для команд», «для фрилансеров», «для e-commerce»)
• Один главный CTA, а не три конкурирующих
• Нет автоплея видео со звуком
• Нет полноэкранного попапа в первые 5 секунд
• Загрузка не дольше 3 секунд (проверь в DevTools → Network → Slow 3G)
• На мобайле CTA виден без скролла

### Навигация и ориентация

• Пользователь понимает, где он находится (breadcrumbs, активный пункт меню)
• Понятно, как вернуться назад или на главную
• Лого кликабельно и ведёт на главную
• Мобильное меню открывается и закрывается без проблем
• Поиск есть там, где нужен (если продукт с большим количеством контента)

## Блок 2: Ключевой флоу — 2 часа

Это основа аудита. Проходишь главный сценарий пользователя от начала до конца — как будто ты делаешь это впервые.

### Как проходить флоу

Принципиально важно: не помогай себе. Если что-то непонятно — фиксируй, но не ищи решение сам. Именно растерянность и неопределённость — это и есть проблема.

На каждом шаге спрашивай:

• Куда я должен смотреть сейчас?
• Что мне предлагают сделать?
• Понятно ли что произойдёт если я нажму?
• Есть ли страх ошибиться?

### Чеклист онбординга

• Регистрация занимает менее 2 минут
• Первое полезное действие возможно сразу после регистрации
• Empty state объясняет что делать (не просто «у вас нет данных»)
• Прогресс онбординга виден (пользователь знает сколько ещё осталось)
• Каждый шаг имеет понятную цель (не «шаг 3 из 7», а «добавьте первый проект»)
• Есть возможность пропустить необязательные шаги
• После завершения онбординга понятно, что делать дальше

### Чеклист форм

Формы — концентрация UX-боли. Проверяй каждую форму в продукте:

• Только обязательные поля (каждое лишнее поле снижает conversion)
• Лейблы над полями (не placeholder вместо лейбла — он исчезает при вводе)
• Тип клавиатуры соответствует полю (email → email-клавиатура, телефон → цифровая)
• Ошибки появляются рядом с полем, а не вверху формы
• Сообщение об ошибке объясняет что сделать (не «неверный формат», а «введите email в формате name@domain.com»)
• Кнопка submit описывает результат («Создать аккаунт», а не «Далее»)
• Форма не сбрасывается при ошибке — данные сохраняются

### Чеклист ключевых действий

• Главное действие доступно за 1–2 клика с любого экрана
• Кнопка явно выделяется как главное действие (не теряется среди других)
• После действия есть явный фидбэк (что-то изменилось, появилось подтверждение)
• Деструктивные действия (удалить, отменить) требуют подтверждения
• Необратимые действия явно помечены как необратимые
• Есть возможность отменить случайное действие (undo или корзина)

## Блок 3: Читаемость и тексты — 45 минут

UX-проблемы часто живут не в структуре, а в словах. Плохие тексты ломают даже хороший интерфейс.

### Чеклист читаемости

• Размер основного текста не менее 16px (на мобайле)
• Контраст текста соответствует WCAG AA (минимум 4.5:1 для обычного текста)
• Строка не длиннее 65–75 символов (иначе читать тяжело)
• Межстрочный интервал не менее 1.4
• Текст не центрирован в длинных блоках (только в заголовках и коротких фразах)

### Чеклист UX-текстов

• Заголовки разделов описывают содержимое, а не украшают
• CTA-кнопки описывают действие и результат (глагол + объект: «Скачать отчёт», «Добавить участника»)
• Сообщения об ошибках не обвиняют пользователя («Неверный пароль» вместо «Вы ввели неверный пароль»)
• Empty states объясняют что делать, а не просто сообщают об отсутствии данных
• Нет технического жаргона без объяснения (если аудитория не техническая)
• Подтверждающие сообщения конкретны («Проект сохранён» а не «Успешно»)

## Блок 4: Мобайл и кроссплатформа — 45 минут

Если значительная часть аудитории на мобайле — это отдельный полноценный аудит. Мобайл не «уменьшенный десктоп»: там другие паттерны взаимодействия и другие проблемы.

### Чеклист мобильного UX

• Все кнопки и ссылки не менее 44×44px (минимальный tappable size)
• Нет элементов, которые требуют hover (мыши нет на телефоне)
• Формы не вызывают зум при фокусе (размер шрифта полей ≥ 16px)
• Контент не уходит за пределы экрана горизонтально
• Попапы закрываются и не блокируют всё на маленьком экране
• Swipe-жесты работают там, где ожидаются (галереи, карточки)
• Bottom navigation достижима большим пальцем

### Чеклист кроссбраузерности (быстрый)

• Проверь в Chrome и Safari (они дают разные результаты)
• Проверь в режиме инкогнито (без кеша и расширений)
• Проверь при медленном соединении (DevTools → Network → Slow 3G)

## Блок 5: Ошибки и крайние случаи — 30 минут

Большинство дизайнеров проверяют happy path — когда всё идёт по плану. Реальные пользователи живут в edge cases.

### Как проверять

Намеренно делай «неправильные» вещи:

• Вводи неверные данные в формы
• Нажимай «Назад» в браузере посередине флоу
• Прерывай действия на полпути
• Открывай глубокие ссылки без авторизации
• Пробуй пустые состояния (0 проектов, 0 уведомлений, 0 результатов поиска)

### Чеклист состояний

• 404 страница понятна и предлагает путь назад
• Состояние загрузки есть везде где есть ожидание (не пустой экран)
• Ошибка сети обрабатывается (не «белый экран», а понятное сообщение)
• Результаты поиска «0 элементов» объясняют почему и что делать
• Очень длинный контент не ломает вёрстку
• Пустые поля ввода показывают placeholder или подсказку
• Прерванная загрузка восстанавливается или ясно сообщает об ошибке

## Как документировать: система фиксации проблем

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

### Структура одной проблемы

Проблема: [одно предложение — что именно не работает]
Где: [экран, шаг флоу, конкретный элемент]
Severity: Critical / Major / Minor
Почему это проблема: [влияние на пользователя]
Скриншот: [приложи]
Возможное решение: [опционально, если очевидно]

### Классификация severity

Critical — блокирует выполнение ключевой задачи. Пользователь не может зарегистрироваться, оплатить, создать главный объект. Исправлять немедленно.

Major — значительно затрудняет задачу или создаёт высокий риск ошибки. Пользователь справляется, но с трудом или случайно делает не то. Исправлять в ближайшем спринте.

Minor — раздражает, снижает качество опыта, но не блокирует. Исправлять по возможности.

## Итоговый отчёт: от списка проблем к плану

В конце дня у тебя есть список проблем. Следующий шаг — превратить его в план.

### Матрица приоритизации

Для каждой проблемы оцени:

• Frequency: как часто пользователи с ней сталкиваются (единицы / часть / большинство)
• Impact: насколько серьёзно влияет на опыт (Minor / Major / Critical)
• Effort: сколько нужно чтобы исправить (часы / дни / недели)

Начинай с High frequency + High impact + Low effort — это быстрые победы с максимальным эффектом.

### Что включить в отчёт

1. Executive summary — 3–5 предложений: что проверяли, главные находки, рекомендация
2. Топ-5 критических проблем — с скриншотами и объяснением влияния
3. Полный список — сгруппированный по severity
4. Рекомендованные следующие шаги — приоритизированный план

## ИИ и UX-аудит: как Claude ускоряет диагностику

ИИ не заменяет прохождение интерфейса своими руками — но помогает на этапах подготовки, анализа и документирования.

### Промпт: подготовить чеклист под конкретный продукт

Я провожу UX-аудит [тип продукта: SaaS / e-commerce / мобильное приложение / маркетплейс].

Основная аудитория: [описание]
Главный флоу, который проверяю: [описание]
Известные проблемы или жалобы: [если есть]

Составь специализированный чеклист для этого аудита:
— Добавь критерии специфичные для этого типа продукта и аудитории
— Расставь приоритет: что проверять в первую очередь
— Укажи где чаще всего бывают критические проблемы в этом типе продукта

### Промпт: получить второй взгляд на скриншот

Загрузи скриншот экрана в Claude:

Вот скриншот [экрана / флоу] нашего продукта.

Целевое действие пользователя на этом экране: [описание]
Целевая аудитория: [описание]

Проведи экспресс-аудит:
1. Что первым бросается в глаза — и это правильный приоритет?
2. Есть ли элементы, которые могут запутать или создать ложные ожидания?
3. Что мешает пользователю выполнить целевое действие?
4. Оцени тексты: заголовок, CTA, подписи — понятны ли они?

### Промпт: приоритизировать список проблем

Вот список UX-проблем найденных при аудите:

[список проблем]

Приоритизируй их по матрице impact × effort.

Для каждой проблемы:
— Оцени влияние на пользователя (High / Medium / Low)
— Оцени примерное усилие на исправление (Low: часы / Medium: дни / High: недели)
— Итоговый приоритет

Выдели топ-5 «быстрых побед» — высокое влияние, низкое усилие.
Выдели топ-3 «стратегических» — высокое влияние, высокое усилие, стоит планировать.

### Промпт: написать executive summary аудита

Я провёл UX-аудит продукта [название / описание].

Главные найденные проблемы:
[список]

Напиши executive summary на полстраницы для руководства:
— Что проверяли и как
— Главный вывод (1 предложение)
— Топ-3 критические проблемы с влиянием на бизнес
— Рекомендация: что делать в первую очередь

Тон: конкретный, без UX-жаргона, с акцентом на влияние на пользователей и бизнес.

## Блок 6: Доступность — 30 минут

Доступность — не только про пользователей с ограниченными возможностями. Это про качество интерфейса в принципе. Продукт с хорошей доступностью обычно лучше для всех.

### Быстрая проверка без специальных инструментов

• Попробуй пройти ключевой флоу только с клавиатурой (Tab для перехода, Enter для подтверждения). Это работает?
• Увеличь масштаб браузера до 200% — ничего не сломалось, не уехало?
• Выключи CSS (в DevTools → ... → More tools → Rendering → Emulate CSS media feature prefers-color-scheme) и посмотри на структуру. Логична ли она?

### Чеклист доступности (базовый)

• Все изображения имеют alt-текст (кроме декоративных)
• Контраст текста соответствует WCAG AA (4.5:1) — проверь через WebAIM Contrast Checker
• Фокус-состояния видны (не убраны через outline: none)
• Интерактивные элементы достижимы с клавиатуры
• Формы имеют корректные лейблы (не только placeholder)
• Модальные окна захватывают фокус и возвращают его при закрытии

### Инструменты быстрой проверки

• axe DevTools (браузерное расширение) — автоматически находит нарушения WCAG
• Lighthouse (Chrome DevTools → Lighthouse → Accessibility) — даёт оценку от 0 до 100
• WAVE (wave.webaim.org) — визуальный инспектор доступности

Цель быстрого аудита — не идеальный балл, а критические блокеры. Проверь Lighthouse: если балл ниже 70 — есть серьёзные проблемы.

## Блок 7: Производительность как UX — 20 минут

Скорость — это дизайн. Медленный продукт — плохой UX независимо от того насколько красивы экраны.

### Что проверять

Запусти Google PageSpeed Insights (pagespeed.web.dev) для главных страниц продукта. Смотри на:

• LCP (Largest Contentful Paint) — когда пользователь видит главный контент. Норма: < 2.5 секунд
• FID / INP (Interaction to Next Paint) — насколько быстро реагирует интерфейс. Норма: < 200мс
• CLS (Cumulative Layout Shift) — прыгают ли элементы при загрузке. Норма: < 0.1

Если любой из них в «красной» зоне — это UX-проблема, а не только техническая.

### Чеклист производительности

• LCP < 2.5 сек на мобайле (наиболее критично)
• Нет CLS — контент не прыгает при загрузке изображений
• Тяжёлые изображения оптимизированы (используй WebP, правильные размеры)
• Загрузка при медленном соединении (Slow 3G в DevTools) приемлема
• Скелетоны или плейсхолдеры показаны пока грузится контент

## Типичные находки аудита по типам продукта

Разные типы продуктов имеют разные «типичные» проблемы. Зная их — проверяешь в первую очередь.

### SaaS / B2B

Самые частые проблемы:

• Пустые экраны без направления после регистрации
• Перегруженные дашборды с 20+ метриками без иерархии
• Требование заполнить профиль до доступа к функционалу
• Неочевидное различие между платными и бесплатными функциями

### E-commerce

Самые частые проблемы:

• Медленная загрузка страниц каталога и карточек товаров
• Сложный или многошаговый checkout
• Отсутствие «Гость» опции при оформлении заказа
• Мобильная корзина работает иначе чем десктопная

### Мобильные приложения

Самые частые проблемы:

• Слишком маленькие tap targets (особенно в списках)
• Нет deep linking — уведомление ведёт на главный экран, не на конкретный контент
• Запрос разрешений без объяснения зачем (geolocation, camera, notifications)
• Bottom sheet не закрывается свайпом вниз

### Маркетплейсы

Самые частые проблемы:

• Поиск возвращает нерелевантные результаты без фильтров
• Страница результатов поиска не помнит фильтры при возврате
• Нет сравнения нескольких товаров/предложений
• Процесс размещения (для продавца) слишком сложен

## После аудита: как не потерять находки

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

### Система работы с находками

Трекер задач, а не документ. Каждая найденная проблема — отдельная задача в Jira/Linear/Notion. С описанием, скриншотом, severity и оценкой усилия.

Встреча по результатам. 30–45 минут с продактом и командой. Проходишь топ-10 проблем, договариваешься о приоритетах, фиксируешь решения.

Быстрые победы отдельно. Выдели 5–10 задач, которые можно закрыть за день без разработчика (текст, цвет, порядок элементов). Закрой их сразу — это даёт импульс и показывает ценность аудита.

Ревизия через квартал. Что из найденного исправлено? Что нет? Почему? Появились ли новые проблемы? Это превращает аудит из разового события в регулярную практику.