https://www.semrush.com/siteaudit

Роль: Senior UX Designer|Individual Contributor

Зона ответственности: вела UX-направление отчёта от исследования проблемы и концепции MVP до развития зрелого продукта.

• Определяла структуру пользовательского опыта и ключевые сценарии.
• Переводила результаты исследований в продуктовые гипотезы и приоритеты.
• Проектировала информационную архитектуру, интерфейсы и UX-тексты.
• Проверяла решения через usability-тестирование и продуктовую аналитику.
• Совместно с Product, Engineering, QA и Research развивала отчёт на протяжении нескольких итераций.

Результат

19% → 34%
Adoption отчёта среди платных пользователей

54% → 91%
Task Success Rate

№ 1 из 8
По просмотрам среди тематических отчётов Site Audit

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

1 Diagnose [Что не так?]
Сводный статус сайта через знакомую пользователям Google-модель Good / Needs Improvement / Poor.

2 Prioritise [С чего начать?]
Мультистраничный анализ и сортировка позволяют быстро найти страницы, которые требуют внимания.

3 Understanding [Почему это происходит?]
Детализация метрик и проблем помогает понять причину и масштаб проблемы, а не просто увидеть плохой статус.

4 Fix [Как исправить?]
How to Improve переводит проблему в конкретную рекомендацию для разработчика.

5 Track [Что изменилось?]
История аудитов и trend charts и дельта метрик позволяют увидеть результат после изменений, не дожидаясь 28 дней обновления данных GSC.

Задача: снизить порог входа в Core Web Vitals для широкой аудитории на этапе бета-запуска. Спроектировать виджет главной страницы, который переводит метрики в понятные гипотезы.

Ограничение: данные только по главной странице, жесткий дедлайн.

Решение: простые карточки метрик с цветовой индикацией Google + тултипы с расшифровкой в духе «возможно, проблема в hero-изображении» вместо сухого LCP 4.5s.

Результат: проверка спроса минимальным ресурсом. Выпустили вовремя, заняли нишу, получили реальные данные об использовании и развернутую обратную связь с запросом.

Ограничение: фидбек после беты: «проблемы на посадочных страницах, а главная чистая».

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

Решение: общий скор по 10 страницам на основе ILR, сортируемая таблица динамики, collapsible-детали Lighthouse, модалка ручного выбора URL, переключатель mobile/desktop.

Результат: данные реальных пользователей сместили приоритеты с главной страницы на трафикогенерирующие.

Юзабилити тестирование и обработка фидбека подсветили, что пользователи не всегда согласны с ранжированием 10 страниц по ILR и хотели бы сами выбирать, что включить в скоуп.

Задача: Дать пользователю самостоятельно выбирать 10 страниц для ILR-ранжирования вместо автоматического отбора.

Решение: предоставить возможность выбирать 10 страниц самостоятельно в модальном окне, валидация и понятные статусы обработки.

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

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

Нужно было связать весь сценарий в единый цикл:
Аудит → приоритет → рекомендация → исправление → повторная проверка

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

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

How to Improve
Каждая проблема сопровождается понятным объяснением и рекомендацией по исправлению. Технические данные переводятся в действие, которое можно передать разработчику.

Анализ затронутых страниц
Из рекомендации можно перейти к страницам, на которых обнаружена проблема, и понять её масштаб.

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

Что изменилось: отчёт стал не просто способом увидеть состояние Core Web Vitals, а рабочим инструментом для цикла:
найти проблему → определить приоритет → передать задачу → исправить → проверить результат

Для отчёта Core Web Vitals подготовила спецификации по веб-доступности в соответствии со стандартами WCAG 2.2 AA. Работа стала частью масштабной инициативы по accessibility: Site Audit первый среди Core-продуктов начал перестройку под требования A11y в условиях legacy-кода.

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

Совместно с командой мы разделили работу на два направления:

• Краткосрочное: ручные UX- и accessibility-исправления в рамках сроков проекта.
• Системное: переход на React-компоненты с поддержкой accessibility на уровне дизайн-системы и реализации.

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

В результате внедрения веб‑доступности в Site Audit от Semrush удалось снизить количество критических ошибок WCAG на 75%, устранить все блокирующие проблемы, выявленные пользователями ассистивных технологий, и сократить время отклика страниц для экранных читателей более чем на 30%. Это привело к росту оценки AUS (Accessibility Usability Scale) по всем ключевым технологиям: Screen Reader — с 63 до 82, Magnification — с 38 до 65, а доля пользователей, готовых рекомендовать продукт, увеличилась почти вдвое.

Качественные usability-тесты (n=23) подтвердили отказ от сырых миллисекунд в пользу лейблов. Количественная аналитика показала:

• Отчет стал № 1 по просмотрам среди 8 тематических блоков.
• Доля платных пользователей Site Audit, которые открывали отчёт и использовали его в рамках сценария аудита, выросла с 19% до 34% между beta-релизом и 2024 годом.
• Недельный retention отчёта: 16,8% на первой неделе против 13,4% у Crawlability; стабилизировался на 24−25% ко второму месяцу.
• Paywall конверсионность отчета: +18% к подписке, +15% апгрейдов Pro→Guru.
• Task Success Rate с первого релиза к полноценной версии вырос с 54% до 91%.
• После релиза общий NPS Site Audit вырос на 43 п.; показатель отражает динамику продукта в целом и не может быть полностью отнесён только к Core Web Vitals Report.

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

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

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

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