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

Написать в ТГ

Дизайн-система логистической компании

b2b · web · app

30+ компонентов

5 продуктов

Как вместе с командой превратили дизайн-систему в масштабируемый инструмент для продуктов

Контекст и проблема

01

Проблема

Возможностей Material UI стало не хватать: доработка компонентов усложнялась и становилась дороже.

Дополнительно накопился ряд проблем:

всё чаще внедрялись временные паттерны (например, модальные окна)
одинаковые элементы могли работать по-разному
не было принципов принятия решений, поэтому одни и те же вопросы приходилось обсуждать заново

Это снижало консистентность и замедляло развитие продуктов.

Продукт

Компания развивает экосистему цифровых продуктов для маркетплейса грузоперевозок (5 продуктов, 100+ IT-специалистов).

Интерфейсы прошли несколько этапов развития: от гайдлайнов в PDF до адаптации Material UI под задачи компании.

Я участвовала во всех этапах развития системы. В этом кейсе — переход на собственную дизайн-систему.

Эволюция экранов до собственной дизайн-системы

Задача и команда

02

Команда

В основной фазе над системой работали 3 frontend-разработчика и 3 продуктовых дизайнера. Также периодически подключались mobile-разработчики и иллюстратор.

Задача

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

Сразу к результатам

Мой вклад

03

Ключевые действия

Вела развитие дизайн-системы и координировала её внедрение в продукты
Развивала компонентную библиотеку и правила её использования
Синхронизировала решения между Figma, документацией и реализацией в Storybook
Проводила дизайн-ревью и контролировала консистентность решений
Помогала новым дизайнерам быстрее включаться в работу через онбординг

Основной вызов

Развивать дизайн-систему в двух плоскостях:

как дизайнер — проектировать саму систему
как менеджер — выстраивать процессы и внедрять в продуктовые команды

Решение

04

Архитектура системы

Система включала:

UI-kit в Figma
документацию и гайдлайны в Confluence
библиотеку компонентов (NPM)
Storybook для синхронизации с разработкой

Все решения синхронизировались между дизайном и разработкой.

Прошлый опыт

При разработке системы учли проблемы предыдущих решений:

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

Шаблон спецификации и компонент в Storybook

Спецификации: вместе с разработчиками создали шаблон описания компонентов, что упростило их использование и передачу в разработку

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

Цвета: разделили на брендовые, нейтральные и семантические (с учётом WCAG)

Типографика: использовали фирменный шрифт для заголовков и системный для текста

Иконки: стандартизировали размеры, нейминг и разработали гайдлайны для создания новых

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

05

Внедрение

Централизированный и федеративный подходы

Подходы

Во время проработки компонентов обсуждали два сценария:

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

Также сравнили подходы на уровне команды:

централизованный подход, когда компоненты делает одна команда — здесь выше консистентность, но дороже ресурс
федеративный подход, когда команды создают компоненты сами — быстрее развитие, но выше риск расхождений

Выбранная стратегия

Для быстрого старта выбрали централизованный подход и создавали компоненты в местах применения — внутри продуктовых задач.

Это позволило быстрее внедрять систему и учитывать реальные сценарии использования.

После формирования базового набора (20+ компонентов) перешли к более гибкой модели:

начали создавать компоненты вне продуктовых задач, если было несколько сценариев использования
частично перешли к федеративному подходу

Дальнейшее развитие

Обновить UI-kit с учётом новых возможностей Figma
Разработать поддержку тёмной темы
Пересмотреть типографику для веба и не использовать размер менее 12 кегля
При полном переходе компании в scrum лучше рассмотреть вариант отдельной команды и централизированного подхода к разработке компонентов

Итог

Разработано и описано 30+ компонентов
Дизайн-система внедрена в 5 продуктах
Она позволила быстро провести ребрендинг продуктов без переработки интерфейсов
По результатам NPS пользователи не отмечали проблем в зоне дизайн-системы, а общее удобство продукта называли одной из его сильных сторон.

Результаты

06