Альфа — дизайн-система как «единый продукт» в масштабе платформ и мультибрендовости

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

Главное

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

Фокус: архитектура масштабной дизайн-системы, синхронизация платформ (web/iOS/Android), процессы и команды, инструменты автоматизации, документация (портал), пресеты и мультибрендовость.

Контекст: дизайн-система развивается много лет (первые подходы — с 2014 года), проходила несколько «скачков» развития, но воспринимается как один непрерывно развивающийся продукт.

Контекст

1. Контекст: как начиналась дизайн-система и почему она стала «продуктом»

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

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

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

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

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

3. Архитектура: кор-уровень + ветки продуктов + инструменты

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

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

6. Команды и процессы: кор-команды, платформенные команды, инициативные группы

Масштаб системы требует многоуровневой организации команд. В интервью выделяются: кор-команды (full-time), отдельные команды под мобилку и под веб, «внутриплатформенные» команды, а также инициативные группы, которые подключаются на часть времени и развивают конкретные инструменты или направления. Процессы в целом опираются на Scrum, но адаптируются под специфику платформенного продукта: результат не заканчивается выпуском компонента — после релиза начинается поддержка и развитие.

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

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

5. Документация: портал как точка входа + связь с репозиториями

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

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

Синхронизация дизайна и кода

4. Принципы: синхронизация платформ и «единый источник правды»

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

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

7. Контроль актуальности в продуктах: инструмент сбора статистики + дашборды

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

9. Ошибки и тупики: роли, демократия и фиксация причин

В кейсе проговариваются типовые ошибки больших систем: рассинхрон между дизайном и разработкой даже на уровне договорённостей; отсутствие чётких ролей и зон ответственности; излишняя демократия в принятии решений; сопротивление формализации процессов. Отдельная практическая рекомендация — фиксировать «зачем» принято решение: без этого через 2–3 года команда повторяет цикл обсуждений и экспериментов.

В интервью несколько раз возвращаются к идее документации решений: записи помогают будущим командам не терять аргументацию и не «изобретать заново».

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

2. Цели: классика (скорость/консистентность/затраты), но в масштабе

Цели в зрелом периоде формулируются как типовые для больших систем: ускорение time-to-market, повышение консистентности и снижение затрат на разработку. Отдельно отмечается переход к «продуктовому» взгляду: система сопоставляется с бизнес-требованиями и метриками, появляется выделенная команда.

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

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

2. Конструкторы интерфейса на базе синхронизации дизайна и кодаЭкран можно собрать из реально реализованных компонентов, настроить параметры и увидеть результат в окружении платформ. Один JSON просматривается в iOS, Android и web одновременно — снижает разрыв между макетом и продом.

3. Автогенерация вёрстки из макетаЧерновая генерация вёрстки и описаний из Figma. Дизайнер видит, какие компоненты реально доступны, и сравнивает результат с ожиданиями. Экономит время на передаче «вот макет — вот контракт».

4. Уровневая архитектура: foundations → core → паттерны → продуктовые веткиТокены и ассеты как стилеобразующий минимум. Поверх — кор-компоненты для web и mobile. Поверх — паттерны и инструменты. Отдельно — продуктовые ветки: специфика развивается локально и при универсальности заезжает в общий кор.

5. Дашборд использования DS с бизнес-метрикамиИнструмент собирает статистику по коду: какие команды какие версии используют, насколько отстают от актуального. Дашборд рассматривается на уровне бизнеса — попадание в красную зону становится стимулом обновляться.

6. Портал как единая точка входа + ссылки на репозиторииПервая точка входа по любому вопросу DS — внутренний портал. Часть спек остаётся в Figma, часть — в репозиториях кода. Без дублирования: одна ссылка → актуальный источник.

7. Многоуровневая организация командКор-команды full-time, платформенные команды (mobile, web), плюс инициативные группы на часть времени. Масштаб требует, чтобы кто-то отвечал за общий кор, а кто-то за специфику платформы.

8. Фиксация «зачем» принятого решенияБез записи мотивации через 2–3 года команда повторяет цикл обсуждений. В больших DS документация решений — не бюрократия, а способ не «изобретать заново».

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

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

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