Редизайн модуля создания офферов

PM + Product Designer в проекте редизайна ключевого флоу B2C/B2B SaaS-биллинга. Один переиспользуемый компонент для восьми модалок, цикл публикации лимитов – с месяца до спринта и сокращение времени на выполнение задач.

Контекст

Продукт – подписочный B2C/B2B SaaS-сервис. Отдел биллинга состоял из четырёх команд:

1. процессинг и управление платежами
2. подписки и офферы
3. управление лимитами
4. внешний биллинговый кабинет пользователя.

Я работал с первыми тремя из четырёх команд. В тесном взаимодействии с дизайнером из четвёртой команды выстраивал общие процессы там, где зоны ответственности пересекались.

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

В какой-то момент бизнес дал добро на разработку нового биллинга – более гибкого, способного подстраиваться под быстро меняющиеся потребности. Это стало основным проектом департамента, в рамках которого и существовал мой проект с редизайном модалки создания офферов.

Проблема

Модалки работали на legacy коде. Любые изменения требовали огромных затрат времени разработчиков, поэтому цикл публикации новых лимитов на прод занимал около месяца.

С точки зрения UX проблема была острее всего у sales-менеджеров. Офферы они создавали как во время звонка с клиентом, так и после – часто в большом количестве за один рабочий день. Список насчитывал более 100 лимитов и растягивался на 8–10 экранов 14 дюймов”. Нужный лимит искали через Ctrl+F. После его включения нужно было скроллить вниз – там появлялись настройки. В сценарии на звонке это нарушало ритм разговора, а в офлайн-режиме – замедляло работу. Особенно когда пользователь просил добавить в подписку много разных лимитов.

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

Моя роль

В рамках основного проекта нового биллинга задачи распределялись между командами, и я вызвался курировать проект редизайна модалки как PM. Это значило совмещать две роли одновременно.

Как Project Manager:

• Еженедельная отчётность перед двумя стейкхолдерами – Head of Engineering и Head of Product
• Управление своей командой (fullstack + frontend), при этом поддерживал коммуникацию с тремя другими командами департамента – информировал об изменениях, которые могли затронуть их подсистемы
• Планирование спринтов и контроль приоритетов – выравнивание технических решений с бизнес-целями, без ухода в избыточную сложность.

Как Product Designer:

• Первичное исследование и формирование User Journey Map – впервые задокументированной для всех модалок
• Проектирование нескольких вариантов решения, итерационное тестирование на интерактивных прототипах
• Передача разработке финального решения через код прототипа, поддержка пользователей после запуска

Исследование

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

Охват:

Разные группы взаимодействовали с модалкой по-разному:

• sales создавали и редактировали офферы (14 человек)
• customer support работал в режиме просмотра (9)
• PO/PM/dev – редко и ситуативно. (6)

Это стало основой для сегментации при тестировании.

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

В ходе интервью я параллельно составлял User Journey Map – она не существовала до этого момента ни в каком виде. Карта помогла работать с приоритетами и держать фокус на самом важном, а так же помогла при последующем ручном тестировании.

Процесс

1. Фокус и ограничения

Полный редизайн и техническая переработка заняли бы слишком много времени и потребовало бы от пользователей переучиваться с нуля. Я намеренно сузил список проблем до одной критической – компактности и структуры списка лимитов. Параллельно принял решение сделать компонент переиспользуемым: одна реализация должна была покрыть все 8 модалок с разной логикой.

2. Дизайн-решение: компонент поверх Intergalactic DS

Новый список лимитов разрабатывался на React + Intergalactic дизайн-система Semrush. Проектировался именно компонент списка, который будет встраиваться в существующие окружения. Остальная модалка оставалась на legacy стеке. Я использовал DS как основу, но визуальную модель и логику поведения проектировал под конкретную задачу.

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

Три ключевых принципа компонента:

• Список как управляемая структура: поиск + явные состояния каждого лимита (добавлен, недобавлен, недоступен) вместо бесконечного однородного скролла
• Прогрессивное раскрытие: строка по умолчанию – только название и статус; настройки появляются при включении
• Явные зависимости и иерархия: лимиты сгруппированы в родитель-дочерние связи там, где они существуют; недоступные получили визуальный статус с объяснением причины в интерфейсе

Финальное решение для списка лимитов.

3. Интерактивный прототип (Svelte + Tailwind)

Тестирование на статичных макетах в Figma не дало бы нужной точности: нужно было реально взаимодействовать с длинным динамическим списком чтобы видеть разницу. Я самостоятельно собрал рабочий прототип – взял базовый HTML с существующей страницы и реализовал новую модель списка на Svelte + Tailwind.

Поверх прототипа встроил три кастомных инструмента замера:

• Таймер – запускалcя при старте задачи и останавливался при завершении; это давало точное время выполнения без наблюдательского эффекта
• Карта кликов – показывала, куда пользователи нажимают, где теряются и что игнорируют
• Карта скролла – показывала порядок просмотра и помогала проверить, правильно ли выстроена очерёдность элементов

Прототип публиковался как статическая страница в GitLab Pages и отправлялся участникам до сессии – на интервью они сразу работали с реальным интерфейсом.

4. Итерации

Я тестировал 3 варианта компоновки. Первые два получили схожий фидбэк: список стал немного компактнее, но информация по-прежнему было много и она была неочевидной – настройки каждого лимита занимали место независимо от того, нужны ли они сейчас.

На третьей версии добился нужного баланса: в исходном состоянии лимит показывает только название и статус, настройки появляются только после включения. На первом экране стало видно 3–8 упорядоченных лимитов в зависимости от состояния, против 10-15 тесно скученных ранее.

Первая версия

Часть обнаруженных проблем

• Основной проблемой версии было то что плашку настроек вообще не замечали и не знали как редактировать параметры лимита
• Кроме этого сами лимиты занимали много места

Вторая версия

Часть обнаруженных проблем

• Лимиты с параметрами внутри карточки лимита - сьедали место по вертикали
• Не было места встроить ручной ввод значения количества, а без этой возможности время в части задач увеличивалось т.к приходилось долго кликать чтобы набрать нужное количество

Доработки

После того как финальная структура модуля была определена. Я доработал логику необходимую для работы в других модалках.

Эту логику я держал в голове и набросках в Figma при проектировании общего модуля списка.

Например в модалке редактирования пользовательской подписки и лимитов нужна была возможность оставлять комментарии для каждого редактируемого лимита. Cделать одно поле с комментарием для всех, было технически трудозатрано.

Старая версия

Модкалка просмотра и редактирования подписки пользователя со всеми лимитами в этой подписке.

Новая версия

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

5. Передача разработке

Разработчики получили интерактивный прототип с кодом – большая часть логики состояний уже была реализована и проверена на пользователях. Это позволило сразу передать рабочую реализацию вместо описания поведения текстом. Полную документацию состояний и edge-cases я закончил оформлять уже после разработки, а не до – это сэкономило время на передаче дизайн-артефактов. Один дизайн компонент был интегрирован во все модалки, заменив разрозненные legacy-реализации.

Результаты

Продуктовый impact

Пользовательский impact

~70% участников финального тестирования выполняли задачи уверенно и укладывались в целевое время. 30% отметили непривычность – без критики к функциональности, просто смена их привычного паттерна.

Базу для сравнения я собирал заранее – замерял время вручную на старом интерфейсе и получал данные от самих пользователей, некоторые из которых знали своё среднее время на задачу. Это дало возможность сравнивать показатели, а не просто оценивать “лучше/хуже” субъективно.

Исследовательский процесс

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

После запуска я месяц работал в роли поддержки: собирал фидбэк, записал видеогайд, помогал другим командам разобраться в новой логике.

Вызовы и выводы

Сдвиг сроков

Через пять месяцев работы выяснилось, что первоначальная оценка была неточной – скрытые зависимости в legacy-коде вскрылись только в процессе, потому что глубокого технического исследования в начале не было. Сроки сдвинулись на три месяца. Мне нужно было объяснить ситуацию Head of Engineering и Head of Product, обосновать новый срок и сохранить доверие – от нашего таймлайна зависели другие команды. Это был самый сложный момент проекта. После переоценки уложились без сдвигов.

Баги после запуска

После релиза нашли около 4 багов – часть взаимосвязей между лимитами не была учтена, так как некоторые тесты отсутствовали и документации по логике не было. Команда быстро исправила, пока контекст по коду был свежим. Я выступал связующим звеном: собирал обратную связь от пользователей и помогал расставлять приоритеты.

Ключевые выводы

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