Иногда проблема продукта не в том, что он не нужен, а в том, что им невозможно пользоваться.
Это история про рейдизайн (и немного рефакторинг) раздела управления облачными расходами в нашей платформе для управления затратами на ИТ-инфраструктуру «Клаудмастер». И сделали так, что вместо 2 минут клиенты стали проводить в разделе 10, используя его функции в полном объеме.
С чего всё началось
Изначально решение о создании раздела бюджетов с одной из ключевых фич — управлением бюджетами — мы принимали, опираясь на опыт успешных зарубежных ФинОпс-платформ, где такие инструменты уже доказали свою эффективность.
Однако на практике это сработало хуже, чем мы ожидали. Аналитика в Amplitude показала: пользователи заходят в раздел, но проводят в нем в среднем всего 2 минуты.
Раздел привлекал внимание, но не удерживал его. Первая реакция команды была предсказуемой: «Наверное, это никому не нужно». Но в продуктовой разработке это чаще всего заблуждение.
Ошибка №1: “Фича не используется = фича не нужна”
Мы решили не делать поспешных выводов и копнули глубже:
проанализировали текущие пользовательские пути;
детально изучили поведение в интерфейсе;
провели серию глубинных интервью.
Что мы узнали на интервью
Глубинные интервью с клиентами стали для нас главным источником инсайтов. Респонденты описывали свои трудности взаимодействия с разделом по-разному, но мы выделили три ключевых «боли»:
1. “Я не понимаю, как этим пользоваться”
Как создать бюджет?
Что дальше с ним делать?
Как отслеживать?
2. “Я не вижу, что происходит с деньгами”
Нет нормальной визуализации;
нет прогноза;
нет ощущения контроля.
3. “Слишком много всего и все разбросано”
Чтобы сделать простую вещь, нужно:
открыть несколько экранов;
собрать данные вручную;
держать всё в голове.
Инсайт
В какой-то момент стало ясно: мы сделали функциональность, но не сделали сценарий. В руках пользователей оказался инструмент, но без понимания — а что с ним дальше делать, как и для чего он.
Что решили менять
Мы не стали “чуть править UI” текущего раздела. Мы пересобрали весь подход и логику раздела.
Что было нужно:
Консолидация: вся информация о бюджете должна отображаться на одном экране.
Наглядность: статус бюджета (норма/перерасход) должен считываться мгновенно.
Упрощение: очевидное подсвечивание ключевых действий — создание бюджета, работа с дочерними центрами затрат и т.д.
Пересборка логики
Перед дизайном мы сделали скучную, но важную вещь:
разложили сценарии использования;
создали новый user flow;
убрали лишние шаги в каждом сценарии.
И только после этого пошли в интерфейс.
Что изменилось в дизайне
Нам нужно было исправить:
разрозненность экранов и слабую визуализацию;
отсутствие гибкого распределения ресурсов по заданным правилам и детализации затрат.
Что мы сделали:
Гибкое распределение ресурсов по центрам затрат с использованием правил (по каким критериям объекты и привязанные к ним ресурсы должны быть добавлены в центр затрат);
детализированный учет расходов на всех уровнях;
централизованный контроль затрат по всем подключениям в корневом центре;
возможность создания дочерних центров для точного разделения расходов;
актуальная и регулярно обновляемая информация по затратам.
Ошибка №2: сначала хотели “улучшить форму”
Изначально мы думали: “Ну давайте просто сделаем форму попроще”.
Но быстро поняли: проблема не в количестве полей, а в смысловой модели раздела. Пока мы не пересобрали бы логику представления данных, никакой дизайн не спас ситуацию.
Проверка
После дизайна мы не пошли сразу в разработку, а снова обратились к опыту наших пользователей:
провели серию UX-тестов;
прогнали пользователей по критическим сценариям;
зафиксировали , как быстро человек находит ответ на вопрос: «Сколько я потрачу на ИТ-инфраструктуру к концу месяца?»
Результаты тестов: количество вопросов к функционалу со стороны пользователей сократилось. Пользователи наконец «увидели» свои деньги и почувствовали контроль над ними.
Было: ~2 минуты (поверхностный осмотр и уход).
Стало: ~10 минут (глубокая работа с аналитикой).
Показатель вырос в 5 раз. И это не означает, что интерфейс стал медленнее. Наоборот, пользователи перестали тратить время на борьбу с UI и начали использовать инструмент по назначению — для полноценного финансового анализа и планирования.
Главный вывод
Самое важное в этом кейсе: если фичей не пользуются — это почти всегда UX-проблема. Виноваты не пользователи, а интерфейс не объяснил, что делать.
Что реально сработало:
интервью (а не догадки);
работа со сценариями;
упрощение, а не добавление;
визуализация вместо текста.
Этот кейс не про редизайн. Он про то, что: UX — это не про кнопки, а про понимание. И если пользователь не понимает систему — он просто не будет ей пользоваться.
