Дизайн-система проекта: подготовка, токены и компоненты

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

Система не ограничивается файлом Figma с кнопками и полями. Если в проекте есть только визуальная библиотека, но нет правил применения, реализации в коде, документации, ответственных и процесса обновления, команда получила UI-kit. Он может быть полезным, но не решает всех задач дизайн-системы.

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

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

Что такое дизайн-система

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

• принципов продукта и интерфейса;
• визуальных основ;
• дизайн-токенов;
• компонентов;
• паттернов взаимодействия;
• шаблонов страниц;
• правил контента;
• требований доступности;
• компонентов в коде;
• документации;
• процессов управления изменениями.

Система отвечает не только на вопрос «как выглядит кнопка», но и на вопросы:

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

Чем дизайн-система отличается от UI-kit

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

Чем дизайн-система отличается от брендбука

Брендбук описывает визуальную и смысловую идентичность организации:

• логотип;
• фирменные цвета;
• типографику;
• изображения;
• тон коммуникации;
• правила использования бренда;
• рекламные носители.

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

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

Фирменный синий цвет ещё не определяет, как должна работать кнопка, когда использовать основной вариант и каким будет фокус при навигации с клавиатуры.

Чем дизайн-система отличается от руководства по стилю

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

Когда проекту нужна дизайн-система

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

Признаки необходимости

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

Когда полноценная система может быть избыточной

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

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

Какие задачи решает дизайн-система

Согласованность

Одинаковые элементы получают одинаковый внешний вид и поведение.

Скорость работы

Команда собирает интерфейс из проверенных компонентов вместо повторного проектирования типовых решений.

Качество

Исправления доступности, адаптивности и поведения внедряются на уровне компонента и распространяются на все места использования.

Масштабирование

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

Онбординг

Новый сотрудник получает не набор разрозненных макетов, а документированные правила и компоненты.

Синхронизация дизайна и разработки

Названия, варианты и состояния компонентов согласуются между макетами и кодом.

Управление брендом

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

Снижение технического долга

Команда постепенно заменяет случайные локальные решения общими компонентами.

Что дизайн-система не решает

Она не может автоматически:

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

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

Этап 1. Определите цели и границы

Начинать следует не с рисования библиотеки, а с описания проблем.

Возможные цели

• сократить время создания типовых экранов;
• уменьшить число визуальных расхождений;
• объединить несколько продуктов;
• поддержать несколько брендов;
• ускорить разработку;
• повысить доступность;
• создать единый стандарт форм;
• упростить редизайн;
• снизить количество локальных CSS-решений;
• подготовить продукт к масштабированию.

Определите область системы

Она может охватывать:

• один сайт;
• веб-приложение;
• несколько продуктов;
• мобильные приложения;
• внутренние системы;
• маркетинговые страницы;
• email-шаблоны;
• печатные материалы;
• все цифровые продукты бренда.

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

Этап 2. Определите заинтересованные стороны

Дизайн-система затрагивает не только дизайнеров.

Возможные участники

• продуктовый дизайнер;
• UX-исследователь;
• frontend-разработчик;
• разработчик мобильного приложения;
• архитектор;
• продуктовый менеджер;
• контент-дизайнер;
• специалист по доступности;
• QA-инженер;
• бренд-команда;
• маркетинг;
• технический писатель;
• руководители продуктовых команд.

Что согласовать

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

Этап 3. Проведите аудит интерфейса

Аудит помогает понять фактическое состояние продукта и выбрать первые компоненты.

Соберите материалы

• актуальные страницы сайта;
• мобильные экраны;
• макеты;
• компоненты Figma;
• CSS и frontend-библиотеки;
• Storybook;
• старые руководства;
• брендбук;
• результаты аудита доступности;
• обращения пользователей;
• список известных дефектов.

Проведите визуальную инвентаризацию

Сгруппируйте существующие варианты:

• кнопок;
• полей;
• селекторов;
• таблиц;
• карточек;
• уведомлений;
• заголовков;
• ссылок;
• модальных окон;
• навигации;
• пагинации;
• иконок;
• отступов;
• теней;
• цветов.

Фиксируйте различия

Оцените частоту и критичность

Для каждого элемента полезно определить:

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

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

Этап 4. Сформулируйте принципы

Принципы помогают принимать решения, которых ещё нет в документации.

Примеры принципов

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

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

Этап 5. Создайте визуальные основы

До компонентов необходимо определить фундаментальные правила.

Цвет

Система цветов включает:

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

Цветовые значения должны сопровождаться назначением. Название blue-500 описывает палитру, но не объясняет, где цвет используется. Семантический токен color-action-primary-background передаёт роль.

Типографика

Определите:

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

Типографическая роль должна быть связана со смыслом, а не с конкретным тегом. Один стиль может использоваться для нескольких элементов, но структура HTML обязана сохранять семантику.

Отступы

Шкала отступов помогает избежать случайных значений:

space-0: 0
space-1: 4px
space-2: 8px
space-3: 12px
space-4: 16px
space-5: 24px
space-6: 32px
space-7: 48px
space-8: 64px

Это только пример. Шаг выбирается по типографике, плотности и платформе проекта.

Сетка

Опишите:

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

Радиусы

Слишком большое количество радиусов создаёт визуальный шум. Обычно достаточно небольшой шкалы, связанной с типами компонентов.

Тени и уровни

Определите, когда элемент действительно находится над другой поверхностью. Тень не должна добавляться каждой карточке просто потому, что без неё блок кажется недостаточно «дизайнерским».

Иконки

Зафиксируйте:

• стиль;
• сетку;
• толщину линий;
• размеры;
• правила заливки;
• доступные подписи;
• цвет;
• использование декоративных и функциональных иконок.

Движение

Для анимации определяются:

• длительности;
• кривые;
• типы переходов;
• условия использования;
• реакция на prefers-reduced-motion;
• поведение загрузки;
• анимация появления и исчезновения.

Этап 6. Спроектируйте архитектуру токенов

Дизайн-токен — именованное значение, которое хранит визуальное или функциональное решение: цвет, размер, отступ, радиус, длительность или другое свойство.

Формат DTCG предназначен для обмена токенами между инструментами и кодовыми базами. Спецификация определяет структуру значений, типы, группы, ссылки и описания, но не диктует конкретную стратегию именования каждой команде.

Уровень 1. Базовые токены

Хранят исходные значения:

color.blue.500
color.gray.100
size.4
radius.2
duration.fast

Уровень 2. Семантические токены

Описывают назначение:

color.text.primary
color.text.secondary
color.surface.page
color.surface.card
color.border.default
color.action.primary
color.feedback.error

Уровень 3. Компонентные токены

Применяются к конкретному компоненту:

button.primary.background.default
button.primary.background.hover
button.primary.text.default
input.border.focus
alert.error.icon

Зачем нужны уровни

Без семантического слоя компонент зависит от конкретного цвета:

button background = blue-500

С семантическим слоем:

button background = action-primary
action-primary = blue-500

При смене бренда или темы меняется ссылка семантического токена, а компонент сохраняет назначение.

Как называть токены

Схема должна быть понятна дизайнерам и разработчикам.

Возможная структура:

категория.роль.вариант.состояние

Примеры:

color.text.primary
color.action.primary.background.hover
space.component.button.inline
radius.control.medium

Хорошее имя

• объясняет назначение;
• не зависит от конкретного значения;
• следует общей структуре;
• не содержит случайных сокращений;
• подходит дизайну и коду;
• допускает расширение.

Проблемные имена

main-blue
new-gray
button-color-final
spacing-big
card-shadow-2-fixed

Такие имена отражают историю изменений, а не роль значения.

Переменные и режимы Figma

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

Возможные коллекции

• базовые цвета;
• семантические цвета;
• размеры и отступы;
• типографика;
• компоненты;
• темы;
• бренды;
• платформы.

Не создавайте режим для каждого исключения

Режимы полезны для системных контекстов. Если отдельная страница требует случайного цвета, это не обязательно новый mode. Иначе коллекция превращается в таблицу, где каждый новый столбец объясняет одно старое решение, которое никто уже не решается удалить.

Этап 7. Определите модель компонентов

Компонент должен решать повторяющуюся задачу и иметь устойчивое поведение.

Анатомия компонента

Для каждого компонента укажите:

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

Варианты

Вариант создаётся, если изменяется назначение или устойчивое визуальное представление:

• primary;
• secondary;
• tertiary;
• danger;
• compact;
• с иконкой;
• без иконки.

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

Состояния

Минимальный перечень зависит от компонента:

• default;
• hover;
• focus;
• active;
• selected;
• disabled;
• loading;
• error;
• success;
• empty;
• read-only.

Размеры

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

Контент

Опишите:

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

Atomic Design: полезная модель, но не обязательная архитектура

Atomic Design предлагает рассматривать интерфейс на уровнях:

• атомы;
• молекулы;
• организмы;
• шаблоны;
• страницы.

Модель помогает обсуждать композицию интерфейса, но её не обязательно превращать в структуру папок, названия всех компонентов и организационную религию.

Когда подход полезен

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

Когда возникают проблемы

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

Практичнее называть компоненты по роли: Button, SearchField, ProductCard, SiteHeader. Классификация должна помогать команде, а не создавать новый предмет для собраний.

Этап 8. Начните с базовых компонентов

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

• Button;
• Link;
• Icon;
• TextField;
• Textarea;
• Select;
• Checkbox;
• Radio;
• Switch;
• FormField;
• Alert;
• Badge;
• Tooltip;
• Modal;
• Dropdown;
• Tabs;
• Breadcrumbs;
• Pagination;
• Table;
• Card;
• LoadingIndicator;
• EmptyState.

Необязательно разрабатывать всё сразу. Для первой версии выберите компоненты, которые:

• часто используются;
• сильно различаются;
• создают ошибки;
• влияют на ключевые сценарии;
• требуются нескольким командам.

Пример спецификации кнопки

Компонент и паттерн: в чём разница

Компонент является переиспользуемым элементом интерфейса. Паттерн описывает решение более широкой пользовательской задачи.

Компоненты

• кнопка;
• поле;
• карточка;
• диалог;
• таблица;
• вкладки.

Паттерны

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

Одних компонентов недостаточно. Две команды могут использовать одинаковые кнопки и поля, но собирать из них совершенно разные и противоречивые сценарии.

Шаблоны страниц

Шаблон задаёт типовую композицию:

• страница списка;
• страница детали;
• форма создания;
• панель управления;
• страница настроек;
• страница статьи;
• страница услуги;
• каталог;
• карточка товара;
• состояние ошибки.

Шаблон не должен жёстко фиксировать содержимое. Он определяет структуру, зоны и правила адаптации.

Этап 9. Встройте доступность в систему

Доступность должна учитываться внутри компонентов, а не исправляться отдельно на каждой странице.

Контраст

WCAG 2.2 требует для обычного текста контраст не менее 4,5:1, а для крупного текста — не менее 3:1. Значимые графические элементы и границы элементов управления обычно должны иметь контраст не менее 3:1 относительно соседних цветов.

Клавиатура

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

Размер области действия

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

Семантика

Документация должна указывать:

• какой HTML-элемент использовать;
• какое доступное имя требуется;
• как связать label и поле;
• как сообщать ошибку;
• когда нужен ARIA-атрибут;
• какие клавиши поддерживаются;
• как управляется фокус;
• как озвучивается загрузка.

Не заменяйте семантику ARIA

Кнопку следует реализовывать как <button>, а ссылку — как <a>. Добавление роли к произвольному <div> требует вручную воспроизводить клавиатурное поведение и состояния.

Проверяйте изменение текста

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

Этап 10. Свяжите Figma и код

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

Что должно совпадать

• название компонента;
• назначение;
• варианты;
• размеры;
• состояния;
• токены;
• анатомия;
• правила содержимого;
• адаптивность;
• доступность;
• статус готовности.

Пример соответствия

Не копируйте API кода в Figma буквально

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

Токены в коде

Токены могут преобразовываться в:

• CSS Custom Properties;
• SCSS-переменные;
• JavaScript или TypeScript;
• JSON;
• ресурсы Android;
• ресурсы iOS;
• настройки других платформ.

Пример CSS:

:root {
    --color-text-primary: #20242a;
    --color-surface-page: #ffffff;
    --space-control-inline: 1rem;
    --radius-control: 0.375rem;
}

.button {
    color: var(--color-action-primary-text);
    background: var(--color-action-primary-background);
    padding-inline: var(--space-control-inline);
    border-radius: var(--radius-control);
}

Источник истины для токенов

Команда должна определить, где создаются и утверждаются изменения:

• Figma;
• репозиторий токенов;
• специализированная платформа;
• комбинированный процесс.

Если дизайнер меняет переменную в Figma, а разработчик независимо меняет CSS, система быстро расходится. Нужен утверждённый процесс синхронизации, ревью и публикации.

Этап 11. Создайте кодовую библиотеку компонентов

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

Библиотека должна учитывать

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

Не прячьте всю логику внутри компонента

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

Storybook и документация компонентов

Storybook позволяет разрабатывать компоненты отдельно от приложения. Каждая story описывает определённое состояние компонента, а документация может включать свойства, примеры, инструкции и тесты. Такой подход особенно полезен для редких состояний, которые сложно воспроизвести внутри всего продукта.

Какие stories подготовить

• основной вариант;
• все визуальные варианты;
• размеры;
• длинный текст;
• минимальное содержимое;
• ошибка;
• loading;
• disabled;
• пустое состояние;
• мобильная ширина;
• тёмная тема;
• локализация;
• клавиатурный сценарий.

Storybook не заменяет документацию назначения. Демонстрация двадцати вариантов кнопки не объясняет, какой из них выбрать.

Этап 12. Подготовьте документацию

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

Структура страницы компонента

1. Название.
2. Краткое назначение.
3. Когда использовать.
4. Когда не использовать.
5. Анатомия.
6. Варианты.
7. Размеры.
8. Состояния.
9. Поведение.
10. Правила содержимого.
11. Адаптивность.
12. Доступность.
13. Примеры.
14. Ошибочные примеры.
15. API кода.
16. Связанные компоненты.
17. История изменений.

Документируйте причины

Фраза «используйте primary-кнопку только один раз» должна объяснять область применения: одну основную кнопку в конкретной группе действий, форме или модальном окне. Иначе правило будет либо нарушаться, либо применяться ко всей странице без смысла.

Добавляйте отрицательные примеры

Примеры «не делайте так» помогают понять границы:

• не размещайте две основные кнопки рядом;
• не используйте tooltip для обязательной информации;
• не заменяйте label placeholder;
• не скрывайте ошибку только цветом;
• не используйте ссылку для отправки формы;
• не открывайте модальное окно внутри другого без необходимости.

Документация контента

Компонент зависит от текста не меньше, чем от цвета.

Опишите

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

Пример сообщения об ошибке

Слабый вариант:

Ошибка 422

Более полезный:

Не удалось отправить форму. Проверьте обязательные поля и повторите попытку.

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

Этап 13. Организуйте управление системой

Система требует владельцев и процесса принятия решений.

Централизованная модель

Отдельная команда создаёт и поддерживает систему.

Преимущества:

• единое качество;
• понятная ответственность;
• согласованный план развития.

Риски:

• отрыв от продуктовых команд;
• очередь запросов;
• медленная реакция;
• ощущение навязанной библиотеки.

Распределённая модель

Компоненты развиваются участниками разных команд.

Преимущества:

• близость к реальным задачам;
• больше участников;
• быстрое появление решений.

Риски:

• расхождения;
• неравномерное качество;
• неясная ответственность;
• сложное ревью.

Смешанная модель

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

Роли

Даже небольшая система должна определить обязанности.

В небольшой команде один человек может совмещать несколько ролей. Важно не количество должностей, а наличие ответственности.

Процесс добавления компонента

1. Команда фиксирует повторяющуюся проблему.
2. Проверяет, нельзя ли использовать существующий компонент.
3. Собирает сценарии и требования.
4. Проектирует решение.
5. Проверяет доступность.
6. Создаёт прототип.
7. Проводит дизайн- и code-review.
8. Добавляет документацию.
9. Тестирует в реальном продукте.
10. Публикует версию.
11. Собирает обратную связь.

Критерии системного компонента

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

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

Версионирование

Изменения должны быть предсказуемыми.

Виды изменений

• исправление дефекта;
• добавление варианта;
• новое состояние;
• изменение токена;
• устаревание свойства;
• удаление компонента;
• изменение API;
• переработка поведения.

Breaking change

Ломающее изменение требует действий от потребителей:

• переименование свойства;
• удаление варианта;
• изменение структуры DOM;
• изменение поведения;
• удаление токена;
• изменение обязательных параметров.

Для него нужны:

• описание;
• причина;
• план миграции;
• срок поддержки старого варианта;
• пример обновления;
• ответственный.

Changelog

Журнал изменений сообщает:

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

Запись «обновили кнопки» недостаточна. Потребителю нужно понимать, изменились ли размеры, цвета, API или только внутренняя реализация.

Deprecated-компоненты

Компонент не следует удалять внезапно. Процесс может включать:

1. объявление устаревшим;
2. описание замены;
3. предупреждение в документации;
4. вывод уведомления разработчику;
5. период миграции;
6. удаление в следующей крупной версии.

Этап 14. Организуйте тестирование

Визуальное тестирование

Проверяет неожиданные изменения внешнего вида.

Компонентные тесты

Проверяют свойства, события и состояния в изоляции.

Интеракционные тесты

Проверяют сценарии:

• открытие меню;
• выбор элемента;
• отправку формы;
• закрытие диалога;
• навигацию клавиатурой;
• появление ошибки.

Тесты доступности

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

Кроссбраузерное тестирование

Особенно важно для:

• форм;
• select;
• диалогов;
• position: sticky;
• таблиц;
• скролла;
• автозаполнения;
• мобильных браузеров.

Тестирование содержимого

Проверьте:

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

Этап 15. Подготовьте первую версию

Первая версия не должна охватывать все возможные компоненты.

Минимальный состав

• цели и принципы;
• цветовые токены;
• типографика;
• отступы;
• сетка;
• базовые формы;
• кнопки и ссылки;
• уведомления;
• документация;
• кодовая реализация критичных компонентов;
• процесс изменений;
• ответственные.

Выберите пилот

Пилотный раздел должен:

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

Этап 16. Внедряйте постепенно

Полная одновременная замена интерфейса редко оправдана.

Стратегии миграции

• новые страницы создаются только на системе;
• старые компоненты заменяются при изменении раздела;
• сначала мигрируются критические формы;
• выполняется поэтапная замена по компонентам;
• обновляется один продукт, затем остальные;
• старые и новые компоненты временно сосуществуют.

Не скрывайте стоимость миграции

Переход требует:

• разработки;
• тестирования;
• обновления макетов;
• изменения документации;
• обучения;
• исправления регрессий;
• поддержки нескольких версий.

Как измерять пользу

Метрики выбираются из целей системы.

Скорость

• время создания типового экрана;
• время разработки;
• срок от макета до релиза;
• время онбординга;
• число повторных согласований.

Использование

• доля экранов на системных компонентах;
• количество продуктов-потребителей;
• число установок новой версии;
• доля устаревших компонентов;
• частота обращений к документации.

Качество

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

Обратная связь команды

• удобство поиска компонента;
• понятность документации;
• скорость получения ответа;
• доверие к библиотеке;
• сложность внесения изменений.

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

Как поддерживать систему

Регулярный аудит

Проверяйте:

• устаревшие компоненты;
• неиспользуемые варианты;
• расхождения с кодом;
• дубли;
• новые паттерны в продуктах;
• ошибки доступности;
• актуальность документации;
• зависимости;
• совместимость.

Канал обратной связи

Команда должна знать, куда сообщить:

• об ошибке;
• о недостающем варианте;
• о проблеме документации;
• о предложении компонента;
• о сложностях миграции.

План развития

Backlog системы может включать:

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

Многоуровневая система для нескольких брендов

Если организация поддерживает несколько продуктов, полезно разделить:

• общие фундаментальные токены;
• семантические правила;
• брендовые темы;
• платформенные компоненты;
• продуктовые расширения.

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

Система для нескольких платформ

Веб, iOS и Android не обязаны выглядеть идентично. Общими могут быть:

• бренд;
• принципы;
• семантические токены;
• термины;
• статусы;
• основные паттерны.

Платформенными остаются:

• навигация;
• системные компоненты;
• жесты;
• размеры;
• поведение клавиатуры;
• анимация;
• нативные возможности.

Единая система не означает одинаковые пиксели. Она означает согласованную логику с учётом платформы.

Дизайн-система для небольшого сайта

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

Достаточный минимум

• цветовые переменные;
• типографическая шкала;
• контейнер и сетка;
• шкала отступов;
• кнопки;
• формы;
• карточки;
• таблицы;
• уведомления;
• состояния;
• правила мобильной версии;
• комментарии или краткая документация.

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

Типичные ошибки

Система создаётся без проблемы

Команда начинает с библиотеки, не определив цели и пользователей.

Копирование чужой системы

Компоненты крупной платформы переносятся в проект с другой аудиторией, технологиями и задачами.

Слишком большой объём первой версии

Команда годами проектирует идеальную систему, пока продукт продолжает развиваться отдельно.

Слишком ранняя универсализация

Один случай использования превращается в компонент с десятками параметров «на будущее».

UI-kit называется системой

Есть макеты, но нет кода, документации и процессов.

Кодовая библиотека создаётся без дизайнеров

Компоненты технически переиспользуются, но визуальные и UX-правила остаются несогласованными.

Figma и код имеют разные названия

Передача макета требует постоянного перевода между двумя словарями.

Нет владельца

Ошибки известны всем, но обновления не входят ни в чьи обязанности.

Компоненты нельзя расширять

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

Любое исключение запрещено

Система становится препятствием для новых сценариев.

Любое исключение разрешено

Система перестаёт что-либо стандартизировать.

Документация показывает только внешний вид

Не объясняются назначение и ограничения.

Не описаны состояния

Разработчик самостоятельно придумывает loading, error и disabled.

Доступность проверяется после разработки

Исправления требуют изменения API и структуры компонента.

Нет миграционного плана

Новая библиотека существует рядом со старым продуктом, но доля использования не растёт.

Система оценивается по числу компонентов

Команда создаёт всё больше элементов, не проверяя использование и качество.

Пошаговый план подготовки

1. Определить проблемы проекта.
2. Согласовать цели.
3. Ограничить первую область применения.
4. Назначить ответственных.
5. Провести аудит интерфейса и кода.
6. Сформулировать принципы.
7. Создать визуальные основы.
8. Определить архитектуру токенов.
9. Согласовать названия между дизайном и кодом.
10. Выбрать приоритетные компоненты.
11. Описать анатомию, состояния и правила.
12. Реализовать компоненты в Figma.
13. Реализовать критичные компоненты в коде.
14. Добавить тесты.
15. Подготовить документацию.
16. Запустить пилот.
17. Собрать обратную связь.
18. Исправить архитектурные проблемы.
19. Опубликовать первую версию.
20. Начать поэтапную миграцию.
21. Измерять использование и качество.
22. Поддерживать систему как продукт.

Чек-лист перед началом

• Определены проблемы, которые должна решить система.
• Понятна область первой версии.
• Определены платформы.
• Известны команды-потребители.
• Назначен владелец.
• Есть участник со стороны разработки.
• Есть время на поддержку после запуска.
• Проведён аудит текущего интерфейса.
• Собраны существующие библиотеки.
• Определены наиболее частые компоненты.
• Найдены основные расхождения.
• Согласованы продуктовые принципы.
• Определён источник истины.
• Выбран пилотный проект.
• Определены показатели результата.

Чек-лист токенов

• Определены базовые значения.
• Создан семантический слой.
• Компонентные токены используются только при необходимости.
• Имена передают назначение.
• Нет названий, зависящих от случайного цвета.
• Есть описания токенов.
• Темы не дублируют структуру.
• Aliases используются последовательно.
• Понятен источник истины.
• Настроен экспорт в код.
• Изменения проходят ревью.
• Удаление токена имеет миграционный процесс.

Чек-лист компонента

• Определено назначение.
• Описано, когда использовать.
• Описано, когда не использовать.
• Зафиксирована анатомия.
• Определены обязательные элементы.
• Определены варианты.
• Количество вариантов обосновано.
• Определены размеры.
• Описаны все состояния.
• Есть loading.
• Есть empty-state при необходимости.
• Есть ошибка.
• Есть disabled или объяснение его отсутствия.
• Описано адаптивное поведение.
• Проверен длинный текст.
• Проверена локализация.
• Определена HTML-семантика.
• Работает клавиатура.
• Виден фокус.
• Проверен контраст.
• Проверен размер области действия.
• Подготовлены stories.
• Добавлены тесты.
• Есть документация.
• Figma соответствует коду.
• Указана версия.

Чек-лист документации

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

Чек-лист внедрения

• Выбран пилотный продукт.
• Команда пилота участвовала в подготовке.
• Компоненты протестированы в реальном сценарии.
• Определён порядок миграции.
• Новые страницы используют систему.
• Старые компоненты помечены.
• Есть срок поддержки старой версии.
• Разработчики получили инструкции.
• Дизайнеры подключили библиотеку.
• Настроена публикация пакетов.
• Настроены автоматические тесты.
• Настроен визуальный контроль.
• Есть канал обратной связи.
• Измеряется доля использования.
• Ошибки попадают в backlog.
• Назначен регулярный аудит.

Вывод

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

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

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

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

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

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

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