Pulse UI

О продукте и контексте

Дизайн-система Pulse UI (в ранних версиях — Impulse DS), на которой построена HR-платформа «Пульс» в Сбере, охватывает более 65 сервисов. Она закрывает сценарии от промо-лендингов до высоконагруженных рабочих интерфейсов: таблиц, аналитических дашбордов и командных календарей.

Ключевая архитектурная особенность Pulse UI — гибкая настройка тем. Через семантические дизайн-токены и связи между уровнями палитры система позволяет менять цветовую схему, типографику, скругления и другие визуальные параметры без пересборки продуктовых экранов — под разные бренды и пользовательские предпочтения.

Роль

Design System Lead (Сбер)

Мой вклад

Аудит и исследование · Стратегия и планирование · Проектирование и разработка · Внедрение в продукты · Поддержка и развитие

Команда

Владелец продукта · Дизайнер (×2) · Frontend-разработчик (×2)

Масштаб

65+ сервисов платформы «Пульс» · 50+ продуктовых команд

Период

2021 — 2025 (ключевой срез метрик — Q1 / 2024, результаты за 1,5 года)

Что нужно было полечить

На старте системной пересборки вокруг библиотеки накопилось шесть узких мест, которые тормозили и команду ДС, и продуктовые команды платформы:

• Много кастомных компонентовПродуктовые команды собирали собственные локальные версии кнопок, модалок и таблиц вместо переиспользования общей библиотеки.
• Нет налаженного производственного процессаОтсутствовали прозрачные этапы исследования, оценки, тестирования, ревью и демо перед выкаткой новых и обновлённых компонентов.
• Нет долгосрочной стратегии развитияСистема жила в режиме реактивного закрытия точечных тикетов без единого плана развития под цели бизнеса и будущие сервисы.
• Команды не понимают ценности дизайн-системыПродуктовые дизайнеры и разработчики воспринимали библиотеку как внешнее ограничение, а не как общий инструмент ускорения.
• Не хватает нужных компонентовВ библиотеке отсутствовали паттерны для сложных сценариев, и не было критериев, что должно жить в ядре ДС, а что — оставаться локальным.
• Расхождения дизайна с разработкойКомпоненты в Figma и в Storybook расходились по состояниям и API; дизайнеры брали в макеты элементы раньше, чем они появлялись в коде.

Как решали проблемы

1. Аудит библиотеки и сокращение кастома

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

2. Перезапуск производственного пайплайна

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

3. Долгосрочная стратегия и открытый бэклог

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

4. Разделение «ядро vs локальное» и закрытие гэпов

Собрали полный список недостающих компонентов по запросам команд и разделили его на две группы: универсальные примитивы и паттерны, которые идут в общую библиотеку, и узкоспецифичные продуктовые блоки, которые остаются локальными. Провели гэп-анализ между Figma и кодом, разметили все расхождения и синхронизировали выпуск обновлений библиотеки и Storybook — чтобы дизайнеры не использовали в макетах компоненты, которых ещё нет в разработке. Для поддержания синхронности запустили регулярный процесс проверки DS Check up.

5. Обучение и вовлечение команд

Запустили серию обучающих встреч, практических сессий и регулярных митапов для дизайнеров и разработчиков со всей платформы: разбирали устройство библиотеки, планы команды и правила сборки экранов.

Токены, основы и спецификации компонентов

Когда бизнес поставил задачу поддерживать смену цветовых тем в интерфейсе платформы, нам пришлось полностью переосмыслить работу с цветом и семантикой. Мы разделили базовую палитру (10 цветовых рядов в шкале 10–100 плюс дополнительные градиенты) и функциональный слой semantic tokens (bg-primary, text-secondary, интерактивные состояния и токены иллюстраций) для светлой и тёмной тем.

Мы разработали пошаговый план миграции в макетах и в коде. Сложнее всего переезд давался продуктовым командам с большим числом экранов: вместе с ними и за счёт плотной поддержки мы перевели на новые цветовые токены более 50 команд за 4 месяца.

Параллельно формализовали все базовые уровни системы в версии 1.0.0 со сквозными ссылками на Storybook и гайдлайны:

• Тени (shadows): четыре уровня высоты (small для карточек, medium для поповеров и дропдаунов, large для модалок и offcanvas, extraLarge для drag & drop) отдельно для светлой и тёмной темы;
• Типографика: иерархия заголовков на SB Sans Display и наборного текста на SB Sans Text по стандарту контрастности WCAG 2.1 AA;
• Сетка и отступы: правила 12-колоночной сетки для разрешений от 1024dp (планшеты) до 2560dp с учётом свёрнутого и развёрнутого сайдбара, а также единый пространственный ритм на базе модуля 4px (0.5rem).

Каждый сложный компонент документировался так, чтобы у дизайнера и фронтенд-разработчика не оставалось серых зон при сборке экрана: от анатомии и сценариев «когда использовать / когда не использовать» до адаптива, вариантов шапки и подвала и поведения при внутреннем скролле.

Что ещё было сделано

• Описали и внедрили процесс контрибьюта от продуктовых командНебольшой командой ядра (2 дизайнера и 2 фронтенд-разработчика) невозможно закрыть все продуктовые запросы на 65+ сервисов. Мы описали прозрачный процесс контрибьюта: продуктовые команды сами предлагают и разрабатывают новые компоненты, чинят баги и вносят доработки в общую библиотеку.
• Разработали и запустили процесс контроля качества Design GateВнедрили обязательный контур проверки макетов перед передачей в разработку и сверстанных экранов перед релизом. Со временем это направление выросло и выделилось из дизайн-системы в отдельную команду, так как стало критичным контуром качества для руководства платформы.
• Собрали прикладную документацию для командОписали жизненный цикл компонента от идеи до депрекейта, гайды по сборке локальных компонентов, инструкции по миграции на новые семантические токены и правила прохождения ревью.
• Изменили отношение команд к дизайн-системеЗа счёт открытого бэклога, демо, обучения и контрибьюта продуктовые команды перестали воспринимать ДС как внешний барьер и стали активно участвовать в обсуждении архитектуры и развитии библиотеки.

Итоги и метрики (Q1 / 2024 — за 1,5 года)

Для оценки здоровья и эффективности дизайн-системы мы отслеживали три ключевых показателя: индекс удовлетворённости команд (CSI — Component Satisfaction Index), долю покрытия интерфейсов компонентами системы (Adoption) и долю кастомных решений в продуктах (Custom Usage).