Как провести быстрый UX-аудит интерфейса за 30 минут

Что такое экспресс-аудит и чем он не является

Экспресс-аудит — это экспертная оценка интерфейса по одному-двум ключевым сценариям с фиксированным временем. Его задача — быстро найти очевидные барьеры: места, где пользователь теряется, ошибается или бросает задачу. Это не замена юзабилити-тестированию и не исследование мотивации: вы смотрите на продукт глазами специалиста, а не реального клиента.

Ограничение по времени здесь не формальность. Без него аудит расползается: появляется желание проверить все экраны, поспорить о шрифтах и переписать тексты. Тридцать минут заставляют держаться сценария и отбирать только то, что действительно мешает пройти путь от входа до результата.

Хороший экспресс-аудит отвечает на три вопроса: где в главном сценарии пользователь может застрять, какие нарушения базовых принципов юзабилити видны сразу и какие проблемы доступности блокируют часть аудитории. Всё остальное — материал для следующей, более глубокой итерации.

Минуты 0–5: задаём рамку

Сначала сформулируйте цель продукта и выберите один сценарий, который приносит ему ценность: оформить заказ, создать проект, отправить заявку, найти документ. Запишите его как задачу пользователя с понятным финалом: «оплатить подписку и получить доступ к кабинету». Если сценариев несколько, берите тот, через который проходит больше всего людей или денег.

Затем определите контекст: устройство, ширину экрана, состояние аккаунта. Новый пользователь и постоянный клиент видят разные интерфейсы, и смешивать их в одном проходе нельзя. Для первого аудита обычно выгоднее смотреть на новичка с мобильного устройства — там проблемы проявляются острее всего.

Подготовьте таблицу из четырёх колонок: экран или шаг, наблюдение, нарушенный принцип, серьёзность. Заполнять её вы будете по ходу, а не после. Это экономит время на отчёт и не даёт забыть детали, которые кажутся очевидными в моменте.

Включите запись экрана. Через полчаса вы не вспомните, на каком шаге мелькнул непонятный индикатор или почему форма сбросилась, а видео позволит вернуться к моменту за несколько секунд и сделать точный скриншот для отчёта.

• цель продукта в одном предложении
• один сценарий с измеримым финалом
• устройство, ширина экрана, тип пользователя
• таблица для наблюдений

Минуты 5–15: проходим сценарий как пользователь

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

Отдельно отмечайте места, где интерфейс требует от пользователя запоминания: код из письма, который нужно ввести на другом экране, повторный ввод уже указанных данных, условия, которые показали один раз и спрятали. Повторный ввод информации в WCAG 2.2 вынесен в отдельный критерий 3.3.7 «Избыточный ввод» — это хороший индикатор того, что проблема распространённая.

Обратите внимание на ошибки. Специально введите некорректный email, пропустите обязательное поле, нажмите кнопку дважды. Посмотрите, где появляется сообщение, понятно ли оно и сохраняются ли уже введённые данные. Обработка ошибок чаще всего проверяется в последнюю очередь и поэтому чаще всего сломана.

Засекайте, сколько действий занимает сценарий. Само число мало что говорит, но лишние шаги видны сразу: подтверждение, которое ничего не подтверждает, промежуточный экран без решения, обязательная регистрация перед просмотром каталога.

Минуты 15–22: сверяемся с эвристиками

Теперь вернитесь к пройденным экранам и посмотрите на них через десять эвристик Якоба Нильсена. Это не исчерпывающий список правил, а удобная сетка, которая помогает назвать проблему и не спорить о вкусе. Не нужно проверять каждую эвристику на каждом экране — достаточно пробежаться по списку и вспомнить, где что-то цепляло.

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

Не забывайте про закон Хика: время выбора растёт с количеством вариантов. Если на ключевом шаге пользователю предлагают семь равнозначных кнопок, это не обязательно ошибка, но точно кандидат на упрощение. То же с законом Фиттса: главное действие должно быть крупным и находиться там, куда ведёт сценарий, а не в углу экрана.

Если наблюдение не ложится ни на одну эвристику, всё равно запишите его, но пометьте как гипотезу. Такие пункты часто оказываются проблемами контента или бизнес-логики, и их полезнее обсудить с продактом, чем пытаться решить средствами интерфейса.

• видимость состояния системы
• соответствие реальному миру
• контроль и свобода пользователя
• единообразие и стандарты
• предотвращение ошибок
• узнавание вместо припоминания
• гибкость и эффективность
• эстетичный и минималистичный дизайн
• помощь в распознавании и исправлении ошибок
• справка и документация

Минуты 22–27: базовые проверки доступности

За пять минут невозможно провести аудит доступности, но можно найти блокеры. Первая проверка — клавиатура: уберите руку с мыши и пройдите сценарий клавишей Tab. Виден ли фокус на каждом элементе, логичен ли порядок, можно ли закрыть модальное окно клавишей Escape. Отсутствующий фокус нарушает критерий 2.4.7 и делает интерфейс непроходимым для части пользователей.

Вторая проверка — масштаб. Увеличьте страницу до 200% в браузере и сузьте окно до 320 CSS-пикселей: по критерию 1.4.10 контент не должен требовать горизонтальной прокрутки. Третья — контраст: проверьте основной текст, плейсхолдеры и кнопки любым анализатором. Для обычного текста нужен коэффициент 4,5:1, для границ полей и иконок — 3:1.

Наконец, посмотрите на размеры кликабельных элементов на мобильном. Критерий 2.5.8 требует минимум 24×24 CSS-пикселя или достаточного отступа между целями. Маленькие крестики закрытия и плотно стоящие ссылки в подвале — типичная находка.

Минуты 27–30: приоритизация и отчёт

Оцените каждую находку по шкале серьёзности. Удобна четырёхуровневая: критично (блокирует сценарий), серьёзно (сильно замедляет или вызывает ошибки), умеренно (раздражает, но не мешает), косметика. Учитывайте частоту: проблема на главном экране важнее такой же на редко посещаемой странице.

Отчёт должен помещаться на один экран. Сверху — три-пять главных проблем со скриншотом, описанием и предложением, что проверить или изменить. Ниже — остальной список из таблицы. Формулируйте наблюдения как факты, а не оценки: «после отправки формы нет подтверждения, кнопка остаётся активной» вместо «форма сделана плохо».

Честно обозначьте ограничения: аудит проведён одним экспертом, по одному сценарию, без реальных пользователей. Это защищает от ложной уверенности и подсказывает следующий шаг — например, короткое юзабилити-тестирование спорных мест.

После обсуждения превратите главные находки в задачи в трекере и привяжите к ним скриншоты из отчёта. Через пару спринтов повторите тот же тридцатиминутный проход по тому же сценарию: так вы увидите, закрылись ли проблемы и не появились ли новые. Регулярный короткий аудит полезнее разового большого, который устаревает к моменту, когда его дочитали.

Редакция Флагштока

Пишем об UX/UI-дизайне: исследования, интерфейсы, дизайн-системы и доступность.