Что разберём
1Что входит в библиотеку
В библиотеку попадает то, что нужно многим. То, что нужно одной команде, остаётся в её продукте.
Команда сайта просит добавить в библиотеку карточку дегустационного набора.
Команда кабинета — таблицу счетов.
Команда приложения — кнопку-переключатель «Подписаться на сорт», которая, кстати, нужна и сайту.
Что из этого — библиотека?
Критерии GOV.UK
В GOV.UK Design System предложение нового компонента проверяют по двум признакам:
- Полезен — есть свидетельства, что он нужен многим командам или сервисам.
- Не повторяет — в системе нет того же самого.
А перед публикацией — ещё по трём:
- Удобен — проверен на людях, в том числе на людях с инвалидностью.
- Согласован — собран из уже имеющихся стилей и компонентов.
- Универсален — подходит разным сервисам, которым он может понадобиться.
Три места для решения
- Библиотека — то, что нужно нескольким продуктам: поле поиска, кнопка, переключатель «Подписаться на сорт».
- Продукт — сборка из компонентов библиотеки для одной команды. Карточка дегустационного набора собирается из карточки сорта, чипов и кнопки в файле сайта.
- Разово — то, что встретится один раз: баннер распродажи. Это слои в макете.
Брэд Фрост называет эти три места компонентами системы, «рецептами» и «снежинками». А в книге «Atomic Design» советует считать новое разовым, пока похожая задача не появится у второй команды.
Проверьте себя на запросах команд «Лесной обжарки».
Поле поиска: есть в приложении, на сайте и в кабинете.
БиблиотекаНужно всем трём продуктам и устроено одинаково.
Карточка дегустационного набора — только на сайте, из карточки сорта, чипов и кнопки.
ПродуктНужна одной команде и собирается из того, что в библиотеке уже есть. Пусть живёт в файле сайта.
Баннер «Чёрная пятница» на главной сайта.
РазовоПоявится на неделю и уйдёт. Слои в макете.
Счётчик количества «− 2 +» в корзине приложения и сайта.
БиблиотекаДва продукта, одно поведение, и у него есть состояния: на нуле и на максимуме.
Таблица счетов в кабинете для офисов.
ПродуктСложная, но нужна одной команде. Если таблица понадобится второму продукту — тогда в библиотеку пойдут её части: строка, заголовок, сортировка.
Кнопка-переключатель «Подписаться на сорт» — для приложения и сайта.
БиблиотекаНужна двум продуктам. Проверьте только, не делает ли то же самое уже существующий компонент.
Иллюстрация к письму о дне рождения магазина.
РазовоОдно письмо, одна картинка.
2«Добавьте компонент» — как ответить
Отказывать — нормальная часть работы с библиотекой. Плохой отказ — без причины и без выхода.
Если брать в библиотеку всё, через год в ней будет три кнопки, два чипа и никто не будет понимать, какой из них нужен.
Если отказывать молча, команды перестанут спрашивать — и начнут рисовать своё.
О чём спросить, прежде чем ответить
- Кому ещё это нужно? Одна команда или несколько.
- Нет ли уже такого? Может, это вариант существующего компонента.
- Это компонент или сборка? Карточка набора — сборка из карточки и чипов.
- Кто будет его поддерживать? Компонент в библиотеке — это и состояния, и описание, и исправления.
Четыре ответа
Да, берём. Нужно нескольким продуктам, такого нет.
Вариантом существующего. Просят «оранжевую кнопку для акций». Если у неё своя роль — это вариант кнопки с именем по роли, а не новый компонент.
Сборкой в продукте. Карточку набора собирают в файле сайта из компонентов библиотеки.
Разово. Баннер остаётся слоями в макете.
О втором ответе спорят. Натан Кертис советует редкий случай не добавлять вариантом, а собирать из частей: частое настраивают свойствами, редкое собирают. Иначе у зрелого компонента панель свойств разрастается так, что её приходится листать.
Как написать отказ
Например:
«Карточку набора в библиотеку пока не берём: она нужна только сайту и собирается из карточки сорта и чипов. Соберите её в файле сайта. Если такая понадобится приложению — вернёмся к разговору, и я помогу перенести».
В ответе три части: решение, причина и что делать дальше.
3Два компонента об одном
Через год в библиотеке находятся «Тег» и «Чип»: оба — короткая подпись в рамке. Один делали для сайта, другой — для приложения.
Пока их два, каждая правка — двойная. А новый дизайнер выбирает наугад.
Как найти двойников
- Пройдите библиотеку по задачам, а не по названиям. «Показать короткий признак» — и рядом окажутся тег, чип и бейдж.
- Посмотрите аналитику библиотеки. В Figma она показывает, сколько у компонента экземпляров, в каких командах и файлах он стоит и сколько раз его отвязывали. Она есть на тарифах Organization и Enterprise.
- Обратите внимание на отвязки. Если экземпляр часто отвязывают, компонент чего-то не умеет, и рядом, скорее всего, появился самодельный двойник.
Как свести
- Сравните оба компонента: свойства, состояния, где стоят.
- Выберите основу — тот, что используют чаще и что лучше устроен.
- Добавьте в основу то, чего ей не хватает, вариантом или свойством.
- Пометьте второй устаревшим с указанием, чем заменить.
- Переведите места по списку и только потом уберите второй. Как — в следующем разделе.
| Что сравниваем | Тег | Чип |
|---|---|---|
| Где стоит | Сайт: признаки на карточке — «Новинка», «Без кофеина» | Приложение: фильтры каталога |
| Нажимается | Нет | Да: включает фильтр |
| Состояния | Только покой | Покой, наведение, фокус, выбран, неактивен |
| Решение | Это разные задачи. Тег — признак, чип — фильтр. Свести нужно не их, а два тега: «Тег» сайта и «Бейдж» приложения | |
Похожий вид — не повод сводить. Сводят то, что делает одно и то же.
4Изменение без поломки — по шагам
Правку библиотеки получают все, кто ею пользуется. Поэтому заметное изменение выпускают по шагам, а не одним движением.
В Figma обновление библиотеки не приходит в чужие файлы само. Владелец файла видит, что вышло обновление, сравнивает «было — стало» и принимает изменения по одному или все сразу.
Значит, после выпуска старое и новое ещё долго живут рядом. И команды должны знать, что делать.
- ПредупредитьЗа две недели до выпуска: что меняется, зачем, кого касается, что сделать и до какого числа.
- Выпустить новое рядом со старым«Тег» получает вариант «Размер=Малая», как у «Бейджа». «Бейдж» помечен устаревшим и указывает на замену.
- ПеревестиКоманды меняют экземпляры у себя. Вы смотрите по аналитике, сколько «Бейджей» осталось и где.
- Убрать староеКогда мест не осталось или наступила объявленная дата. Удаление — отдельный выпуск.
Шаг «перевести» не везде делают за команды. В ЮMoney сначала добивались, чтобы на новую версию перешли все, — это привело к напряжению, и теперь команды сами решают, когда обновляться. Плата за это — разные версии библиотеки в разных командах.
Как помечают устаревшее в больших системах
В Atlassian вывод из системы идёт в две фазы: сначала «намерение вывести» с предупреждением, потом «устарел». И правило: ничто из стабильной части системы не убирают без ясно объявленного срока.
В Primer, дизайн-системе GitHub, у устаревшего компонента есть описание, чем его заменить, а тому, кто его использует, показывается предупреждение.
Чего не делать
Не удаляйте компонент сразу. В Figma удаление главного компонента не убирает его экземпляры из чужих файлов. Они остаются — но без образца, и чинить их потом приходится руками.
Не предупреждайте после выпуска. «Вчера мы всё поменяли» — это не предупреждение, а новость.
5Версии и список изменений
Номер версии говорит команде, можно ли обновляться не глядя.
Многие библиотеки нумеруют выпуски по правилам семантического версионирования, semver. Номер из трёх чисел — например, 2.4.1.
- Первое число, мажорная версия, растёт, когда изменение несовместимо: что-то убрали или переименовали так, что старое перестанет работать.
- Второе, минорная, — когда добавили новое, ничего не сломав. Пометка «устарело» — тоже минорная версия.
- Третье, патч, — когда исправили ошибку, ничего не сломав.
В semver есть и правило про вывод устаревшего: прежде чем убрать что-то в мажорной версии, нужна хотя бы одна минорная, где это помечено устаревшим.
Дизайнерская библиотека в Figma не обязана нумеровать выпуски так же, как код. Но если компонент живёт и в коде, удобно, когда номера совпадают: разработчик и дизайнер говорят об одной версии.
Запись в списке изменений
Каждое изменение отвечает на четыре вопроса:
- что изменилось;
- кого это касается;
- что сделать;
- до какого числа.
Например:
2.0.0 · 10 ноября Убрано: «Бейдж». Касается приложения (38 мест). Что сделать: заменить на «Тег», Размер=Малая. Подписи переносятся сами, цвет фона — проверить на тёмных карточках. 1.6.0 · 27 октября Добавлено: у «Тега» вариант Размер=Малая. Устарело: «Бейдж» — используйте «Тег», Размер=Малая. Удалим в 2.0.0, 10 ноября. 1.5.1 · 20 октября Исправлено: у поля поиска радиус как у остальных полей.
6Найдите ошибки в выпуске библиотеки
Коллега выпустил новую версию библиотеки и написал об этом в общий чат. Пять мест в сообщении подведут команды.
Нажимайте на строки, которые стоило написать или сделать иначе. Нормальные строки тоже можно нажать.
- Номер 1.5.0.Иначе. В выпуске удалён компонент и переименовано свойство — это несовместимые изменения, мажорная версия: 2.0.0. По номеру 1.5.0 команды решат, что обновиться можно не глядя.
- «Тег» удалён сегодня.Иначе. Удаление без предупреждения и без минорной версии, где «Тег» помечен устаревшим. И проверьте замену: тег — признак, чип — фильтр, задачи у них разные.
- Новый вариант чипа.Нормально. Добавили, ничего не сломав, — минорное изменение.
- «Разберётесь».Иначе. Переименование свойства — заметное изменение. Нужна запись: что изменилось, кого касается, что проверить в своих файлах и до какого числа.
- Исправлен радиус поля поиска.Нормально. Исправление без поломки — патч.
- «Кнопка акции» отдельным компонентом.Иначе. Это та же кнопка другого цвета. Если у неё своя роль — вариант кнопки с именем по роли. Если нет — не нужна вовсе.
- Удалим завтра.Иначе. Один день — не срок для перевода. Сначала проверить по аналитике, где эти компоненты ещё стоят, объявить дату и дать время.
- Вопросы — в канал.Нормально. Понятно, куда спрашивать и когда ждать ответа.
Все пять найдены. Номер не тот, удаление без предупреждения, «разберётесь», лишний компонент и срок в один день. Каждая из них кончается тем, что команды чинят свои макеты руками.
7Задание
Проведите одно изменение в общей библиотеке по шагам: предупредить, выпустить, перевести, убрать. Запишите, что пошло не так.
Часть 1 · Выбрать и подготовить, 1 день
- Выберите изменение: свести два компонента об одном, переименовать свойство или убрать то, чем не пользуются. Если своей библиотеки нет, возьмите «Бейдж» и «Тег» из раздела 3 и распишите все шаги на бумаге.
- Посчитайте места, где стоит то, что изменится: по аналитике библиотеки или поиском по файлам.
- Напишите предупреждение по шаблону ниже и отправьте до выпуска.
ИЗМЕНЕНИЕ: ______________________ Дата: __.__.____ ЧТО МЕНЯЕТСЯ И ЗАЧЕМ: ______________________ КОГО КАСАЕТСЯ (команды, число мест): ______________________ ЧТО СДЕЛАТЬ КОМАНДАМ: ______________________ ШАГИ предупредили: __.__ выпустили новое рядом со старым: __.__ (версия ____) перевели: __ из __ мест убрали старое: __.__ (версия ____) ЧТО ПОШЛО НЕ ТАК ______________________ что сделать иначе в следующий раз: ______________________
Часть 2 · Выпустить и перевести, 1–2 недели
- Выпустите новое рядом со старым. Старое пометьте устаревшим и укажите замену.
- Помогите командам перевести места. Следите по аналитике, сколько осталось.
- Отвечайте на вопросы и записывайте их: каждый вопрос — дыра в предупреждении.
Часть 3 · Убрать и записать, 1 день
- Уберите старое отдельным выпуском, когда мест не осталось или наступила объявленная дата.
- Спросите команды, пришлось ли им что-то чинить руками.
- Заполните «что пошло не так» в шаблоне.
Что должно получиться
- Предупреждение, отправленное до выпуска.
- Два выпуска: с пометкой «устарело» и с удалением — и записи о них в списке изменений.
- Заполненный шаблон с разделом «что пошло не так».
План работы: день на подготовку, одна–две недели на перевод, день на удаление и разбор.
Частые сложности
- «Команды не переходят, пока не заставишь». Объявленная дата и список мест помогают больше, чем напоминания. Пройдите по списку вместе с командой.
- «Аналитики нет: тариф не тот». Тогда поиск по файлам и опрос команд: «где у вас стоит «Бейдж»?». Медленнее, но работает.
- «Изменение маленькое, зачем столько шагов». Не нужно. Исправление без поломки — патч и строка в списке изменений. Шаги — для того, что ломает чужие макеты.
- «Отказали команде, теперь она делает своё». Вернитесь к ответу: была ли в нём причина и выход? Помогите собрать нужное в продукте.
8Чек-лист и ошибки
Библиотека держится, если
- В ней то, что нужно нескольким продуктам и не повторяет имеющееся
- Отказ в новом компоненте — с причиной и выходом
- Двойники найдены по задачам и сведены в один
- Заметное изменение идёт по шагам: предупредить, выпустить рядом, перевести, убрать
- Устаревшее помечено и указывает на замену
- Номер версии говорит, ломает ли выпуск
- У каждой записи в списке изменений: что, кого касается, что сделать, до когда
Что мешает
- Брать всё подряд. Через год три кнопки и никто не знает, какую взять.
- Отказывать молча. Команды перестают спрашивать и рисуют своё.
- Удалить сразу. Экземпляры остаются без образца и чинятся руками.
- Предупредить после. Это не предупреждение, а новость.
- Сводить по виду, а не по задаче. Признак и фильтр становятся одним компонентом, который не подходит ни туда, ни сюда.
9Три ступени темы
На первых ступенях учились собирать компонент и продумывать его состояния. Здесь — вести библиотеку, которой пользуются другие: решать, что в неё входит, и менять её, не ломая чужие макеты.
| Ступень | Что нужно уметь | Как проверить результат |
|---|---|---|
| Junior | Отличать повторяющееся от разового; собирать компонент с вариантами; называть варианты словами; проверять на короткой и длинной подписи; заменять копии экземплярами | Изменение вида элемента во всём макете делается в одном месте |
| Middle | Продумывать все состояния: наведение, фокус, нажатие, неактивное, загрузку и ошибку; отличать неактивное от загрузки; описывать, когда компонент применять и когда нет | Разработка собрала компонент по макету и не спросила ни про одно состояние |
| Senior — этот урок | Решать, что входит в систему; менять библиотеку, не ломая чужие макеты; отказывать в лишних компонентах с причиной; сводить два компонента об одном; предупреждать об изменениях заранее | После изменения ни один чужой макет не потребовал ручной починки |
Что почитать дальше
- Раскатываем дизайн-систему: от хаоса к процессамРуководитель фронтенда ЮMoney о дизайн-системе на 70 с лишним микросервисов: как свели разрозненные библиотеки в одну, стали считать использования каждого компонента и перед большим изменением оценивать, во что обойдётся переход командам. В отличие от урока, команды в итоге сами решают, когда обновляться.
- Design system components, recipes, and snowflakesБрэд Фрост делит компоненты на три уровня: общие компоненты системы, рецепты (сборки из них внутри одного продукта) и снежинки — разовые решения. Отсюда три ответа на «добавьте компонент». Специфичное держат в продукте и переносят в систему, когда оно пошло в ход широко. На английском, 2021.
- A Design System Governance ProcessПроцесс Брэда Фроста по шагам: команда не нашла компонент → разговор с командой системы → готовое решение, снежинка в продукте или работа в системе → прототип, проверки, документация, список изменений, новая версия. Десять шагов, и автор сам признаёт, что это долго. На английском, 2019.
- Maintaining Design SystemsПятая глава «Atomic Design» о поддержке системы: новый шаблон считать разовым, пока он не понадобится второй команде, до вывода старого спросить тех, кто им пользуется, и предложить замену. Книга 2016 года, часть инструментов устарела. Глава длинная, для урока нужен раздел «Making changes to patterns».
- Configuration CollapseНатан Кертис о том, как свойства и варианты компонента разрастаются до «полосы прокрутки позора» и почему со слотами в Figma их стоит сокращать: частое — настраивать, редкое — собирать из частей. В отличие от урока, для редкого случая он советует не новый вариант, а сборку. На английском, 2026.