Семантическое версионирование ДС, простой гайд для дизайнера

Обложка
Обложка

Нет понимания как работать с изменениями ДС? давайте разбираться вместе.

Что такое семантическое версионирование?

Семантическое версионирование (Semantic Versioning, SemVer) — это система версионирования, которая помогает прозрачно отслеживать изменения и их влияние на проект.

Хорошо, как это мне поможет?

  • Будет понимание какой компонент в беклоге, а какой готов в дизайне или в коде;
  • Прозрачность статусов работы по каждому компоненту;
  • Как работать с изменениями и компонентом, который в процессе создания у разработки;
  • Минимизировать хаос и разногласия между дизайнерами и разработчиками;
  • Синхронизировать дизайн и код;
  • Ускоряется масштабирование и развитие ДС;
  • Самое главное — появляется прозрачность для разработки и других дизайнеров.

Как это применяется в дизайн системе?

Доска для разработки

Доска канбан
Доска канбан

Создаем доску с этапами разработки компонента:

  1. Бэклог;
  2. Дизайн компонента;
  3. Ревью лидом ДС;
  4. Готово к разработке;
  5. Разработка;
  6. Тестирование;
  7. Ревью дизайнерами;
  8. Готово (архив);

По этой доске задачи двигаются от идеи до готового компонента. Рассмотрим два сценария: создание нового компонента и обновление существующего.

Сценарий 1: Новый компонент

  1. Создается задача в бэклоге;
  2. Дизайнер собирает компонент в Figma, присваивает ему версию 1.0.0;
  3. Лид дизайн-системы проводит ревью и двигает задачу в “Готово к разработке;.
  4. Компонент уходит в разработку, тестируется и тд;
  5. После тестирования — ревью финальной версии дизайнером. Если всё ок — ставим статус “Готово”;

Сценарий 2: Если объект готов в коде

Тут есть два исхода событий.

Вариант А — компонент уже есть в коде:

  1. Создаем задачу на изменение;
  2. Вносим правки в компонент (в бранче или сразу — на ваше усмотрение);
  3. Перемещаем задачу по канбан-доске;
  4. В changelog фиксируем изменения: версию, описание правок, ссылку на задачу;
  5. В задаче также фиксируем актуальную версию, ссылку на changelog в figma;

Вариант Б — разработка ещё не начиналась:

  1. Вносим изменения в компонент в Figma;
  2. Повышаем версию компнонента в задаче (просто переименовываем с 1.1.0 до 1.2.0);
  3. Документируем изменения в changelog и задаче;

Доступность изменений для продуктовых дизайнеров

Есть два подхода публикации обновлённых компонентов в библиотеке:

Публикуем сразу после внесения изменений в Figma и понимаем что:

  • Дизайнеры получат доступ к обновлению сразу;
  • Возможны расхождения между дизайном и кодом в скрости создния объектов;
  • SemVer помогает отслеживать актуальность;

Публикуем только после релиза в коде, но понимаем что:

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

Часто выбирают комбинированный подход: minor-обновления пускают сразу, major — синхронизируют с кодом.

Отслеживание версий в Storybook или Figma

Каждому компоненту в Storybook и в figma можно присваивать версию (например, Button v2.1.0). Это позволяет разработчику и дизайнеру понимать, какую именно версию компонента он сейчас видит.

Пример таблицы версионирования
Пример таблицы версионирования

Ну хорошо, а как отслеживать изменения?

Пример ведения журнала изменений 
Пример ведения журнала изменений 

Ведите журнал изменений прямо в Figma или в сопроводительных документах (например, Confluence, Notion). Каждый раз при внесении изменений, которые требуют обновления версии, документируйте:

  • Номер версии;
  • Краткое описание внесённых изменений и их влияния;
  • Дата обновления.

В Figma можно создать специальную страницу или фрейм для документирования этих изменений. Уведомляйте всех пользователей об изменениях, особенно если изменения являются значительными (MAJOR или MINOR).

Работа с несколькими платформами (Web / App)

Если ДС используется для нескольких платформ:

  1. Изменил компонент в Web — обязательно синхронизируй изменения с App;
  2. У одинаковых компонентов в Web и App версии должны совпадать;

Примечание

Можно отказаться от жёсткого семантического версионирования, если команда:

  • Чётко понимает этапы работы;
  • Активно коммуницирует по изменениям;
  • Ведёт документацию по статусам компонентов;

Но лично я считаю, что даже простая версия x.y.z позволяет держать макеты в полном порядке, особенно в крупных командах и при долгих проектах.

Итог

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

🚀 Подписывайтесь, чтобы узнать то, чего не знают другие! Уникальные инсайты и редкие темы для вашего роста и вдохновения! 💡

Начать дискуссию