Спор о том, как должен выглядеть интерфейс, редко решается аргументами. Он решается данными: что люди на самом деле делают на странице, где останавливаются, куда не доходят и на каком шаге закрывают вкладку. Аналитика в проектировании интерфейсов нужна не для отчётов, а для того, чтобы список правок был обоснован, а после изменений можно было сказать, стало лучше или хуже. Разбираем, какие данные мы собираем, как их читаем и что с ними делаем на практике.
С каких вопросов начинается работа
Данные бесполезны, пока к ним не задан вопрос. Поэтому перед подключением любых инструментов мы формулируем, что именно хотим узнать. Типичный набор вопросов на старте:
- Каким путём человек доходит до целевого действия и сколько шагов на этом пути.
- На каком шаге теряется больше всего людей и что происходит на этом шаге.
- Отличается ли поведение на мобильном телефоне от поведения на компьютере.
- Какими разделами и функциями не пользуются вовсе.
- Где люди возвращаются назад, повторяют действие или пользуются поиском по сайту.
Из этих вопросов складывается схема измерений: какие события отмечать, какие шаги считать воронкой, какие сегменты сравнивать.
Количественные данные: что показывают цифры
Количественная часть отвечает на вопрос «сколько и где». Основной источник — система веб-аналитики с настроенными событиями. Важна не установка счётчика, а разметка: пока клики по кнопкам, отправки форм, открытия модальных окон и шаги оформления не отмечены отдельными событиями, воронку построить не на чем.
Что мы обычно смотрим:
- Воронку по шагам. Сколько людей дошло до каждого шага и где обрыв. Один шаг с провалом важнее, чем общая конверсия.
- Разбивку по устройствам. Значительная часть проблем интерфейса видна только на узком экране.
- Поведение внутри формы. Какие поля люди заполняют, какие пропускают, на каком поле останавливаются.
- Внутренний поиск. Запросы, которые люди вводят в поиск по сайту, прямо показывают, чего не хватает в навигации.
- Возвраты и повторы. Многократное нажатие одной кнопки почти всегда означает, что интерфейс не дал обратной связи.
Качественные данные: что показывают люди
Цифры говорят, где проблема, но не говорят почему. Причину дают наблюдения. Мы используем записи сессий и карты кликов, чтобы посмотреть на конкретные сценарии, а затем проводим короткие юзабилити-тесты: человеку дают задачу и просят выполнить её вслух, не подсказывая.
Отдельный, почти бесплатный источник — обращения в поддержку и вопросы менеджерам. Повторяющийся вопрос клиента почти всегда указывает на место, где интерфейс не объяснил очевидное. Мы просим выгрузку таких обращений в самом начале проекта: она экономит недели наблюдений.
Как мы связываем сигнал и решение
| Что видим в данных | Возможная причина | Как проверяем и что делаем |
|---|---|---|
| Обрыв на шаге оформления | Слишком много обязательных полей или непонятное требование | Смотрим записи сессий, сокращаем поля, показываем формат ввода |
| Повторные клики по одной кнопке | Нет отклика на действие, человек не понял, что оно принято | Добавляем состояние загрузки и подтверждение |
| Высокая доля выходов с карточки товара | Не хватает сведений для решения: цена, наличие, сроки | Опрос менеджеров, добавление недостающих данных, повторный замер |
| Активный внутренний поиск по разделу | Раздел нельзя найти через меню | Пересобираем навигацию по частоте запросов |
| Разница между мобильным и десктопом | Элемент не помещается на экран или перекрыт | Проверяем на реальных устройствах, правим вёрстку |
| Функцией не пользуются | Она не нужна либо спрятана | Проверяем на тесте: если не нужна, убираем и не поддерживаем |
| Быстрый возврат назад из раздела | Ожидание от названия раздела не совпало с содержанием | Переименовываем, проверяем на карточной сортировке |
Сравнительные проверки и их пределы
Сравнительное тестирование двух вариантов интерфейса — хороший инструмент, но он подходит не всем. Ему нужен поток: на сайте с небольшим числом целевых действий в месяц различие между вариантами не отделится от случайных колебаний, и вы получите красивый отчёт без смысла.
Что мы делаем, когда трафика мало:
- Проводим юзабилити-тесты на небольшой группе. Грубые проблемы навигации видны уже на первых участниках.
- Меняем один заметный элемент и сравниваем достаточно длинные периоды до и после, учитывая сезон и рекламную активность.
- Опираемся на промежуточные показатели: доля дошедших до формы, доля начавших заполнение, число ошибок при отправке. Их набирается больше, чем заявок.
Какие показатели мы держим на контроле
Для интерфейса важны не только конверсии. Мы обычно ведём небольшой набор:
- Доля успешно завершённых сценариев из числа начатых.
- Число шагов и время до целевого действия.
- Частота ошибок валидации в формах и повторных отправок.
- Доля обращений в поддержку по вопросам, связанным с навигацией.
- Скорость появления основного содержания и устойчивость вёрстки при загрузке: медленный или прыгающий интерфейс портит любые метрики.
Ошибки, которые обесценивают аналитику
- Считать всё подряд. Десятки отчётов, которые никто не открывает, вместо пяти показателей, привязанных к решениям.
- Смотреть только средние значения. Среднее время на странице скрывает и тех, кто ушёл сразу, и тех, кто не смог разобраться.
- Делать выводы по неделе. Недельные колебания трафика и рекламы легко принять за эффект правки.
- Менять несколько вещей сразу. Потом невозможно понять, что сработало.
- Не проверять разметку. Событие перестало отправляться после релиза, цифры упали, а интерфейс ни при чём.
Как это выглядит на проекте
Обычный цикл занимает несколько недель и повторяется. Сначала мы описываем сценарии и настраиваем события, затем собираем данные и наблюдения, формулируем гипотезы и раскладываем их по цене реализации и ожидаемому эффекту. Дальше берём в работу верхние, вносим изменения по одному и через контрольный период сравниваем показатели. То, что не подтвердилось, откатываем без сожалений — это нормальный результат, а не неудача.
Если нужен взгляд со стороны
Мы начинаем с разбора сценариев и данных, которые уже собираются, и показываем, где интерфейс теряет людей. Дальше проектируем и проверяем изменения. Посмотрите, как устроено проектирование веб-интерфейсов, и расскажите, какой сценарий на вашем сайте вызывает больше всего вопросов.
На проекте это отдельный этап: проектирование интерфейсов — сценарии, прототипы и проверка на живых пользователях.
