Сбер (B2E) — дизайн-система канала как инфраструктура: портал, процессы качества и конструкторы

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

Главное

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

Фокус: масштабирование под десятки/сотни команд, портал-витрина и база знаний, поддержка через бот+тикеты, монорепозиторий (компоненты как отдельные библиотеки), двухэтапные ревью (UX/UI), архивирование макетов, контроль реализации перед релизом, рейтинг качества команд (UXcorom), токенная модель (родительские значения → токены), конструкторы workflow и автоматизация ревью.

Контекст: продукт вырос с 2021 года; к концу 2023 года подключилось ~70 команд, затем >130. Дизайн-система развивалась через несколько «скачков» и была пересобрана под масштаб и внешних потребителей внутри банка.

Контекст

1. Контекст: от «кастома» к системному решению

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

Ключевой поворот связан с превращением продукта в «канал»: к платформе стали подключаться десятки команд, затем счёт пошёл на сотни. Это резко повысило требования к документации, витрине и процессам поддержки.

Позиционирование и цели

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

Состав системы

5. Команда и модель развития: центр + контрибьюторы

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

Процессы развития

4. Техническая стратегия: монорепозиторий и релизная гибкость

Один из отличительных выборов — архитектура монорепозитория: каждый компонент является отдельной библиотекой. Это позволяет выкатывать обновления точечно (например, обновить только кнопку), а общий «пак» обновлять по релизному циклу для удобства установки. Такой подход снижает издержки на обновления и ускоряет внедрение изменений в командах.

Документация

3. Архитектура системы: аудитории, портал, поддержка

Архитектура описывается через три аудитории: дизайнеры, разработчики и бизнес (менеджеры, аналитики). Под дизайнеров собираются библиотеки, гайдлайны, шаблоны, workflow и банк реализованных решений. Под разработчиков — репозиторий и витрина. Для бизнеса портал становится способом «пощупать» компоненты и понять, какие ресурсы и ограничения потребуются.

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

9. Документация: «живые гайдлайны», понятность и тестирование на внешних

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

Контроль качества

6. Контроль качества: двухэтапные ревью, архив и сверка перед релизом

Контроль качества строится как процесс, а не разовая проверка. Ревью проводится в два этапа: сначала UX review (сценарий, целостность пути, ограничения), затем UI review (соответствие гайдлайнам, токенам и правилам).

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

Перед релизом проводится сверка «согласованные макеты ↔ реализация»: команда сравнивает скринкаст/прод с макетами и фиксирует дефекты.

7. UXcorom: рейтинг качества команд и «карта здоровья» канала

Для управления качеством в масштабе внедрён отдельный процесс, где дефекты фиксируются на независимой доске. Каждый дефект имеет вес (по формуле тяжести нарушения), веса влияют на рейтинг команды. Команды видят количество и тяжесть дефектов и могут приоритизировать исправления; бизнес видит объективный сигнал по качеству.

11. Ошибки и уроки: путь через итерации и «бюрократия как спасение»

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

Масштабирование и внедрение

2. Цели: скорость, консистентность, снижение затрат и масштабируемость

Цели дизайн-системы описываются как операционные и измеримые: сократить время сборки типовых экранов, снизить трудозатраты дизайнеров и разработчиков, повысить консистентность (особенно при большом числе команд), обеспечить масштабируемость под стратегию на несколько лет вперёд и подготовиться к потенциальным изменениям вроде white label и выхода на новые платформы.

Отдельно подчёркивается, что дизайн-система рассматривается как финансово оправданный продукт: её защищают перед бизнесом через сравнение стоимости «жизни без системы» и стоимости разработки/поддержки системы.

8. Токены и принципы: гибкость, white label, простота и постепенное раскрытие сложности

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

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

Уникальные практики и «фишки» кейса

1. Гайды как копируемые экраныЧасть гайдлайнов превращена из «текста с картинками» в готовые экраны Figma: скопировал, заменил название — и у тебя валидный шаблон. Снижает нагрузку на ревью и помогает командам без дизайнеров (аналитики, PM частично закрывают роль).

2. Workflow-конструктор своими силами за 3 месяцаDrag-and-drop конструктор: пользователь собирает экран из заранее закодированных блоков, меняет названия и выгружает в PDF + заготовку вёрстки (без логики). Хранение — прямо в браузере, без бэкендеров. 22 пилота, 12 проектов в проме — окупилось.

3. UXcorom — рейтинг качества командДашборд, где подключены все команды-разработки и бизнес. Плохой балл — блокировка релиза до исправлений. Превращает DS в не просто «витрину», а механизм давления на качество.

4. Монорепозиторий: каждый компонент — отдельная библиотекаВыкатывать обновления можно точечно, по одному компоненту, а раз в релизный цикл — весь пак разом. Гибкость: команды-потребители обновляются в своём темпе, DS не блокирует всех одним релизом.

5. Банк реализованных решенийКоманды приносят свои решения «контрибьюторами»: файл копируется в общий банк, становится доступен остальным. Взаимовыгодно — пользователь получает проверенное решение, DS экономит на разработке.

6. Двухэтапное ревью: UX review + UI reviewСначала UX-этап: смотрят суть сценария, зачем он и для кого. Потом UI-этап: детали, консистентность, соответствие DS. Две разные задачи — две разные встречи.

7. Портал с ботом поддержки из контекстаК чату поддержки подключён бот: если из контекста считывает, что ответ у него есть — закрывает вопрос сам, не беспокоя команду. Разгружает поддержку на типовых вопросах.

8. AI-reviewer как следующий шагВ разработке — агент, который принимает макет и прогоняет его по правилам DS, выдавая замечания. Идея: убрать рутинное ревью на 80% типовых ошибок, освободить ревьюеров для сложных кейсов.

9. «Бюрократия решает»Уроки роста: при масштабе правила, регламенты и фиксация — не враг, а спасение. Без них знания теряются, архитектура разваливается, одни и те же дискуссии повторяются по кругу.

Выводы и принципы

12. Что можно перенять другим командам

Избранные цитаты