Дизайн-система
логистической компании
5 продуктов
30+ компонентов
Как вместе с командой превратили дизайн-систему в масштабируемый инструмент для продуктов
Контекст
и проблема
Контекст
Компания развивает экосистему цифровых продуктов для маркетплейса грузоперевозок (5 продуктов, 100+ IT-специалистов).
Интерфейсы прошли несколько этапов развития: от гайдлайнов в PDF до адаптации Material UI под задачи компании.
Я участвовала во всех этапах развития системы. В этом кейсе — переход на собственную дизайн-систему.
Проблема
Со временем возможностей Material UI стало не хватать: доработка компонентов усложнялась и становилась дороже.
Дополнительно накопился ряд проблем:
- всё чаще внедрялись временные паттерны (например, модальные окна)
- одинаковые элементы могли работать по-разному
- не было принципов принятия решений, поэтому одни и те же вопросы приходилось обсуждать заново
Это снижало консистентность и замедляло развитие продуктов.
Задача
и команда
Задача
Создать собственную дизайн-систему, чтобы ускорить разработку, снизить стоимость поддержки, внедрения изменений и обеспечить единый подход к проектированию интерфейсов в продуктах.
Команда
В основной фазе над системой работали 3 frontend-разработчика и 3 продуктовых дизайнера. Также периодически подключались mobile-разработчики и иллюстратор.
Мой вклад
Основной вызов
Развивать дизайн-систему в двух плоскостях:
- как дизайнер — проектировать саму систему
- как менеджер — выстраивать процессы и внедрять в продуктовые команды
Ключевые действия
- Вела развитие дизайн-системы и координировала её внедрение в продукты
- Развивала компонентную библиотеку и правила её использования
- Синхронизировала решения между Figma, документацией и реализацией в Storybook
- Проводила дизайн-ревью и контролировала консистентность решений
- Помогала новым дизайнерам быстрее включаться в работу через онбординг
Решение
Прошлый опыт
При разработке системы учли проблемы предыдущих решений:
- хаотичное использование серых цветов
- пересечение брендового и семантического цветов
- отсутствие спецификаций и стандартов, что порождало лишние споры
- сложная и дорогая кастомизация компонентов
UI-kit
- Цвета: разделили на брендовые, нейтральные и семантические (с учётом WCAG)
- Типографика: использовали фирменный шрифт для заголовков и системный для текста
- Иконки: стандартизировали размеры, нейминг и разработали гайдлайны для создания новых
- Иллюстрации: вместе с иллюстратором собрали масштабируемую библиотеку элементов и отдельную расширенную палитру, чтобы дизайнеры могли быстро собирать сюжеты сами
Спецификации
Вместе с разработчиками создали шаблон описания компонентов, что упростило их использование и передачу в разработку.
Редактура
Через документ задали единые правила текстов и типографики, чтобы снизить расхождения и повторные обсуждения. Документ стал использоваться не только дизайнерами, но и командами тестирования и маркетинга.
Внедрение
Подходы
Во время проработки компонентов обсуждали два сценария:
- компонент создаётся заранее, вне конкретного экрана — ускоряет разработку, но есть риск не учесть реальный контекст
- компонент создаётся в момент необходимости, как часть продуктовой задачи — позволяет учесть контекст и быстрее проверить решение, но замедляет запуск
Также сравнили подходы на уровне команды:
- централизованный подход, когда компоненты делает одна команда — здесь выше консистентность, но дороже ресурс
- федеративный подход, когда команды создают компоненты сами — быстрее развитие, но выше риск расхождений
Выбранная стратегия
Для быстрого старта выбрали централизованный подход и создавали компоненты в местах применения — внутри продуктовых задач.
Это позволило быстрее внедрять систему и учитывать реальные сценарии использования.
После формирования базового набора (20+ компонентов) перешли к более гибкой модели:
- начали создавать компоненты вне продуктовых задач, если было несколько сценариев использования
- частично перешли к федеративному подходу
Результаты
Итог
- Разработано и описано 30+ компонентов
- Дизайн-система внедрена в 5 продуктах
- Она позволила быстро провести ребрендинг продуктов без переработки интерфейсов
- По результатам NPS пользователи не отмечали проблем в зоне дизайн-системы, а общее удобство продукта называли одной из его сильных сторон
Дальнейшее развитие
- Обновить UI-kit с учётом новых возможностей Figma
- Разработать поддержку тёмной темы
- Пересмотреть типографику для веба и не использовать размер менее 12 кегля
- При полном переходе компании в scrum лучше рассмотреть вариант отдельной команды и централизованного подхода к разработке компонентов
-
Инициировала создание компонентов и вела беклог
-
Вместе с командой создали и описали 30+ компонентов для быстрого построения интерфейсов
-
Снизили количество повторных обсуждений интерфейсных решений
-
Упростили взаимодействие дизайна и разработки через единые стандарты и компоненты