Как мы создавали 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.
На этом, пожалуй, все.
В следующей статье расскажем о витрине компонентов и зачем разрабатывать компоненты вне дизайн-системы.