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

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

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

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

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

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

Отделяйте наблюдение от предполагаемой причины. Человек мог не заметить кнопку из-за текста, расположения или контраста; аудит не должен объявлять единственную причину без проверки. Если причина неизвестна, предложите маленькую проверку: изменить подпись или прототип, затем повторить задачу.

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

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

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

Не обещайте рост конверсии только по числу закрытых замечаний. Исправленный интерфейс должен сначала пройти функциональную проверку; влияние на бизнес оценивают по данным после выпуска и с учётом источников трафика. Так UX-аудит становится циклом принятия решений, а не списком вкусовых правок.