Редизайн без метрики - дорогая перестановка пикселей

Начните не с макета, а с проблемы

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

Базовая линия: снимок до изменений

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

Выберите метрику по пользовательской задаче

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

Что измерять в usability-тесте

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

Эксперимент: проверяйте гипотезу, а не вкус

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

Технические метрики тоже часть редизайна

Новый визуальный слой может добавить тяжёлые изображения, шрифты, анимации и клиентский код. На мощном ноутбуке презентация летает, а на обычном телефоне страница прыгает и тормозит. Проверяйте Core Web Vitals, вес ресурсов, стабильность макета и доступность. Иначе редизайн улучшает портфолио команды, но ухудшает реальный опыт.

Практический пример: оформление заказа

Исходная проблема: пользователи мобильной версии часто бросают выбор доставки. Базовая линия показывает завершение 62%, медианное время четыре минуты и высокий поток вопросов о датах. Исследование обнаруживает, что календарь открывается ниже экрана, а стоимость меняется без объяснения. Команда ставит цель: увеличить успешное завершение без роста отмен и обращений.

Редизайн делает доступные даты видимыми, объясняет изменение цены и сохраняет выбор при возврате. В usability-тесте уменьшаются ошибки, пилот подтверждает более быстрое выполнение, а поэтапный запуск показывает рост завершения при стабильных отменах. Это кейс. Фраза «мы сделали календарь чище и современнее» - только описание макета.

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

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

Пятый способ - подменять результат выпуском. «Запустили новую дизайн-систему» означает, что команда закончила работу, а не что пользователю стало легче. Дизайн-система может снизить стоимость разработки, ускорить сборку экранов и уменьшить число несогласованных паттернов - вот измеримые эффекты. Без них остаётся дорогой каталог компонентов.

Что делать, если метрика не выросла

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

Как собрать доказательный кейс

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

Вывод KGAM

Редизайн без заранее выбранной метрики не обязательно бесполезен, но его польза не доказана. Красивый before/after показывает изменение формы. Доказательный кейс показывает изменение поведения, качества, стоимости или скорости. Это менее эффектно на первом слайде, зато намного честнее.