UX-аудит приложения и сайта: что проверяют и как выглядит отчёт

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

18 октября 2026Разработка16 мин чтения

---

Что такое UX-аудит приложения и сайта

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

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

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

Какие методы используют при проверке

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

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

Как анализируют воронку действий

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

События и условия подсчёта

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

От потери на шаге к проверяемой гипотезе

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

Что проверяют в пользовательском пути

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

Эвристики: понятность и контроль действий

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

Навигация и поиск

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

Выбор товара или услуги

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

Формы и оформление

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

Состояния и обратная связь

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

Доступность интерфейса

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

Чем отличаются проверки сайта и приложения

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

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

Когда заказывать аудит и как определить границы

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

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

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

Данные для начала работы

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

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

Порядок проведения UX-аудита

1. Согласовать границы. Результат — перечень сценариев и устройств. Проверяют, что известны начало пути и успешное завершение.
2. Подготовить данные. Результат — доступы и список источников. Проверяют работоспособность учётных записей и значение событий.
3. Пройти сценарии. Результат — наблюдения с подтверждениями. Проверяют воспроизводимость и условия каждой находки.
4. Оформить отчёт. Результат — карточки и приоритеты. Проверяют основания вывода и критерии предлагаемых правок.
5. Обсудить действия. Результат — согласованный план. Проверяют ответственных, зависимости и способ повторной оценки.

Как определяют критичность ошибок

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

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

Как выглядит отчёт по UX-аудиту

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

Структура документа

• Контекст. Задача бизнеса, аудитория и выбранные маршруты.
• Условия. Дата проверки, версии, устройства и доступные данные.
• Сводка. Основные препятствия и порядок работы с ними.
• Карточки проблем. Шаги, наблюдение, подтверждение и рекомендация.
• План действий. Зависимости, ответственные и критерии проверки.
• Ограничения выводов. Непроверенные сценарии и вопросы для дальнейшего исследования.

Формат согласуют до начала: документ со скриншотами, таблица задач или сочетание обоих вариантов. Макеты изменений и тестирование после внедрения включаются отдельно, если предусмотрены договорённостью. Отчёт и разработка UX/UI-дизайна дают разные результаты.

Образец одной страницы отчёта

УЧЕБНЫЙ ОТЧЁТ · СТРАНИЦА 1

UX-07. Сброс выбранного размера при возврате
Сценарий: выбор товара → корзина → возврат к товару

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

Поле	Содержание
Место и условия	Карточка одежды → корзина → возврат; мобильный сайт, авторизация отсутствует. Учебный стенд: версия 1.0, Chrome, окно 390×844, проверка 13.10.2026.
Шаги воспроизведения	Открыть товар; выбрать размер M; добавить в корзину; открыть корзину; вернуться кнопкой браузера к карточке.
Ожидаемое поведение	Размер M остаётся выбран; товар в корзине соответствует выбранному варианту.
Наблюдение	После возврата выбор размера пуст; товар в корзине сохраняется
Подтверждение	В учебном сценарии после возврата поле размера пустое, а корзина содержит размер M. Для реального отчёта прикладывают снимки обоих состояний или запись воспроизведения.
Последствие	Покупателю нужно повторно выяснить выбранный вариант; частота затруднения не измерена
Приоритет	Критичность: затрудняет действие, покупку завершить возможно. Охват: неизвестен. Приоритет внедрения согласовать после проверки охвата и оценки работ.
Гипотеза	Сохранение состояния уменьшит необходимость повторного выбора. Влияние на уход покупателей не измерено.
Рекомендация	Сохранить состояние выбранного размера при возврате и обозначить добавленный вариант
Приёмка	После возврата отображается исходный размер; смена размера явно меняет выбор; корзина показывает соответствующий вариант
Проверка результата	Повторить сценарий на согласованных устройствах и наблюдать выполнение задания участниками

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

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

Приоритет отражает влияние на задачу пользователя и основания вывода. В методике NN/g по оценке серьёзности рассматривают частоту проблемы, её влияние и устойчивость затруднения. Для плана внедрения дополнительно обсуждают трудоёмкость и зависимости.

Серьёзность и уверенность

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

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

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

Список гипотез и порядок проверки

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

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

Как превратить отчёт в задачи и проверить результат

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

Задача на изменение

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

Проверка после внедрения

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

Рост заказов в период правки может совпасть с рекламной кампанией или изменением ассортимента. Чтобы проверить влияние интерфейса, при подходящих условиях используют A/B-тестирование — сравнение вариантов на разделённых группах. Для качественной проверки повторяют задания с участниками. Метод и ограничения фиксируют до оценки эффекта.

Какие сценарии видны в кейсах АстМаркет и Сыроварни

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

АстМаркет: витрина, каталог и карточка товара

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

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

Сыроварня: корзина и оформление в одном окне

В приложении сети ресторанов Сыроварня корзина совмещена с оформлением: в одном окне выбирают доставку или самовывоз, ресторан, адрес, время и способ оплаты. Отдельного экрана оформления нет. Такое решение сокращает переходы между экранами; в UX-аудите проверяют, доступны ли нужные поля, видна ли итоговая сумма и сохраняются ли данные при изменении способа получения.

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

Сколько стоит UX-аудит и что входит в оценку

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

• Объём продукта. Один путь оформления и несколько ролей в личном кабинете требуют разного исследования.
• Платформы. Сайт, мобильный браузер и приложения проверяют по согласованной матрице.
• Методы. Экспертный разбор отличается по составу работ от исследования с участниками.
• Результат. Уточните формат отчёта, обсуждение рекомендаций и подготовку задач.

Сроки определяют после согласования состава работ и доступов. Услуга аудита UX/UI помогает выявить проблемные участки пути и подготовить рекомендации. Внедрение можно обсудить как редизайн или отдельные доработки. Разделение оценки позволяет видеть бюджет исследования и бюджет изменений.

Критерии выбора команды для аудита

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

Итог: отчёт, по которому можно действовать

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

Если нужен разбор пользовательского пути, начните с UX/UI-аудита. При вопросах о техническом состоянии дополните его аудитом приложения. Для согласования изменений подходит разработка технического задания. Описать задачу можно в форме обсуждения проекта.

Источники и методические материалы

Методы сверены 13 октября 2026 года. Пример карточки и рабочие категории приоритетов подготовлены для этой статьи; это учебные материалы, а не отчёты клиентов.

• NN/g: принципы взаимодействия с интерфейсом.
• NN/g: проведение экспертной оценки.
• NN/g: оценка серьёзности проблем.
• W3C: уведомления в формах.
• W3C: первичная проверка доступности.
• Яндекс Метрика: воронки сайта.
• AppMetrica: воронки приложения.
• FITTIN: редизайн АстМаркет и приложение Сыроварни.

Часто задаваемые вопросы

Что входит в UX-аудит сайта?

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

Чем UX-аудит отличается от тестирования с пользователями?

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

Можно ли провести UX-аудит без аналитики?

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

Как выглядит отчёт по UX-аудиту?

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

Сколько стоит UX-аудит приложения?

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

Повысится ли конверсия после UX-аудита?

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

Екатерина ЕгельскаяРуководитель отдела дизайна