Пересобрали дизайн-систему для Добро.рф и в 2 раза ускорили работу над интерфейсами
Построили новую дизайн-систему для экосистемы сервисов Добро.рф на основе токенной модели для централизованного управления элементами интерфейса. В результате количество правок стало на 70% меньше, а время на перенос дизайна в код сократилось на 45%.
Добро.рф
крупнейшая волонтёрская экосистема и цифровая платформа в России. Здесь люди и организации находят друг друга, чтобы помогать, учиться, развивать сообщества и реализовывать социальные инициативы. По сути — это единое цифровое пространство для всех, кто так или иначе связан с добровольчеством и общественной жизнью в стране.
Цель
создать современную дизайн-инфраструктуру, которая обеспечит управляемость компонентов, ускорит внедрение дизайна в продакшен
Задачи проекта
выбрать безопасную стратегию миграции с учётом существующего ядра старой дизайн-системы, которое трогать нельзя;
выстроить токенную модель, чтобы централизованно управлять элементами интерфейса и ускорить разработку;
управлять элементами интерфейса и ускорить разработку;
собрать библиотеку компонентов и состояний;
связать Figma и Storybook, чтобы компоненты быстрее переходили из дизайна в разработку и прод.
Решение
Дизайн-команда «Вебпрактик» на проекте Добро.рф работала в тесной связке с фронтенд-разработчиками и продуктовой командой клиента. Мы выстроили процесс как инженерную трансформацию: анализировали ограничения существующей архитектуры, тестировали миграционные сценарии и поэтапно внедряли изменения без остановки текущей разработки.Такой подход позволил создать устойчивую инфраструктуру, которая поддерживает масштабирование платформы и ускоряет работу продуктовых команд.
В экосистему Добро.рф входят десятки сервисов: сайты привязаны к старой дизайн-системе, компоненты и экраны построены на прежних принципах, поэтому выстроить систему с нуля, без учёта легаси было нельзя. Резкий отказ от старой логики сломал бы слишком много связей.
Плюс за время проекта брендбук трижды менялся. Нужно было оперативно перестраивать фундамент дизайн-системы прямо на ходу и следить, чтобы новое не поломалось.
Формально дизайн-система у клиента существовала, но не учитывала обновлённый брендбук: была объёмной, содержала множество архивных компонентов, не была синхронизирована с кодом.
Разработали три сценария миграции
Собрать всё с нуля
Слишком рискованно: старая дизайн-система построена на стилях, а не на токенах, одинаковые компоненты в разных сервисах не синхронизированы, а настроены вручную. Любое изменение обрушит совместимость, усложнит тестирование и согласование макетов.
Постепенно заменять компоненты в старой системе
Новая топология компонентов предполагает настройки и свойства, несовместимые со старой архитектурой, и постоянно упиралась бы в старый каркас. Это разрушит старые связи между уровнями компонентов во всех сервисах экосистемы.
Создать новую систему рядом со старой
Такой сценарий требовал большей аккуратности, зато позволил бы двигаться без резких сбоев. План такой: берём компоненты из старой системы, копируем в новую и заново настраиваем их, сохраняя преемственность. Потом поэтапно привязываем новые компоненты к продуктам.
Мы выбрали третий путь — самый сложный в управлении, но безопасный и контролируемый.
Построили новую дизайн-систему на токенах
Старая система опиралась на стили и не позволяла гибко управлять компонентами или синхронизироваться с кодом. Токены же — это переменные, которые хранят значения цветов, размеров, отступов и шрифтов и позволяют централизованно управлять ими в дизайне и коде. За счёт этого изменения стали предсказуемыми, а сама система — управляемой.
Для цветовой палитры создали структурированную шкалу оттенков для каждого базового цвета, чтобы управлять интенсивностью цвета и легко вносить изменения
Цветовая модель состоит из трёх уровней: базовые оттенки → рабочие переменные → конкретные применения в интерфейсе. Такая структура — буфер безопасности: изменения на одном уровне не ломают систему целиком. Она помогает обновлять систему точечно, а не вручную по всему продукту.
Снизили долю фирменного фиолетового в визуале. В старой системе это был основной цвет: его использовали даже в тексте. Мы ввели нейтральную черно-серую базу и оставили фиолетовый только для брендинга и интерактивных элементов. Это сделало интерфейс визуально устойчивым и менее тяжёлым.
Для типографики, отступов и размеров шрифта использовали двухуровневую модель с жёсткой семантической привязкой. Каждый токен отвечает только за свою зону: текст, фон, иконки или рамки. Это защитило систему от случайных конфликтов.
Основная сложность работы в том, что брендбук ещё формировался. Несколько раз менялись логотипы суббрендов. Заложенный в брендбуке шрифт Fact не подходил для веба — пришлось оперативно перестраивать систему. Сначала временно перешли на Euclid Circular B, затем финально на Onest из Google Fonts. Из-за этого нужно было пересобирать типографику и повторно согласовывать всю дизайн-систему.
Как и планировали: собрали новую систему рядом со старой
Сохранили нейминг и логику, чтобы не разрушить существующий монолит. Постепенно компоненты эволюционировали и стали жить по новым правилам.
Громоздкие и сложные элементы упростили. Убрали лишние сущности и сохранили функциональность. Отдельное внимание уделили интерактивным компонентам: кнопкам, инпутам и чекбоксам. Продумали и зафиксировали все возможные состояния: наведение, нажатие, активность и ошибки.
Для согласований собирали интерактивные демостенды, чтобы клиент сразу мог протестировать, как компоненты ведут себя в реальности, и дать обратную связь.
Увязали новую дизайн-систему с разработкой
Раньше дизайн жил только в Figma и никак не был связан с кодом. Мы выстроили связку Figma ⟷ Storybook и перевели систему на токенную архитектуру, совместимую с фронтендом. Теперь изменения в дизайн-системе автоматически отражаются в интерфейсах и коде.
Трёхуровневая цветовая модель и двухуровневая типографическая схема сделали изменения безопасными: обновления на верхнем уровне не разрушают уже собранные интерфейсы.
Результаты
Дизайн-система перестала быть набором правил и стала полноценной инфраструктурой разработки — управляемой, безопасной и масштабируемой.
Она поддерживает единый визуальный язык на всех сервисах экосистемы Добро.рф, ускоряет производство, снижает количество ошибок и выдерживает масштаб федеральной платформы. А значит — экономит государственные ресурсы и ускоряет запуск новых социальных инициатив на федеральном уровне.
В основе системы — единая инфраструктура:
Figma — единое пространство для компонентов, токенов и документации;
Storybook — живая витрина для хранения и проверки компонентов для разных платформ;
Дизайн-токены — фундамент единого визуального языка, обеспечивающий согласованность цветов, типографики, отступов и других параметров интерфейса на всех платформах.
Новая дизайн-система стала основой для работы дизайнеров и фронтенд-разработчиков. Она подходит для масштабирования на сервисы и инициативы всей экосистемы Добро.рф.
Проект в цифрах
- 80% всего интерфейса (1300 экранов)
уже перевели на новую систему
- В 2 раза
сократилось время на дизайн-задачи
- На 60–70%
снизился объём ручных правок
- 5 месяцев
ушло на разработку стабильной версии
- 100% синхронизация
компонентов между Figma и фронтендом
- На 45%
сократилось время на внедрение дизайна в код
Следующий проект