Обычно ко мне приходят с фразой «конверсия просела, а почему — не понятно». Редизайн заказывать страшно, гипотез много, спорят все. UX-аудит как раз для такого момента: за неделю он превращает споры в список конкретных проблем с приоритетами. Ниже мой порядок работы по дням, список данных, которые стоит запросить, и чек-лист, который можно взять себе.
Что входит в UX-аудит и чего в нём нет
UX-аудит — это независимая проверка того, насколько удобно пользователям решать свои задачи в вашем сайте или приложении. На выходе не «мне не нравятся кнопки», а список мест, где человек ошибается, теряется или уходит, и понимание, что исправлять первым.
Обычно в аудит входят четыре части:
- разбор данных: аналитика, записи сессий, обращения в поддержку;
- эвристический анализ интерфейса по известным принципам юзабилити;
- прохождение ключевых сценариев глазами нового пользователя;
- отчёт с приоритетами и вариантами решений.
Чего в аудите нет: нового дизайна, пользовательских интервью и A/B-тестов. Это следующие шаги, и аудит помогает понять, какие из них нужны. Если после него остаётся много вопросов «почему люди так делают», я предлагаю добавить пять-шесть коротких интервью или юзабилити-тестов. Но начинать с них, не посмотрев данные, дороже и дольше.
Когда аудит нужен
Чаще всего аудит заказывают в нескольких ситуациях: упала конверсия и непонятно почему; перед редизайном, чтобы не переделывать то, что работало; после запуска, когда в поддержку пошли однотипные вопросы; перед вложением в рекламу, чтобы трафик не утекал в неудобную воронку. Во всех случаях логика одна: сначала понять, что ломается, потом чинить.
Ещё один повод — смена команды. Новому дизайнеру или продакту аудит даёт карту продукта и честный список долгов, на который можно опереться, не споря о прошлом.
План на неделю: что делаю по дням
Неделя — это пять рабочих дней на один продукт с несколькими ключевыми сценариями. Для большого сервиса с десятками разделов я заранее договариваюсь, какие сценарии берём, иначе аудит растягивается.
| День | Что делаю | Что получаю |
|---|---|---|
| 1 | Созвон с командой, цели, сценарии, доступы к данным | Список главных сценариев и метрик, гипотезы команды |
| 2 | Разбор аналитики, записей сессий и обращений | Карта мест, где люди уходят и ошибаются |
| 3 | Эвристический анализ экранов | Список нарушений с привязкой к экранам |
| 4 | Прохождение сценариев на телефоне и компьютере, проверка доступности и скорости | Путь пользователя с отмеченными точками трения |
| 5 | Приоритизация, отчёт, варианты решений | Документ и подготовка к разбору с командой |
Разбор отчёта вместе с командой — отдельная короткая встреча после пятого дня. Без неё отчёт часто остаётся в папке.
День 1–2. Какие данные запросить до начала
Хороший аудит держится на данных, а не на моём вкусе. Поэтому до старта прошу у команды четыре вещи.
Веб-аналитика
Доступ на чтение к Яндекс Метрике, Google Analytics или внутренней аналитике продукта. Смотрю воронки по ключевым сценариям, страницы с высоким процентом выходов, разницу между мобильными и десктопными пользователями, поведение новых и вернувшихся.
Записи сессий
Вебвизор в Метрике или похожие инструменты. Я смотрю не всё подряд, а выборку: сессии, которые закончились уходом на шаге оплаты или регистрации, и сессии с «яростными кликами» по элементам, которые не кликаются. Десять-пятнадцать таких записей обычно показывают больше, чем таблица с цифрами.
Обращения в поддержку
Выгрузка вопросов и жалоб за несколько месяцев, отзывы в магазинах приложений, комментарии в соцсетях. Часто вижу в аудитах одно и то же: тема, которая постоянно всплывает в поддержке («как отменить заказ», «где мой документ»), на самом деле дыра в интерфейсе.
Контекст от команды
Цели продукта, портреты клиентов, что уже пробовали менять и чем это закончилось. Это экономит время: не придётся предлагать то, что команда уже проверила.
Если аналитика не настроена, это тоже результат аудита. Не откладывайте старт: начните с записей сессий и обращений в поддержку, а настройку целей и воронок включите в список задач отчёта.
Про то, как соотносить такие данные с деньгами, я писал в статье о том, где продукт теряет клиентов.
День 3. Эвристический анализ
Эвристический анализ — проверка интерфейса по списку признанных принципов. Чаще всего берут десять эвристик Якоба Нильсена. Я иду по экранам ключевых сценариев и для каждого отмечаю, какие принципы нарушены.
- Видимость состояния системы. Человек понимает, что происходит: загрузка, шаг в процессе, результат действия.
- Соответствие реальному миру. Слова и логика понятны пользователю, а не внутренней команде.
- Контроль и свобода. Есть «отмена», «назад», выход из состояния.
- Согласованность. Одинаковые вещи выглядят и работают одинаково.
- Предотвращение ошибок. Интерфейс не даёт совершить очевидную ошибку.
- Узнавание вместо запоминания. Нужное видно на экране, его не надо вспоминать.
- Гибкость и эффективность. Опытным пользователям доступны быстрые пути.
- Минимализм. Нет лишнего, что отвлекает от главного.
- Помощь с ошибками. Сообщение об ошибке говорит, что случилось и что делать.
- Справка и подсказки. Помощь там, где она нужна, а не в отдельном разделе.
Добавляю к списку то, что в нём не прописано: контраст текста (для обычного текста по WCAG 2.2 нужно не менее 4,5:1), размер зон нажатия на телефоне, читаемость шрифтов, поведение при плохом интернете.
Один пример из типичных находок. Было: на форме заказа поле телефона принимает текст, а при ошибке очищается, и человек вводит всё заново. Стало: цифровая клавиатура через inputmode="tel", автозаполнение через autocomplete="tel", ошибка рядом с полем, введённое сохраняется. Подробнее про такие случаи — в разборе ошибок в формах.
Эвристики работают лучше, когда оценивает не один человек. Если есть возможность, пусть второй дизайнер или аналитик пройдёт те же экраны отдельно, потом сравните. Один человек обычно находит лишь часть проблем.
День 4. Путь пользователя
Эвристики смотрят на экраны по отдельности, а клиенты живут в сценариях. Поэтому я беру три-пять главных задач, например «найти товар и оплатить», «зарегистрироваться и дойти до первой пользы», «оформить заявку», и прохожу их от первого касания до результата.
Проходить стоит дважды: на телефоне и на компьютере. Во многих продуктах мобильная версия — основная по трафику, а проверяют её в последнюю очередь.
Для каждого шага записываю:
- что пользователь хочет сделать;
- что ему показывает интерфейс;
- где он сомневается, ошибается или ждёт;
- какие данные это подтверждают (аналитика, запись, обращение).
Получается таблица или схема пути с отмеченными точками трения. Она хорошо работает на встрече: команда видит свой продукт глазами человека, который его открыл впервые.
В этот же день проверяю скорость. Смотрю на показатели Core Web Vitals (LCP, INP, CLS) в отчёте Search Console или PageSpeed Insights. Если страница с главным действием грузится медленно или прыгает во время загрузки, это тоже проблема интерфейса, а не только разработки. Если в продукте есть AI-функции, отдельно смотрю, понятно ли пользователю, что отвечает модель и как поправить ответ: об этом у меня есть отдельная статья про AI в интерфейсе.
Конкурентов смотрю выборочно: как они решают те же задачи, к каким паттернам привыкла аудитория. Копировать чужое не нужно, но знать привычки пользователей полезно.
День 5. Как приоритизировать проблемы
К пятому дню обычно накапливается несколько десятков замечаний. Отдать команде их все списком — значит ничего не изменить. Поэтому каждую проблему я оцениваю по двум осям: насколько она вредит пользователю и бизнесу и насколько сложно её исправить.
| Группа | Признак | Что делать |
|---|---|---|
| Критичные | Блокируют главный сценарий: нельзя оплатить, отправить заявку, войти | Исправлять в первую очередь, до любых улучшений |
| Быстрые победы | Заметный эффект, правка занимает часы или пару дней | Взять в ближайший спринт |
| Крупные задачи | Серьёзно влияют, но требуют переделки раздела | Запланировать, подготовить дизайн |
| Мелочи | Раздражают, но на результат почти не влияют | Собрать в бэклог, делать по ходу работы |
Оценку серьёзности делаю по трём вопросам. Как часто с этим сталкиваются? Насколько тяжело пользователю обойти проблему? Какой сценарий затронут: ключевой или второстепенный? Проблема, которую видят все на шаге оплаты, важнее проблемы, которую видят редкие пользователи в настройках.
Оценки сложности я согласую с разработчиками команды. Дизайнер часто недооценивает или переоценивает трудоёмкость, а ошибка здесь ломает весь порядок приоритетов.
Как объяснять приоритеты руководителям, не уходя в разговор о вкусе, я описывал в статье «Как говорить с бизнесом о дизайне».
Формат результата: что получает команда
Отчёт должен читаться за полчаса и превращаться в задачи без дополнительных вопросов. Моя структура такая:
- Краткое резюме на одной странице. Главные выводы и пять-семь самых важных проблем.
- Список проблем с приоритетами. У каждой: где находится, скриншот, почему это проблема, на какие данные опираюсь, серьёзность и сложность исправления.
- Путь пользователя с отмеченными точками трения.
- Рекомендации и варианты решений для самых важных проблем: эскизы или короткое описание, что поменять.
- План действий на ближайшие недели и предложение, что проверять тестами.
Пишите проблему как наблюдение, а не как приговор. «В просмотренных записях люди на шаге оплаты возвращаются на предыдущий экран, ища промокод» — полезно. «Оплата неудобная» — спор на ровном месте. Если в отчёте есть цифры, они должны быть из ваших данных, а не из головы.
После отправки отчёта провожу созвон: разбираем вместе, что понятно, что спорно, что команда может начать завтра. Примеры моих проектов можно посмотреть в разделе с работами. А как я использую AI при разборе данных и подготовке материалов, описано в статье про AI в моей работе. Анализ и выводы при этом остаются за человеком: модель может помочь сгруппировать обращения, но решать, что важно, нужно самому.
Чек-лист юзабилити-аудита
Это сокращённая версия того, по чему я иду. Можно взять её и пройтись самостоятельно, прежде чем заказывать аудит.
Подготовка
- Определены 3–5 главных сценариев и целевое действие каждого.
- Есть доступ к аналитике, записям сессий, обращениям в поддержку.
- Известны основные устройства и браузеры аудитории.
Структура и навигация
- С любой страницы понятно, где вы находитесь и как вернуться.
- Названия разделов совпадают с тем, как называет их клиент.
- Главное действие на странице одно и оно заметно.
Формы и действия
- Нет лишних полей, у каждого есть понятная подпись.
- Подходящая клавиатура и автозаполнение на телефоне.
- Ошибки показываются рядом с полем и объясняют, что исправить.
- После отправки понятно, что произошло и что дальше.
Контент и читаемость
- Контраст текста не ниже 4,5:1, размер шрифта читается на телефоне.
- Зоны нажатия достаточно большие и не слипаются.
- Тексты написаны для клиента, без внутреннего жаргона.
Состояния и скорость
- Есть состояния загрузки, пустого списка, ошибки сети.
- Главная страница сценария открывается быстро, элементы не прыгают.
- Действия, которые нельзя отменить, требуют подтверждения.
Доступность
- Сайтом можно пользоваться с клавиатуры, фокус виден.
- У изображений и иконок-кнопок есть текстовые описания.
- Информация не передаётся только цветом.
Частые вопросы
Что входит в UX-аудит сайта?
Разбор данных (аналитика, записи сессий, обращения в поддержку), эвристический анализ интерфейса, прохождение ключевых сценариев на телефоне и компьютере и итоговый отчёт с приоритетами и вариантами решений.
Сколько длится UX-аудит?
Для одного продукта с несколькими ключевыми сценариями хватает рабочей недели. Для крупного сервиса с множеством разделов сроки зависят от объёма: сначала согласовываем, какие сценарии берём в работу.
Чем UX-аудит отличается от юзабилити-тестирования?
Аудит — это экспертная проверка по данным и принципам юзабилити, без участия пользователей. В тестировании реальные люди выполняют задачи, а вы наблюдаете. Аудит быстрее и дешевле, тестирование лучше отвечает на вопрос «почему». Часто их используют вместе.
Какие данные нужны для UX-аудита?
Минимум: доступ к аналитике, записи сессий и выгрузка обращений в поддержку. Дополнительно — цели продукта, портреты клиентов и список того, что вы уже пробовали менять. Если аналитики нет, аудит всё равно можно провести, но выводы будут менее точными.
Можно ли провести UX-аудит самостоятельно?
Да, чек-лист выше подойдёт для первого прохода. Но взгляд изнутри команды часто пропускает очевидное: вы привыкли к своему интерфейсу. Поэтому хорошо, если проверку делает человек со стороны или хотя бы тот, кто не участвовал в разработке.
Что делать после аудита?
Исправить критичные проблемы и быстрые победы, спланировать крупные задачи и после правок снова посмотреть на метрики. Если остаются вопросы «почему», добавьте интервью или юзабилити-тест.
Хороший аудит заканчивается не красивым документом, а задачами в трекере, которые команда может взять на следующий день. Если хотите быстро понять, где у вас самые заметные проблемы, начните с мини-аудита: семь вопросов, около минуты. А если нужен разбор продукта целиком, напишите мне, обсудим задачу и с чего лучше начать.