Как мы создавали CDS

В прошлый раз мы рассказали про UI Kit и его проблемы. Сегодня же хотим остановиться на истории создания Central Design System (CDS) в B2B-Center.

Как появилась дизайн-система

На очередном техническом совещании команда разработчиков узнала о запуске нового продукта N. Проект необходимо было написать на современном языке и при этом избежать проблем с фронтом, описанных в статье UI Kit vs CDS.

UI Kit использовал старые технологии, которые конфликтовали с новыми. При этом продукт N не был частью торговой площадки B2B-Center, и его визуальный язык мог отличаться.

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

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

Готовые же дизайн-системы, Material и т.п., дают свой набор компонентов, а дальше пришлось бы плодить кладбище костылей.

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

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

С фразой «да кто мы такие, чтобы бояться трудностей?» стартовали. К слову, после этой фразы в компании и появился автор статьи, так как для создания дизайн системы выделили отдельную полноценную команду.

С чего мы начали

У нас было 3 фулстек-разработчика, 1 менеджер, 2 дизайнера, 75 пакетиков чая, 5 пакетиков конфет, 2 пачки печенья, и ТЗ на продукт N (читать голосом Юрия Живова).

Итак, чай заварен, пакетики с конфетами разорваны, поехали!

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

Сделав глоток ароматного чая, открыли Sketch, и понеслось.

У нас был план и мы его придерживались

Первым шагом в создании визуального стиля стали цвета. Подбирали долго, тестировали на соответствие рекомендациям W3C — WCAG 2.1.

Вторым шагом стала типографика. «Играли» со шрифтами, применяли различные подходы к масштабированию: от классической типографической шкалы до золотого сечения. В итоге получили подходящую иерархию. Сам шрифт оставили базовым — Arial.

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

Параллельно зарождались принципы, описанные в статье «Зачем нужна дизайн-система», которые должны были заложить во все это крепкий фундамент.

Основа для будущей библиотеки была готова. Пока разработчики переводили все это в токены и миксины, дизайнер начал собирать первые компоненты.

Кстати на чем пишем?

Выбрали Vue.js. Этот красавец умеет внедряться в существующие системы, что идеально подходило для замены старых компонентов UI Kit на CDS.

Фреймворк настолько прост и понятен, что дизайнер со знанием html, css и зачатков js мог спокойно разработать простой компонент или внести изменения в существующие. Порог вхождения низок, комьюнити дружелюбное, один словом — любовь с первого взгляда.

Видишь дизайн-систему? А она есть!

Пока это все походило на обычный UI Kit: вроде дизайн-система, а системы нет.

Набросились на Miro, описали воркфлоу всех этапов разработки, процесса добавления компонентов в библиотеку, правила версионирования, релизов и так далее. Если какой-то из пунктов интересен, пишите в комментариях, рассмотрим подробнее.

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

Компоненты зарождались в продукте N, как и планировалось. Возник вопрос, где эти компоненты публиковать. Ответом стал сайт cds. Собственный сайт, в отличие от Confluence и других решений, давал полный контроль над ситуацией. А размещенные демки позволяли дизайнерам, и им сочувствующим, вживую потыкать компоненты и понять, что как работает и как себя ведет.

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

Пару компонентов спустя дизайн-система стала работать на опережение. Компоненты создавались уже в самой ДС и использовались в продукте N. Составили роадмап и через год выкатили полноценную версию 1.0. С визуальным языком, компонентами, первыми шаблонами и правилами редактуры.

После релиза другие команды начали присматриваться к CDS. Так как дизайн-система — продукт внутренний, то нужно было где-то обслуживать желающих с ним работать. Так в Slack появилось несколько каналов: отдельно для разработчиков, отдельно для дизайнеров. У одних не тыкался компонент, у других в Sketch что-то не работало. Так мы избежали каши вопросов, каждый консультировал на своей вверенной территории.

Что было дальше?

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

Сейчас полным ходом идет переезд в Figma, Storybook. Готовим новую версию сайта, пилим новые компоненты.

Как-то у меня был диалог с человеком, команда которого рассчитывала создать дизайн-систему в своей компании за год. Ох, как они ошибались…

Дизайн-система — это такой же продукт, как и любой другой. Его нужно развивать и поддерживать, желательно с отдельно выделенной командой, иначе есть риск прийти к нашему UI Kit.

На этом, пожалуй, все.

В следующей статье расскажем о витрине компонентов и зачем разрабатывать компоненты вне дизайн-системы.