ОТП Банк — как собрать дизайн-систему «снизу вверх» и не утонуть в изменениях

без центра ответственности поддерживать и актуализировать систему сложно; чем больше элементов, тем сложнее управление.

Главное

без центра ответственности поддерживать и актуализировать систему сложно; чем больше элементов, тем сложнее управление.

Фокус: токенная архитектура, переход на Variables, структура библиотек, коммуникации и версионирование.

Контекст: внутри организации параллельно существует несколько дизайн-систем; миграция идёт постепенно.

Контекст

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

Запуск дизайн-системы описывается как реакция на накопившееся «наследие» и невозможность эффективно работать на устаревших стилях. Отправной точкой стал переход индустрии на variables и необходимость привести базовые параметры интерфейса к управляемому виду. Работа начиналась с foundations: сначала цвета для веба интернет-банка, затем шрифты, затем отступы и размеры — всё на variables.

Отдельно подчёркивается, что прямой перенос мобильной системы на веб не решает задачу: у веба другие состояния (например, hover/press) и другой набор промежуточных состояний, которые важно учитывать при проектировании компонентов.

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

без центра ответственности поддерживать и актуализировать систему сложно; чем больше элементов, тем сложнее управление.

2. Цели: что пытались выиграть

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

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

3. Как устроена система: архитектура библиотек и уровни

Foundations → компоненты

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

Семантика в названиях — обязательное правило

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

Foundations как набор библиотек

Фундаментальные параметры целесообразно держать не в одном файле, а в нескольких библиотеках: разные команды могут подключать разные части (например, цвета и spacing, но свои шрифты). Такой подход упрощает переиспользование и снижает зависимость команд от одного «монолита».

4. Токенная архитектура и переход на Variables

Три уровня токенов

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

Главная практика: Variables-коллекции на уровне компонента

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

Практика помогает решить проблему «сброса контента» и разрастания компонентов: вместо множества отдельных вариантов команда объединяет поведение в одном компоненте и переключает оформление через темы/переменные.

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

5. Процесс миграции: самое сложное — перейти на новые foundations

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

7. Коммуникации и управление изменениями

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

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

6. Документация: стремление к «порталу», но ограниченные ресурсы

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

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

9. Ограничения и риски

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

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

1. Алиасы для поиска иконок через descriptionЕсли иконка в библиотеке называется «cross», дизайнер её не найдёт, когда ищет «крестик закрытия». Решение — добавлять слова-алиасы в поле description компонента: поиск Figma индексирует описание, и иконка находится по любому логичному запросу.

2. Ownership компонентов: исполнитель + ответственныйУ каждого компонента в системе есть явный исполнитель — к кому идти за контекстом и изменениями. Потеря этой связки приводит к «бесхозным» компонентам, которые никто не хочет трогать.

3. Variables-коллекции на уровне компонентаVariables объявляются не глобально, а на уровне конкретного компонента — ближе к месту использования. Помогает избежать путаницы в больших наборах переменных и делает миграцию управляемой.

4. Переход на Variables как отдельный миграционный проектМиграция со стилей на Variables — самое сложное в развитии DS. Требует времени, участия многих ролей и пересборки foundations. Без выделенного проекта команда застревает на годы в гибридном состоянии.

5. Идея beta-зоны для обкатки измененийВ планах — отдельная beta-зона для обкатки изменений и сбора обратной связи до полного релиза. Снижает риск массовых поломок и даёт командам-потребителям время адаптироваться.

6. Несколько параллельных DS и постепенная миграцияВ организации сосуществует несколько дизайн-систем — это нормальное состояние. Миграция идёт постепенно, не «за один квартал все перешли». Главное — удерживать центр ответственности, иначе любая из систем быстро устаревает.

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

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

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