Как создаются дизайн-системы: делимся собственным примером. Часть 1

Всем привет. Меня зовут Дмитрий Пашкевич, я фронтенд-разработчик в компании Quadcode, специализируюсь на создании и разработке систем проектирования. Эта статья предназначена для специалистов разного уровня, занимающихся дизайн-системами: от потребителей и разработчиков компонентов до тимлидов/техлидов, создающих дизайн-системы с нуля. Здесь я поделюсь своим опытом, и пройденным мной путем от создания UI-китов до полноценного построения дизайн-систем, и покажу преимущества, которые нам принесла готовая дизайн-система. Если вы хотите углубить свое понимание дизайн-систем, то эта статья для вас. Приятного чтения!

вступление

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

Я прошел путь от создания различных наборов пользовательского интерфейса, преобразования этих наборов пользовательского интерфейса в системы проектирования, до полного построения систем проектирования с нуля с точки зрения разработки FE в следующих ролях:

  1. Потребитель комплектующих.
  2. Разработчик компонентов.
  3. Ведение разработки дизайн-системы с нуля. Здесь 80–90% времени уходило на разработку компонентов, а остальные 10–20% приходилось на применение компонентов в коде продукта, а также на обмен знаниями и взаимодействие с командой разработчиков FE.
  4. Разработчик продукта — когда вы «строите компоненты» и сразу внедряете их в процессе разработки продукта. В этом случае в работе над дизайн-системой участвует вся команда.

В этой статье я хочу поделиться накопленным опытом и попытаться структурировать его на примере нашей компании. Я продемонстрирую этапы становления и развития дизайн-системы, через которые мы прошли, поделюсь техническим стеком нашего продукта и расскажу о преимуществах, которые принесла нам готовая дизайн-система.

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

‹СПОЙЛЕР› Для тех, кто хочет узнать о различиях между дизайн-системой и UI-китом, вы можете сразу перейти ко второй части моей статьи и сразу перейти к разделу «Что такое UI-кит?». Короче говоря, это дизайн-система». Тем не менее, я все же рекомендую читать от начала до конца. ‹/СПОЙЛЕР›

Проблемы, которые приводят к появлению дизайн-систем

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

Итак, что это могут быть за проблемы?

  1. Старый дизайн утерян. Больше не поддерживается, либо существует только в образах (да, бывает). В этом случае разработчики сами или с помощью дизайнера придумывают способы включения конкретных элементов. Следствием этого является то, что разработка новых страниц становится проблемой. Продукт неизбежно становится несогласованным на разных страницах, потому что теряется логика построения интерфейса.
  2. Старый дизайн/интерфейс морально устарел, необходим редизайн. Возникает вопрос: что делать? Дорабатывать ли текущий продукт: модульно, постранично, или строить с нуля и т. д. — каждый выбирает свой путь. В разных путях есть нюансы, с которыми нужно разобраться.
  3. Сообщения о создании функций/изменениях интерфейса превышают разумные пределы. В этом случае создание нового элемента или подхода к UX становится не связанным с продуктом. Думаю, это можно рассматривать как продолжение пункта 2 и желание команды предоставить пользователям более удобный и современный продукт.
  4. Создание любой новой функции (даже похожей) занимает много времени. Этому могут способствовать различные факторы, такие как плохая архитектура, унаследованная от проекта MVP, устаревшие инструменты или невозможность просто обновиться.
  5. Необходимость улучшения процессов. Желание создать единую точку общения внутри команды, хотя бы между разработкой и дизайном. Небольшой спойлер: как показывает практика, при разработке этот пункт, он же дизайн-система, становится как минимум единственным источником истины, и там постоянно возникают дискуссии.
  6. Наличие значительной рутинной работы при создании новых макетов или кодировании в рамках одного продукта. Иногда нет возможности повторно использовать UI-кит в дизайне или коде. Такая ситуация часто возникает в разных проектах, а иногда и в одном проекте (что более актуально для проектирования в конкретном инструменте). Выглядит это примерно так: вы открываете новый дизайн-макет, видите похожие элементы, но с другими названиями. Разработчику становится сложно сопоставлять элементы с кодом, и возникает необходимость все стандартизировать, чтобы не тратить время на ненужные разъяснения, когда дело просто в том, чтобы взять, внедрить и использовать.
  7. В компании есть продуктовый пул, и в какой-то момент возникает необходимость стандартизировать UI/UX. У каждого продукта своя команда дизайнеров и разработчиков. Нужно ли каждой команде разрабатывать свой собственный комплект пользовательского интерфейса? Иногда бывает. Затем внедрение дизайн-системы можно начинать со стороны дизайна, что приводит все к единому внешнему виду. В результате в коде может появиться несколько UI-китов из-за сопротивления в разных командах, но уже через пару итераций начинает формироваться единая компонентная база.

Эти описанные проблемы не перечислены в каком-либо определенном порядке или степени важности; любой из них может стать отправной точкой для создания дизайн-системы.

Этапы формирования дизайн-системы

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

  1. Распределяются человеческие и временные ресурсы.
  2. Формируются требования к стеку технологий, которые будут отвечать современным вызовам.
  3. Исходя из требований, выбирается стек. Появляются первые демо-версии каркасов проектов.
  4. Возникают первоначальные договоренности между командами разработчиков и дизайнеров — поиск общего языка, желание синхронизироваться.
  5. Рождается ядро ​​дизайн-системы, точнее сказать, UI-кит, так как процессы еще не до конца сформированы.
  6. Первые компоненты созданы.
  7. Компоненты тестируются в первой функции продукта, и в них вносятся коррективы.
  8. Происходит органическая разработка компонентов в дизайне и коде, с обзорами дизайна или без них.
  9. Появляется больше времени для размышлений о том, что было сделано и что в настоящее время нуждается в корректировке. Команды разработчиков и дизайнеров согласовывают свои подходы и наборы инструментов, чтобы двигаться вперед, в том числе:
  • Выявление и решение проблем.
  • Внедрение новых процессов (синхронизация — встречи о том, как дизайнеры создают дизайн, фронтенд-разработчики работают над фронтендом, QA тестирует фронтенд-часть приложения и как все взаимодействуют с дизайн-макетами.
  • Внедрение новых инструментов.

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

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

Этапы разработки дизайн-системы

Если углубиться в этот список, можно выделить следующие фазы развития:

Горячая фаза: когда компоненты претерпевают максимальное количество изменений в дизайне/коде во время их внедрения в конечный продукт. Эта фаза может длиться от нескольких месяцев (в среднем 6) до нескольких лет. Минимальная продолжительность, которую я испытал, составляет 3 месяца, а максимальная — 1,5 года. Это зависит от первоначальных договоренностей, опыта внутри команды разработчиков и бизнеса, который выделяет ресурсы, время и расставляет приоритеты.

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

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

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

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

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

Устранены недостатки в процессах, связанных с анализом проекта, например, как он проводится со стороны проекта, что и как они анализируют. Определены критические изменения дизайна и приоритеты. Устранено несоответствие между макетами дизайна и сжатыми сроками выпуска. Также решается вопрос о том, как процессы проектирования преобразуются в компоненты в Figma, или наоборот, когда дизайн не знает, как компоненты преобразуются в код.

Этап плато: создание новых страниц/функций/корректировок не требует серьезной переработки ключевых компонентов системы дизайна или требует лишь минимальных изменений. Возможны серьезные изменения в поведении компонентов. Например, переосмысление UI/UX, когда что-то оказывается неудобным и нуждается в переработке, или когда необходимо ввести новые компоненты с другим поведением. Время от времени создаются новые компоненты.

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

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

Во второй части этой монументальной статьи я рассказываю о том, как определить требования к продукту и, как следствие, требования к дизайн-системе, а также объясню, почему мы выбрали Mantine в качестве основы для нашей собственной дизайн-системы. Подписывайтесь и следите за обновлениями! Буду рад ответить на любые вопросы в комментариях.