eXpress 2.0: редизайн B2B-платформы
Перезапустили B2B-платформу за 7 месяцев: переработали 1000+ экранов, провели исследование на ~800 и 792 респондентах, проверили решения на активных пользователях и сделали новый интерфейс точкой продаж продукта.
Контекст
eXpress — платформа корпоративных коммуникаций: чаты, звонки, конференции, контакты, настройки и связанные сценарии для крупных компаний.
На старте продукт уже был функционально сильным, но интерфейс не помогал раскрывать эту силу: часть возможностей терялась в навигации, визуальный уровень проигрывал привычным коммуникационным сервисам, а новые фичи становились дороже из-за накопленного хаоса в интерфейсе, макетах и коде.
Бизнес-проблема
Старый интерфейс начал мешать продукту в трёх местах одновременно: продажах, пользовательской ценности и стоимости развития.
Продажи
10+ демо / месяц
Проходили через сценарии чатов и звонков, поэтому первое впечатление от интерфейса напрямую влияло на восприятие продукта
20+ комментариев за квартал
От sales и клиентов касались устаревшего UI, сложности интерфейса или сравнения с конкурентами
Пользовательская ценность
Исследование показало, что часть проблем была не в отсутствии функций, а в том, что пользователи их не находили.
20% ответов
Содержали просьбы добавить функции, которые уже были в продукте
Стоимость развития
В продукте было 1000+ экранов. Если просто начать перерисовывать всё подряд, можно было зашить ошибки в сотни макетов, перегрузить разработку и получить красивый, но плохо работающий редизайн.
Гипотеза
Если пересобрать интерфейс через исследование, знакомые паттерны, Дизайн-систему и поэтапную валидацию, то продукт станет проще продавать, проще использовать и дешевле развивать.
-
1
Проще продавать: интерфейс будет выглядеть как современное коммуникационное решение
-
2
Проще использовать: пользователи начнут находить функции, которые раньше терялись
-
3
Дешевле развивать: новые фичи можно будет собирать на более гибком визуальном и техническом фундаменте
Дискавери
Сначала нужно было понять, что именно болит: внешний вид, навигация, сценарии или ожидания пользователей.
Мы не пошли сразу в отрисовку. Сначала подняли данные, провели опросы, посмотрели конкурентов и собрали гипотезы.
Пользовательские ожидания
Провели 2 опроса на ~800 и 792 респондентах и собрали качественные комментарии пользователей.
Конкуренты и привычные паттерны
Смотрели прямых и косвенных конкурентов: корпоративные мессенджеры, массовые коммуникационные сервисы, ВКС-продукты. Цель была не скопировать Telegram или Teams, а понять, какие паттерны пользователь уже знает и где их можно безопасно адаптировать в B2B-продукте.
Технические ограничения
Параллельно подключали разработку и техлидов. Нужно было заранее понять, какие идеи можно заложить сейчас, а какие будут слишком дорогими или рискованными.
Результат дискавери
-
1
Обновить UI до уровня знакомых коммуникационных паттернов
-
2
Пересобрать навигацию и иерархию, чтобы пользователи находили существующие функции
-
3
Заложить основу для Дизайн-системы и нового кода, чтобы следующие изменения стоили дешевле
-
4
Запускать изменения поэтапно, потому что резкий редизайн рабочего B2B-инструмента мог вызвать сопротивление
Критерии успеха
Цель минимум
- Пользователи понимают новые сценарии без долгого переобучения
- Ключевые функции становятся заметнее в интерфейсе
- Редизайн можно безопасно передать в разработку без большого числа спорных решений
Цель максимум
- Новый интерфейс становится точкой продаж продукта
- Продукт проще демонстрировать новым заказчикам
- Следующие фичи собираются быстрее за счёт Дизайн-системы и нового визуального фундамента
Технические требования
-
1
Не ломать привычные сценарии для текущих пользователей
-
2
Поддержать большой объём экранов и состояний
-
3
Разделить продукт на управляемые стримы, чтобы не вести редизайн одной бесконечной массой
-
4
Проверять спорные решения до разработки
-
5
Учитывать будущую Дизайн-систему и Storybook, чтобы дизайн и код не разъехались
Как организовали работу
Операционные процессы
Подробно в кейсе «Пересмотр процессов»
Дизайн-система
Подробно в кейсе «Дизайн-система»
Продуктовый трек
Здесь показываю, как мы исследовали, выбирали решения, валидировали их и доводили до релиза
Гипотезы и приоритизация
Гипотезы проверяли не как вкусовые варианты интерфейса, а как продуктовые ставки: что поможет продажам, пользователям и команде разработки.
Гипотеза 1
Если обновить UI до уровня привычных коммуникационных паттернов, продукт будет проще продавать и внедрять.
Почему верили: на демо продукт сравнивали с массовыми коммуникационными сервисами, а старый интерфейс создавал ощущение более тяжёлого решения.
Риск: слишком резкое обновление могло сломать привычный рабочий инструмент.
Что сделали: пошли через визуальный MVP и проверку нескольких направлений, а не через резкий «модный» редизайн.
Гипотеза 2
Если пересобрать навигацию и иерархию, пользователи начнут замечать функции, которые раньше терялись.
Почему верили: 20% ответов в исследовании содержали просьбы добавить функции, которые уже были в продукте.
Риск: можно улучшить видимость одних сценариев, но перегрузить интерфейс и ухудшить ежедневную работу.
Что сделали: разбирали сценарии по стримам, смотрели на частотность, важность и привычность паттернов.
Гипотеза 3
Если собрать редизайн на Дизайн-системе и новом коде, стоимость следующих изменений снизится.
Почему верили: 1000+ экранов невозможно поддерживать вручную без единого визуального и компонентного фундамента.
Риск: Дизайн-система могла стать отдельной «идеальной» задачей и начать тормозить редизайн.
Что сделали: собирали Дизайн-систему параллельно с редизайном: брали реальные паттерны из макетов и переводили их в компоненты.
Что не взяли в работу сразу
Мы не могли делать всё сразу, поэтому отсекали решения по трём критериям.
-
1
Даст ли это пользу пользователю?
-
2
Поможет ли это продажам и внедрению продукта?
-
3
Можно ли это реализовать без неадекватной стоимости разработки?
Что не брали в работу сразу
- Полностью новую навигационную модель — слишком рискованно для рабочего B2B-инструмента
- Слишком «модный» визуальный концепт — можно выиграть в картинке и проиграть в привычности
- Большие новые фичи вместо пересборки существующих сценариев — часть ценности уже была в продукте, но плохо находилась
Что взяли в работу
- Безопасное обновление визуального языка
- Пересборку навигации и иерархии в ключевых сценариях
- Постепенное масштабирование через стримы
- Дизайн-систему как основу для дальнейшей разработки
- Внутреннюю бету и дизайн-ревью, чтобы ловить проблемы до релиза
Решение
Визуальный MVP
По данным исследования, 80% пользователей используют ПК для ВКС, поэтому этот сценарий стал отправной точкой для визуального MVP.
Мы собрали 3 направления редизайна и проверили их на внутренней аудитории и лояльных пользователях.
В итоге выбрали не самый «модный», а самый безопасный путь: сделать интерфейс легче и понятнее, но не оторвать его от привычных сценариев.
Техническая валидация
На этапе гипотез подключали техлидов разработки. Это помогало отсекать слабые решения до того, как они попадали в макеты и начинали съедать время команды.
Где-то это помогало упростить решение. Где-то — наоборот, заложить новые возможности сразу, потому что разработке всё равно нужно было переписывать соответствующий код.
Так редизайн стал не отдельной дизайн-активностью, а совместной работой дизайна, аналитики и разработки.
12 решений
Отсекли до макетов как слишком дорогие или технически рискованные
18 идей
Упростили после обсуждения с разработкой
7 фич
Заложили сразу, потому что код всё равно переписывался
Масштабирование
После утверждения визуального направления мы начали масштабировать концепт на разделы продукта. Работали по стримам, чтобы не потеряться в объёме: чаты, звонки, контакты, настройки.
Параллельно собирали фундамент Дизайн-системы. Повторяющиеся решения не оставались просто кусками макетов — они превращались в компоненты, которые можно переиспользовать в следующих задачах.
Помимо основных сценариев, отдельно прорабатывали корнер-кейсы, чтобы у разработки не оставалось слепых зон.
Внутреннее бета-тестирование
После масштабирования новый дизайн проверяли на живых сценариях.
Это дало быстрый и честный фидбек по сценариям, которые сложно поймать на статичных макетах: частотные действия, раздражающие мелочи, непонятные статусы, спорные состояния.
Дизайн-ревью реализации
После передачи в разработку работа не заканчивалась. Мы сравнивали реализацию в коде с макетами и снимали расхождения до релиза: визуальный шум, отступы, состояния, компоненты, corner cases.
Результат
~90 часов / месяц
Сэкономили поддержке за счёт снижения однотипных вопросов по навигации
16 → 24%
Выросла конверсия из демо в пилот после обновления интерфейса
100 → 13%
Снизили долю sales-возражений про устаревший интерфейс на демо
-60% доработок
Снизили количество правок после реализации за счёт дизайн-ревью и компонентного подхода
Что стало лучше после редизайна
-
1
Продукт стало проще показывать новым заказчикам: интерфейс начал работать как аргумент в продаже, а не как место, которое нужно дополнительно объяснять
-
2
Скрытые функции стали заметнее: редизайн помог раскрыть ценность возможностей, которые уже были в продукте
-
3
Команда получила более гибкую базу для разработки: новые фичи стало проще собирать на готовых паттернах, компонентах и проверенных сценариях
-
4
Дизайн, аналитика и разработка начали раньше синхронизироваться по решениям, а не чинить спорные места на поздних этапах
Что я делала в этом кейсе
-
1
Переводила пользовательские проблемы в продуктовые гипотезы
-
2
Анализировала конкурентов и знакомые пользователю паттерны
-
3
Прорабатывала визуальные направления редизайна
-
4
Синхронизировала решения с аналитикой, разработкой и техлидами
-
5
Масштабировала концепт на ключевые сценарии и корнер-кейсы
-
6
Участвовала в бете и превращала фидбек в итерации
-
7
Проводила дизайн-ревью реализации перед релизом
Итог
Мы не просто обновили визуальный слой продукта. Мы провели редизайн как полноценный продуктовый перезапуск: через исследование, гипотезы, техническую проверку, MVP, поэтапное масштабирование и внутреннюю бету.
В результате eXpress получил новый интерфейс, который проще продавать, проще развивать и проще использовать. А команда получила не набор красивых экранов, а рабочий фундамент для следующих фич, Дизайн-системы и более предсказуемой разработки.