UX-аудит сайта: как найти препятствия на пути пользователя

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

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

Когда UX-аудит действительно поможет

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

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

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

Разделите экспертный разбор, аналитику и тестирование

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

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

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

Как подготовить задание на UX-аудит

Опишите начало и конец сценария

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

Назовите состояния, которые легко пропустить

Обычный путь редко показывает все проблемы. Добавьте отсутствие товара, пустой результат фильтра, неверный телефон, потерю связи и возврат к заполненной форме. Для услуг важны неполные исходные данные и запрос, который не подходит компании. Интерфейс должен объяснять человеку, что произошло и что можно сделать дальше.

Укажите устройства и права доступа. Мобильный посетитель, постоянный клиент с личным кабинетом и новый покупатель могут видеть разные интерфейсы. В рабочие материалы передавайте обезличенные примеры, а доступ к аналитике выдавайте в объёме, необходимом для исследования.

Карточка проблемы: пример полезной фиксации

К карточке добавляют адрес, шаги воспроизведения и изображение состояния, если оно помогает исполнителю. Формулировка должна отделять наблюдение от объяснения. «Ошибка не показана» проверяется сразу; «из-за этого потеряна половина заказов» требует отдельных данных. Масштаб проблемы определяют по частоте, важности сценария и доступным обходным путям.

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

Как выбрать порядок исправлений

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

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

Чек-лист приёмки отчёта

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

Частые вопросы

UX-аудит включает новый дизайн?

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

Можно оценить сайт только по скриншотам?

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

Как понять, что исправление помогло?

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

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