Я выстроил дизайн-систему донат сервиса для стримеров и перенёс её в код: токены в Figma, репозиторий с доступом в Git и живые взаимодействия в Storybook
Главное в этом кейсе — не набор компонентов, а способ передачи в разработку. Поведение интерфейса я собираю не в макетах, а прямо в коде, в Storybook, на тех же токенах и компонентах, что работают в продукте. Дизайнер в репозитории разработчика — схема нетипичная. разработчик получает готовое поведение, а я сразу вижу, как оно работает на деле
Работал в связке с фронтенд-разработчиком. Систему вёл сам: от аудита существующих макетов до передачи в код и сборки состояний в Storybook
Развивал дизайн-систему и перенёс её в claude. Мне завели репозиторий и доступ в Git: вместо статичных флоу я стал собирать живые взаимодействия прямо в нашем Storybook. Это сократило нагрузку на фронтенд: разработчик получает готовое поведение, которое можно открыть и проверить
Начал с аудита переменных: значения заводились под каждый стиль отдельно, часть стилей дублировала друг друга, а шкал отступов и радиусов, палитры и токенов компонентов не было вовсе
Нумерация слоёв — это порядок зависимости: каждый уровень ссылается только на предыдущий. примитивы чисел находятся в базе, примитивы цвета в палитре
Токен называется по роли surface/hover, а не по оттенку. Один тип параметра — один контрол
Я был единственный дизайнер, поэтому система росла вместе с продуктом, а не «на вырост». Сейчас одна тёмная тема: слои готовы к светлой, но делать её без запроса продукта не стал. Редкие компоненты в систему не включал, пока они не повторились на нескольких экранах
Собрал токены в шесть слоёв, где каждый ссылается только на предыдущий
00-base — числовые примитивы без смысла: шаг 4 px, размеры шрифта, высоты строк
01-typography — роли поверх базы: Display, Headline, Body, Label
02-radius и spaces — шкала значений и смысловые имена поверх неё
03-palette — только оттенки: neutral, brand и статусные цвета
1.1 color — смысл поверх палитры: background, content, ui, border
1.2 component color — токены компонентов: button, input, card и другие
Если поменять бренд-цвет, меняется одна запись в палитре: #8F42FF лежит в 03-palette, а кнопки, фокус и акценты на него ссылаются. Типографика собрана на ролях (Display, Headline, Body, Label): размер и вес задаются один раз, а стили на них ссылаются
Описал состояния контролов один раз и для всех компонентов
Состояния описаны один раз для каждого типа контролов. Разработчик не придумывает, как выглядит фокус или ошибка: это уже решено и лежит в системе
Цвета состояний не рисуются вручную, а берутся из слоя 1.2. Например, наведение на основную кнопку ссылается на brand/hover (#A066FF), нажатие на brand/pressed (#6F2ED6)
Перенёс систему в Claude и вместо статичных флоу стал собирать живые взаимодействия в Storybook
Когда токены были готовы, перенёс систему в Claude. Мне завели репозиторий и доступ в Git, поэтому токены и компоненты меняются через историю изменений, а не файлами в чате
Вместо статичных флоу я стал собирать живые взаимодействия прямо в нашем Storybook: наведение, фокус, ошибку, загрузку и переходы между состояниями можно открыть и проверить
Раньше я передавал в разработку подробные флоу и макеты, и этого хватало. Теперь вместо них разработчик получает готовый прототип в Storybook: поведение уже собрано на тех же токенах и компонентах, ему остаётся подключить данные. Это ещё сильнее сократило нагрузку на фронтенд
Имя токена в Figma совпадает с именем переменной в коде: ui/brand/default → --ui-brand-default. При проверке ничего не нужно переводить
Описал паттерны над компонентами и правила развития системы
Пустые состояния, скелетоны загрузки, поиск и шаблон заголовка с фиксированным порядком элементов описаны так же, как компоненты: один раз и с состояниями
Новый компонент появляется, только если задача повторилась и не решается существующим. Новый цвет сначала ищется среди смысловых токенов и только потом добавляется в палитру. Токен, компонент и его story обновляются вместе
Как система работает в деле: пункт меню в разборке, из каких частей он собран и на каких токенах
Что изменилось
Состояния и переходы собраны в Storybook, поэтому вопросы о том, как должен вести себя интерфейс, снимаются до начала реализации: поведение можно открыть и проверить
Имена токенов в Figma и в коде совпадают, поэтому расхождение с макетом видно сразу: достаточно сверить значение с токеном
Путь от макета до проверки поведения. К проверке на готовом экране добавилась проверка в Storybook до реализации