Дизайн система

Предпосылки

Середина 2020. Когда я пришёл в B2B/B2C SaaS, у команды был Figma-файл с базовыми компонентами. Он назывался UI-kit, но к реальному продукту уже почти не имел отношения. Это доставляло много проблем при проектировании новых фич и сильно затягивало сроки разработки.

Исследование

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

Что показал аудит

• До 3-х вариантов одного контрола на проде без четкого понимания для чего они отличаются.
• В каждом разделе состояния (hover, focus, error) реализованы хаотично и редко переиспользуются.
• Тёмная тема заблокирована, все цвета зашиты напрямую в CSS.

Предварительное исследование

Я выделил время на исследование и подготовку. Читал документацию крупных дизайн систем: Material, Polaris, Carbon, изучал открытые Figma-файлы крупных команд и лучшие практики на тот момент. Я читал статьи и смотрел ютуб, чтобы разобраться как крупные компании работают с неймингом, как устроена иерархия компонентов, как они используют варианты и nested instances.

Цели исследования

1. Найти эффективные решения, которые уже проверены крупными командами и адаптировать их под наши нужды.
2. Понять как повысить консистентность продукта за счёт переиспользования компонентов и существующих паттернов.
3. Спланировать поэтапное создание устойчивой и гибкой системы, с помощью которой можно будет ускорить разработку.

Основное ограничение

Дизайн система должна внедряться поэтапно, не тормозя продуктовые релизы. На старте у компании не было намерения нанять второго дизайнера.

Роадмап

1. Токены: цвета, типографика, отступы
2. Базовые компоненты: кнопки, чекбоксы, инпуты, иконки
3. Основные паттерны: навигация, таблицы, модалки, сайдбары, меню и т. д.
4. Синхронизировать с кодом: общий нейминг и стейты для каждого компонента в Storybook
5. Описать принципы работы: документация, и правила контрибуции

Как строился процесс

Возможно правильнее было бы отложить всё в сторону и строить систему. Но это означало бы заморозить продуктовые релизы на несколько месяцев. Как единственный дизайнер в продукте я не мог себе этого позволить. Поэтому я начал собирать компоненты прямо внутри текущих задач. Каждая новая фича становилась тестовым стендом, а компоненты сразу проверялись в боевых условиях.

Что получилось

Взяв за основу лучшие практики, ввёл сетку 4px как единый шаг для всех размеров, зафиксировал базовые правила вёрстки, определил палитру цветов и шрифтовые стили в виде визуальных гайдлайнов и настроил соответствующие стили.

И уже на основании этих стилей я собрал набор самых часто используемых контролов (молекул). С их помощью я смог кратно ускорить создание новых компонентов под текущие продуктовые задачи.

Синхронизация с фронтами

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

Выводы

Сборка интерфейсов на новых компонентах пошла заметно быстрее как с точки зрения дизайна так и с точки зрения разработки.

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

Buy-in

Конец 2020. После сборки и тестирования первой версии, я пришел к стейкхолдерам с цифрами. Аналогичная задача, которая раньше занимала ~21 рабочий день, с использованием новых компонентов вышла в релиз за ~14 дней.

Этого хватило для защиты инициативы перед СЕО и СТО, которые одобрили инициативу и выделили ресурсы (6 часов моего времени в неделю) на развитие и поддержания системы.

Как договаривался

Показал наработки на встрече лидов, объяснил логику построения ДС и выгоду внедрения компонентного подхода для решения рабочих задач.

• CEO одобрил инициативу, так как цифры говорили сами за себя. Time-to-market сократился почти вдвое, а это колоссальная экономия ресурсов всех команд, связанных с разработкой.
• CTO согласовал архитектуру: палитра цветов, стили текста, интеграция со Storybook. Также подтвердил что дизайн система критически важна для масштабирования продукта с сохранением консистентности.
• С лидом фронтенда договорились, что со временем Figma+Storybook станут единственным источником правды, это позволит уйти от верстки через Zeplin и ещё существенней экономить ресурсы.

Результаты

• Защитил идею реальным сокращением сроков: −30%.
• Лид фронтенда стал главным драйвером ДС в своей команде.
• Добился выделения времени на поддержку и развитие ДС.

Старт без токенов

Мы решили оставить хардкод значения, чтобы не тормозить процесс. Это был осознанный техдолг, чтобы быстрее внедрить ДС и использовать её для решения реальных задач. Миграция на семантические токены позже заняла полгода (и потянула за собой частичный редизайн ЛК).

Проект развивался более 5 лет. На каждом этапе я договаривался с разработчиками и принимал осознанные решения, балансируя между скоростью сейчас и устойчивостью потом.

Вёрстка через Zeplin

Первые пару лет работы над системой я был вынужден синхронизировать все новые макеты из Figma в Zeplin. Исторически сложившийся пайплайн продакшена существенно тормозил процесс разработки.

Только web, только desktop

До старта разработки нового мобильного приложения в 2023 году дизайн система охватывала только web приложение для десктопа (с минимальной шириной экрана 960px). Компоненты мобильного приложения я потом собрал в отдельном Figma-файле, на тех же общих токенах.

Storybook over Figma

Правило «компонент готов только когда он отражен в коде» замедлило темп проектирования, но практически убрало расхождения между макетами и продом.

Ключевые инсайты

Из трёх команд систему драйвил только я, так как мне нужно было решать продуктовые задачи каждый день, а старый UI-kit ощутимо тормозил. Фронтенд и QA жили нормально и без неё. Компоненты создавались по месту, а кнопки сверялись вручную и никто не считал это проблемой.

Поэтому первым приоритетом было показать зачем она нужна остальным. Фронту, чтобы использовать единые компоненты вместо разрозненных кусков CSS. QA, чтобы положить конец ручной сверке пикселей на каждом ревью. Когда обе команды увидели разницу на реальных задачах, а не на презентации, аргумент «консистентность = хороший UX» стал общим интересом.

Контекст

Как только Figma выкатила Variables в 2023 году, я осознал все преимущества данной концепции, и начал подготовку к переезду на токены. Для полной синхронизации компонентов с кодом мне пришлось буквально пересобрать все компоненты с нуля, и ввести в оборот 300+ новых переменных. Так в 2023 году появилась версия 2.0.

Я провёл несколько рабочих сессий вместе с лидом фронтов, чтобы мы синхронизировались и проработали токены под новый стек.

Семантика выходит на первый план

Вместо хардкод значений и стилей с названиями по типу blue-500 мы перешли на семантические токены вида button-color/primary/default, внутри которых уже хранились фиксированные переменные blue-800. В итоге изменить тему продукта (например для тёмной темы или white-label) стало задачей на пару кликов.

Трудности миграции

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

Я отвечал за пересборку всей навигации и верхнеуровневых паттернов. За счёт выноса сайдбаров за пределы контентных «островов» удалось добиться четкого разделения элементов управления и навигации от контента.

Что это дало

• Тёмная тема стала технически возможна
• Глобальные цветовые изменения стали многократно быстрее через правки в базовых переменных
• Общий нейминг создал единый язык между дизайном и кодом
• Семантический нейминг читается как документация. Теперь токены вроде button-color/primary/default говорят сами за себя

Наследование через .base

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

Этот принцип стал стандартом для команды. Когда мы выросли до 4 дизайнеров, это спасло нас от хаоса. А когда решили обновить стилистику во всём кабинете — сэкономило десятки часов на правки сотен вариантов в основных молекулах и организмах.

Дизайн взаимодействий

Поведение каждого компонента проектировалось по референсам лучших представителей индустрии и дорабатывалось совместно с фронтендом.

• Зафиксировал состояния: default / hover / focus / active / selected / disabled / error / loading.
• Пропушил Accessibility: матрицы контрастности, фокус-стейты для управления с клавиатуры, обязательные alt-description для пользователей со скрин-ридерами.
• Переработал все навигационные и инструментальные панели в продукте под единый стандарт. Консистентные select-состояния и предсказуемое поведение элементов управления помогают пользователю понимать, где он находится, а значит ускоряют его рабочий процесс.

Микроанимации

Я сделал добавление микроанимаций в компонент обязательным пунктом. Теперь у каждого элемента были предопределённые: появление, исчезновение, state transitions, feedback-анимации. Это позволило в дальнейшем существенно ускорить сборку прототипов для тестирования гипотез, так как любой компонент в макете был отзывчивым и вёл себя точно также как в реальном продукте.

Что легло в основу ДС

• Размерный модуль: шаг 4px для мелочей, 8px для крупных блоков.
• Цвета: 5 семантических групп, по 10 плоских и прозрачных оттенков. Это дало необходимую гибкость для проектирования.
• Типографика: модульная шкала на современном гротеске с открытой лицензией (Onest).
• Иконки жестко стандартизированы. Обводка 2px, рабочая область 20×20. Всё приведено к одному оптическому весу.

Процесс хэнд-оффа

Синхронизировал структуру Figma со спецификациями Storybook. Одна логика, одни названия. Проектирую компонент по чеклисту, отдаю фронтам вместе с продуктовой задачей, они собирают в Storybook, а я провожу ревью. Плюс все краевые случаи и новые состояния мы обсуждали до написания кода. Это позволило существенно сократить процесс релиза новых фич.

Чеклист нового компонента

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

• Шаг сетки 4px (размеры, отступы).
• Определено поведение (включая disabled, error, loading и focused).
• Компонент поддерживает краевые сценарии и они отражены в Figma.
• Нейминг совпадает со Storybook. Все использованные цвета, шрифты и отступы должны быть связанными токенами из библиотеки.
• Полная поддержка адаптивности, настроены constraints и autolayout.
• Анимации встроены, там где это нужно.

Проблема DesignOps

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

Собственный плагин

Поэтому я разработал плагин AxoLinter. Он сканирует выбранные макеты и мгновенно находит любые «оторванные» от переменных значения. Возможности плагина:

• Разделяет ошибки по группам (цвета, радиусы, отступы, контраст и т. д.).
• Рассчитывает общий процент покрытия библиотеки токенами.
• Предлагает ближайший подходящий токен для каждой ошибки и позволяет связать его в один клик или массово через Fix All.
• Общий нейминг полностью устранил путаницу в коммуникации.
• Storybook стал единым источником правды со сквозными ссылками на макеты в Figma.
• Разработчики получают макеты, которые на 100% соответствуют техническим требованиям и ограничениям продакшена.
• Поддержка ДС стала значительно легче с применением собственного плагина.

Переход с Zeplin на Dev Mode

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

С появлением Figma Dev Mode мы убрали лишнее звено. Я провел онбординг для фронтенд-разработчиков: показал, как читать спецификации и работать с компонентами напрямую из библиотек. В результате мы отключили Zeplin, сократили операционные издержки и исключили ошибки, связанные с устаревшими версиями макетов.

Передача знаний

Для бесшовного погружения новых дизайнеров я разработал формат менторства 1-на-1. Вместо чтения лонгридов новые сотрудники проходили интерактивный синк, где я подсвечивал тонкости работы с библиотекой, логику переиспользования компонентов и разбор краевых сценариев. Если в процессе работы один и тот же вопрос возникал дважды — это становилось сигналом для апдейта комментариев в Figma или дополнения спецификации в Storybook.

• Новые дизайнеры адаптировались и начинали уверенно работать с системой после одной менторской сессии.
• Рутинные вопросы в Slack формата «какой здесь отступ или цвет» практически исчезли.
• Отказ от стороннего софта (Zeplin) сэкономил ресурсы компании и упростил экосистему инструментов.

Ключевые этапы

• 2020 — Старт в продакшене. Компоненты создавались прямо внутри продуктовых задач. Официального запуска не было, но команда из 2 продуктовых групп сразу заметила ускорение работы.
• 2021 — Интеграция: проведение синхронизационных сессий с командой разработки. Итог — переход на единую терминологию и сквозные компоненты.
• 2023 — Перезапуск v2.0. После релиза переменных в Figma мы с лидом фронтенда пересобрали токены под семантику. Это позволило технически внедрить тёмную тему и менять глобальные цвета за пару кликов.
• 2024–2025 — Команда дизайна выросла с 1 (я) до 4 специалистов. За счёт готовой базы онбординг занимал один созвон, а система стабильно продолжала масштабироваться.

Эффективность в цифрах

На пике система обслуживала кросс-функциональную команду из 4 фронтенд-разработчиков, 4 дизайнеров и 3 QA-инженеров. Ускорение TTM продуктовых задач на 30% дало следующие результаты:

• ~100 часов разработки ежемесячно — средняя чистая экономия времени команды фронтенда на сборке интерфейсов.
• >6 000 рабочих часов — суммарная экономия за 5 лет работы (без учёта ускорения задач дизайна и QA).

Реакция и долгосрочный профит

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

Итог

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