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

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

От набора правил к системе

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

Лекарство называется дизайн-система. Это общий язык проекта: принципы, значения (цвета, размеры), готовые детали (кнопки, поля), правила их использования, код, который их воспроизводит, и договорённость о том, как всё это меняется. Исследователи Nielsen Norman Group определяют её как набор стандартов для управления дизайном в масштабе с помощью повторно используемых компонентов и паттернов (ссылка на их статью есть в источниках).

Три термина путают, поэтому разведём.

• Гайдлайн (альбом стиля). Документ: «наш синий такой-то, шрифт такой-то». Он описывает, но ничего не воспроизводит.
• Библиотека компонентов. Готовые детали в виде кода или Figma-файла. Они воспроизводят, но не объясняют, когда что брать.
• Дизайн-система. Всё вместе: и принципы, и значения, и детали, и документация, и порядок изменений, и люди, которые за это отвечают.

Проверьте себя: чем система отличается от гайдлайна?

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

Девять слоёв

У системы нет единой обязательной «формы», но в больших публичных системах встречаются одни и те же слои. Выберите на схеме размер проекта и посмотрите, сколько слоёв вам нужно. Откройте любой слой: там сказано, на какой вопрос он отвечает и как это устроено в реальных системах.

Один человек, один сайтКоманда, несколько страницКомпания, несколько продуктов

Принципы нуженОсновы нуженТокены нуженКомпоненты по желаниюПаттерны можно не делатьСлова по желаниюКод можно не делатьДокументация по желаниюУправление можно не делать

Принципы. Отвечает на вопрос: Во что мы верим, когда решаем спорный вопрос?

Что внутри. Три-пять коротких правил, например «сначала понятность, потом красота».

Кто отвечает. Тот, кто отвечает за продукт и дизайн.

В реальных системах. У GOV.UK система опирается на открытые государственные принципы дизайна (Government Design Principles).

В маленьком проекте. Три правила на странице паспорта проекта.

Вот те же слои словами.

1. Принципы. Три-пять коротких правил для спорных случаев: «сначала понятность, потом красота». У GOV.UK система стоит на открытых государственных принципах дизайна.
2. Основы. Цвет, типографика, отступы, сетка, значки, движение. Вы уже сделали три из них в прошлых уроках.
3. Токены. Именованные значения, из которых собрано всё: color.text.primary, space.200. Им отведены два урока ниже.
4. Компоненты. Кнопка, поле, карточка, меню: у каждого есть варианты и состояния (обычное, наведение, фокус, недоступно, ошибка).
5. Паттерны. Решения типовых задач из нескольких компонентов: форма входа, поиск, подтверждение. GOV.UK разделяет их строго: «компоненты» отдельно, «паттерны» отдельно.
6. Слова. Тон голоса, правила для кнопок, сообщений об ошибках, названий. Слова часть интерфейса, и Carbon выделяет их в отдельный раздел основ.
7. Код. Библиотека, которую можно поставить и использовать: пакет, примеры, тесты.
8. Документация. Когда и как брать каждую деталь, когда не брать, примеры «можно» и «нельзя», заметки о доступности.
9. Управление. Кто отвечает, как предложить изменение, как меняются версии, как списывают устаревшее. Это самый недооценённый слой: система без владельца за год превращается в свалку.

Зачем это и сколько стоит

Выгода у системы такая:

• Единый вид и поведение. Посетитель привыкает один раз.
• Скорость. Новую страницу собирают из готовых деталей, а не рисуют заново.
• Качество и доступность «из коробки». Контраст, фокус и размеры исправляют в одном месте, и они исправляются везде.
• Масштаб. Над продуктом работают десятки людей, и система удерживает их вместе.

У неё есть и цена: время на создание, время на поддержку и риск «запереть» дизайн в старых решениях. Поэтому размер системы подгоняют под проект. Сайту из одной страницы хватит лёгкой: принципы, токены, пять-шесть компонентов и справочник. Игнорировать систему совсем тоже дорого: вы всё равно её создадите, только случайно и неряшливо.

Один источник правды

Дизайнер рисует в Figma, а разработчик пишет код, и у них легко появляются две версии «правды»: макет с одними значениями, продукт с другими. Поэтому в зрелых системах выбирают один источник, из которого получают остальное. Чаще всего это файл токенов и код компонентов: из них собираются и переменные в Figma, и CSS, и документация. Как это делается, вы увидите на уроках про токены и про передачу макета в код.

Проверьте себя: нужна ли система сайту из одной страницы?

Нужна лёгкая: принципы, токены, пять-шесть компонентов и короткий справочник. Паттерны и управление можно не делать.

Практика

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

Что было не так с 2014 годом

В 2014 году «дизайн-система» нередко была альбомом в PDF: красивым, но не связанным с кодом. Через полгода код расходился с альбомом, и альбом переставали открывать. Урок эпохи: система живая, если у неё есть код и владелец, и мёртвая, если это только документ.