Всем привет. Меня зовут Дмитрий Пашкевич и я Frontend разработчик в Quadcode. Последние несколько лет я занимаюсь тем, что принято в современной индустрии называть «Дизайн-системами».
В какой-то степени это сочетание слов стало собирательным, так как опыт показывает, что в разных компаниях под ним понимают разное. Понимание зависит от: уровня зрелости команды/проекта/компании/процессов, наличия желания, времени и ресурсов, а самое главное — людей с «горящими» глазами, которые будут это направление развивать, несмотря на все сложности.
Я прошел путь от создания различных UI-китов, трансформаций этих UI-китов в дизайн-системы до полноценного построения дизайн-систем с нуля со стороны FE-разработки в качестве:
Потребителя компонентов.
Разработчика компонентов.
Лида на построении дизайн-системы с нуля. Здесь 80-90% времени занимала разработка компонентов, остальные 10-20% — применение компонентов в продуктовом коде, а также шаринг знаний и взаимодействие с FE-командой разработки.
Продуктового разработчика – когда «пилишь компоненты» и сразу же внедряешь их при разработке продукта. В этом случае вся команда участвует в работе над дизайн-системой.
В этой статье я хочу поделиться наработанным опытом и попробую его структурировать на примере нашей компании. Я покажу фазы формирования и разработки дизайн-системы, через которые мы прошли, поделюсь техническим стеком нашего продукта и выводами о том, какую пользу нам принесла готовая дизайн-система.
С одной стороны, хочется сразу дать определение, что такое дизайн‑система в моем понимании, но пойдем немного по‑другому и сформулируем что есть что после основной части.
Спойлер
Кому не терпится узнать отличия дизайн-системы от UI-кита, может сразу перейти к разделу «Что же такое дизайн‑система, если резюмировать». Но все-таки рекомендую читать от и до