Bloom Design System: Релизный цикл дизайн-системы

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

Статья сделана в рамках разработки собственной дизайн-системы, которую делают два дизайнера: Валя Джазиков и Дмитрий Бамбуров.

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

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

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

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

У команды дизайн-системы такой список закрепляется в этапе аудита, чтобы имплементация таких компонентов/токенов/UI-поведения были зафиксированы и утверждены.

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

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

При этом измения UI-KIT'a должны быть не влияющими на экраны, так как дизайнеры уже начали проектировать экраны и не всегда могут уловить изменения компонентов.

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

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