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

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

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

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

Что такое UX-аудит сайта

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

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

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

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

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

UX-аудит также следует отличать от редизайна. Аудит выявляет проблемы и помогает определить необходимые изменения. Редизайн предполагает переработку визуальных решений, структуры или пользовательских сценариев.

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

Когда необходим UX-аудит

Отправной точкой должна быть конкретная проблема или задача бизнеса.

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

В такой ситуации необходимо определить, на каком участке возникают затруднения.

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

Эта задача подробнее рассмотрена в статье «Сайт не приносит заявки: где теряются клиенты».

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

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

Другая ситуация, десктопная версия сайта работает корректно, но пользователям смартфонов неудобно заполнять форму или пользоваться каталогом.

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

Что проверяют во время UX-аудита

Состав проверки зависит от типа проекта, целевой аудитории и поставленной задачи.

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

Однако есть несколько основных направлений, которые рассматривают при большинстве проверок.

Структура и навигация

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

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

Отдельное внимание уделяют соответствию структуры задачам аудитории.

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

Подобное расхождение становится предметом исследования.

Содержание ключевых страниц

На этом этапе проверяют, получает ли посетитель сведения, необходимые для следующего действия.

Страница услуги может подробно рассказывать о преимуществах компании, но не объяснять состав работ, условия сотрудничества или порядок расчёта стоимости.

В результате потенциальному клиенту приходится самостоятельно искать недостающую информацию либо обращаться к менеджеру за ответами на базовые вопросы.

Аудитор оценивает соответствие содержания пользовательским задачам и последовательность представления информации.

Интерфейс и интерактивные элементы

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

Специалист выясняет, насколько понятны доступные действия и получает ли человек ожидаемый результат после их выполнения.

Например, после отправки формы интерфейс должен подтвердить успешное завершение операции либо объяснить, какие данные необходимо исправить.

Если после нажатия кнопки ничего не происходит, посетитель может не понять, отправлена ли заявка.

Конкретные примеры подобных проблем представлены в статье об ошибках юзабилити сайта.

Мобильные пользовательские сценарии

Мобильную версию необходимо оценивать отдельно.

Правильное отображение элементов на узком экране ещё не означает, что посетитель сможет удобно выполнить нужное действие.

Например, раскрывающееся меню работает корректно до появления экранной клавиатуры. Или закреплённый виджет перекрывает кнопку, необходимую для завершения оформления заказа.

При UX-аудите проверяют удобство самого взаимодействия.

Техническая приёмка отображения на различных устройствах рассматривается отдельно в материале о проверке адаптивной вёрстки сайта.

Как проводится UX-аудит: основные этапы

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

Между этими этапами необходимо собрать и сопоставить информацию, позволяющую обосновать обнаруженные проблемы.

Этап 1. Определение целей и границ аудита

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

Для сайта услуг это может быть путь от знакомства с предложением до отправки обращения. Для интернет-магазина — поиск товара, сравнение вариантов и оформление заказа.

Если проект работает с несколькими аудиториями, их сценарии рассматривают отдельно.

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

На этом этапе также определяют страницы, устройства и функциональные элементы, входящие в проверку.

Этап 2. Анализ доступных данных

Следующий этап — изучение информации о фактическом использовании сайта.

В зависимости от настроенной аналитики специалист может исследовать:

• посещаемость ключевых страниц;

• последовательность действий посетителей;

• взаимодействия с формами;

• различия между мобильными и десктопными сценариями;

• карты кликов и прокрутки;

• записи посещений.

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

Однако сама статистика ещё не объясняет причину. Посетитель мог столкнуться с неудобным интерфейсом, решить связаться другим способом или отказаться от обращения по причинам, не связанным с сайтом.

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

Если необходимые события не измеряются, сначала проверяют достоверность имеющейся информации. Принципы такой работы раскрыты в статье «Как настроить аналитику сайта».

Этап 3. Экспертная оценка интерфейса

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

Для проверки могут использоваться эвристики Якоба Нильсена — общие принципы проектирования удобных интерфейсов.

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

Однако обнаруженное отклонение от эвристики не всегда означает, что интерфейс обязательно необходимо изменить.

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

Поэтому каждое замечание рассматривают с учётом конкретного пользовательского сценария.

Этап 4. Проверка обнаруженных проблем

После экспертной оценки формируется перечень потенциальных затруднений.

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

Другие наблюдения требуют дополнительного исследования.

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

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

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

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

Не каждая проблема требует отдельного пользовательского тестирования. Однако степень её подтверждения должна быть понятна заказчику.

Этап 5. Подготовка рекомендаций

На заключительном этапе специалист объединяет полученные результаты, исключает дублирующие замечания и определяет приоритеты.

Рекомендации связывают с конкретными страницами, сценариями и обнаруженными затруднениями.

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

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

Как отличить подтверждённую проблему от предположения

Одна из наиболее сложных задач UX-аудита заключается в правильной интерпретации собранной информации.

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

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

Рассмотрим условный пример.

На сайте поставщика оборудования форма запроса расчёта содержит обязательное поле для указания точной модели изделия.

Аудитор предполагает, что это поле может создавать затруднения для новых клиентов, которые ещё не определились с выбором оборудования.

Однако предположение необходимо проверить.

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

Возможное решение определяется с учётом бизнес-процессов компании. Например, без точной модели менеджер может быть не способен рассчитать стоимость, но иметь возможность помочь клиенту с подбором.

В такой ситуации потребуется пересмотреть сам сценарий обращения.

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

Что бизнес должен получить по результатам UX-аудита

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

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

Для каждой существенной проблемы в отчёте желательно указать:

1. Страницу и пользовательский сценарий.

2. Описание обнаруженного затруднения.

3. Скриншот или другую наглядную фиксацию.

4. Подтверждающие данные либо необходимость дополнительной проверки.

5. Рекомендуемое изменение и его приоритет.

6. Способ проверки результата после внедрения.

Отдельно составляют сводный план работ.

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

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

При этом не каждое замечание требует немедленного исправления.

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

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

Пример из практики Guard-IT: промышленный сайт ПО СЭСП

При разработке сайта электромонтажной компании ПО СЭСП требовалось учитывать задачи промышленного заказчика.

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

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

Для обращения предусмотрена форма с возможностью приложить материалы проекта.

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

Реальные интерфейсы и состав выполненной работы представлены в кейсе ПО СЭСП.

Этот проект иллюстрирует, как учёт пользовательских сценариев влияет на структуру и содержание сайта ещё на этапе разработки.

Как оценивают результат после внедрения рекомендаций

После завершения аудита компания получает основания для дальнейших изменений. Их эффективность необходимо проверять отдельно.

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

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

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

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

При оценке бизнес-показателей необходимо учитывать сопутствующие изменения.

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

Сам аудит выявляет потенциальные и подтверждённые проблемы. Фактический результат предложенных изменений оценивается после их реализации.