Через год после запуска в продукте обычно живёт пять оттенков синего, четыре вида кнопки «Отправить» и три разных поведения у выпадающих списков. Никто не принимал такого решения: каждый новый экран рисовали чуть иначе, а разработчики каждый раз верстали его с нуля. Дизайн-система нужна, чтобы это не происходило.
Разберём, что такое дизайн-система, чем она отличается от UI-kit и гайдлайнов, из чего состоит, как связана с кодом и когда её создание окупается, а когда пока рано.
Дизайн-система: что это простыми словами
Дизайн-система — это набор переиспользуемых элементов интерфейса и правил, по которым из них собираются экраны. Она существует сразу в двух местах: в библиотеке компонентов у дизайнеров, чаще всего это дизайн-система в Figma, и в библиотеке компонентов у разработчиков. Обе версии описывают одно и то же: одну кнопку, одно поле ввода, одну шкалу отступов.
Главное в определении — слово «система». Отдельные красивые элементы ещё не система. Система появляется, когда каждое решение принято один раз и используется везде: дизайнер берёт готовый компонент, а не рисует новый, разработчик подключает готовый код, а не верстает заново.
Чем дизайн-система отличается от UI-kit и гайдлайнов
Эти три понятия часто смешивают, и из-за этого заказчик получает не то, что ожидал. Удобнее всего сравнить их рядом.
| Гайдлайны | UI-kit | Дизайн-система | |
|---|---|---|---|
| Что это | Документ с правилами бренда | Набор элементов в макетах | Токены, компоненты, правила и код |
| Где живёт | PDF или страница | Файл в Figma | Figma и репозиторий |
| Отвечает на вопрос | Какие у нас цвета и шрифты | Как выглядит элемент | Какой элемент взять и как он работает |
| Кому нужна | Маркетингу и подрядчикам | Дизайнерам | Дизайнерам, разработчикам, продакту |
Гайдлайны (брендбук) описывают логотип, фирменные цвета, шрифты, тон. Это полезно, но гайдлайн не знает, как ведёт себя поле с ошибкой или что показывать, пока таблица загружается.
UI-kit — это библиотека элементов в макетах: кнопки, поля, чекбоксы, карточки, модальные окна. Хороший UI-kit уже содержит состояния элементов. Но если в коде эти элементы каждый раз верстают заново, через несколько месяцев макеты и продукт разойдутся.
Дизайн-система включает UI-kit и добавляет к нему три вещи: токены, правила применения и связь с кодом. Поэтому UI-kit можно сделать за один проект, а дизайн-систему приходится поддерживать, пока живёт продукт.
Когда дизайн-система нужна, а когда рано
Дизайн-система — инвестиция. Её создание требует времени дизайнеров и разработчиков, которое не превращается в новые экраны сразу. Окупается она там, где одни и те же элементы повторяются много раз и продукт постоянно меняется.
Признаки того, что пора:
- у вас веб-сервис, личный кабинет или CRM, где десятки экранов собраны из форм, таблиц и фильтров;
- под одним брендом несколько продуктов: сайт, приложение, кабинет партнёра;
- над продуктом работают несколько дизайнеров или команд разработки;
- новые функции выходят регулярно, и каждая требует новых экранов;
- в интерфейсе накопились разные версии одних и тех же элементов, и пользователи это замечают.
А вот когда рано. Лендинг под рекламную кампанию, корпоративный сайт на десяток страниц, MVP, который через месяц может поменять концепцию. Здесь полноценная дизайн-система для сайта съест бюджет, который полезнее потратить на сам продукт.
Из чего состоит дизайн-система
Состав зависит от продукта, но у работающей системы почти всегда есть четыре слоя.
Токены
Токены — это именованные значения базовых параметров: цветов, размеров шрифта, отступов, радиусов скругления, теней, длительности анимации. Вместо «#1F5BFF» дизайнер и разработчик используют имя, например «цвет основного действия». Если бренд решит сменить оттенок, его меняют в одном месте, и он обновляется во всём продукте.
Токены обычно делят на базовые (вся палитра, вся шкала отступов) и смысловые (цвет ошибки, фон карточки, текст второго уровня). Именно смысловые токены позволяют сделать тёмную тему или отдельную версию для партнёра без перерисовки экранов.
Компоненты
Компонентный подход означает, что интерфейс собирается из готовых деталей, как из конструктора. Компоненты бывают простыми (кнопка, поле, иконка, бейдж) и составными (форма, карточка товара, таблица с фильтрами, шапка). Составные собираются из простых, поэтому изменение в кнопке автоматически доходит до всех форм.
Состояния
Каждый компонент описывается не одной картинкой, а всеми своими состояниями: обычное, наведение, фокус, нажатие, неактивное, загрузка, ошибка. Для экранов — пустое состояние, ошибка загрузки, отсутствие прав. Состояния — то, что чаще всего забывают в макетах, и то, что потом разработчик придумывает на ходу, каждый раз по-своему.
Правила
Правила отвечают на вопрос «когда что использовать». Когда кнопка основная, а когда второстепенная. Сколько основных кнопок может быть на экране. Когда показывать ошибку под полем, а когда — уведомлением. Как писать тексты кнопок и сообщений об ошибках. Без правил компоненты есть, но каждый дизайнер собирает из них что-то своё.
UI-kit отвечает на вопрос «как выглядит кнопка», дизайн-система — «какую кнопку здесь поставить и почему».
Как дизайн-система ускоряет разработку и снижает расходы
Экономия от дизайн-системы складывается не из того, что дизайнер быстрее рисует. Она складывается из того, что команда перестаёт решать одни и те же задачи повторно.
- Новые экраны собираются, а не рисуются. Типовая страница кабинета — это форма, таблица и фильтры из библиотеки. Дизайнер тратит время на логику сценария, а не на отрисовку полей.
- Разработчик не верстает заново. Если компонент уже есть в коде со всеми состояниями, новый экран — это сборка и бизнес-логика.
- Меньше багов в интерфейсе. Компонент проверили один раз, и он одинаково работает на всех экранах. Не нужно искать, где ещё осталась старая версия выпадающего списка.
- Изменения дешевле. Поменять цвет, шрифт или поведение элемента — правка в одном месте, а не поиск по сотне макетов и файлов.
- Проще передать проект. Новый дизайнер или подрядчик быстрее входит в работу, потому что правила записаны, а не живут в голове у одного человека.
Насколько велика экономия, зависит от продукта, частоты релизов и того, насколько система действительно используется. Честная оценка — посмотреть, сколько времени в вашей команде сейчас уходит на повторную отрисовку и вёрстку одинаковых элементов и на исправление расхождений между макетом и продуктом.
Как дизайн-система связана с кодом
Дизайн-система, которая существует только в Figma, — это UI-kit с документацией. Ценность появляется, когда у каждого компонента в макете есть двойник в коде с тем же названием, теми же вариантами и теми же состояниями.
На практике это выглядит так. Токены из Figma выгружаются в переменные, которые использует фронтенд, — в CSS-переменные или в конфигурацию стилей. Компоненты реализуются в библиотеке, которую подключает приложение: на React и Next.js, Vue или другом фреймворке. Для каждого компонента есть страница с примерами, где видно все варианты и состояния, — так разработчик и дизайнер сверяют, что они говорят об одном и том же.
Для бизнеса это означает простую вещь: дизайн-систему нельзя заказать у дизайнеров и отдельно у разработчиков так, чтобы они не общались. Мы в Sphere ведём дизайн и разработку одной командой, поэтому компоненты в макетах сразу проектируются с учётом того, как их будут реализовывать, например на Next.js.
Создание дизайн-системы: как внедрять и поддерживать
Создание дизайн-системы почти никогда не начинается с чистого листа. Чаще есть продукт с накопленным интерфейсом, и систему вытаскивают из него, наводя порядок. Рабочий порядок действий такой.
- Инвентаризация. Соберите все варианты кнопок, полей, цветов, отступов и шрифтов, которые реально есть в продукте. Обычно уже на этом шаге становится видно, сколько лишнего накопилось.
- Токены. Сведите цвета, типографику и отступы к шкалам и дайте им смысловые имена. Это основа, без которой компоненты не будут согласованными.
- Базовые компоненты. Начните с того, что встречается чаще всего: кнопки, поля, выпадающие списки, чекбоксы, уведомления. Опишите все состояния и реализуйте их в коде.
- Составные компоненты и шаблоны. Формы, таблицы, карточки, шаблоны типовых страниц. Их стоит делать по мере того, как они нужны в реальных задачах, а не впрок.
- Постепенный переход. Переводите продукт на новые компоненты по разделам: при каждой доработке раздела заменяйте старые элементы новыми. Один большой релиз «переделать всё» почти всегда затягивается.
- Документация и правила. Записывайте не только «как выглядит», но и «когда использовать». Короткие примеры правильного и неправильного применения работают лучше длинных текстов.
Поддержка — то, о чём забывают при планировании. У системы должен быть владелец, который принимает изменения и следит, чтобы Figma и код не расходились. Новый компонент добавляют в систему, только если он нужен больше чем в одном месте, иначе библиотека разрастается до состояния, когда в ней сложнее найти нужное, чем нарисовать заново. Изменения стоит фиксировать в журнале, чтобы команды знали, что поменялось и что нужно обновить у себя.
Если продукт ждёт большого обновления интерфейса, это удобный момент, чтобы заложить систему: старые элементы всё равно будут переделывать, и лучше сразу делать их компонентами.
Что получить от подрядчика, если заказываете дизайн-систему
Если вы заказываете дизайн-систему или просите заложить её в проект сайта или сервиса, договоритесь о составе результата заранее. Разумный комплект выглядит так:
- библиотека в Figma с компонентами, вариантами и всеми состояниями;
- токены цвета, типографики, отступов и скруглений с понятными именами;
- библиотека компонентов в коде с теми же названиями и вариантами;
- страница с примерами компонентов, где можно проверить их поведение;
- правила применения: когда какой компонент использовать и как писать тексты интерфейса;
- описание процесса: кто владелец системы и как в неё вносить изменения.
Наш подход к дизайну — сначала аналитика и структура, потом визуальный код с нуля, без шаблонов, — хорошо ложится на системную работу: компоненты появляются из реальных сценариев продукта, а не из чужого набора. Примеры проектов можно посмотреть на странице с нашими работами.
Частые вопросы
Чем дизайн-система отличается от UI-kit?
UI-kit — это набор готовых элементов интерфейса: кнопки, поля, карточки, иконки. Дизайн-система включает UI-kit, но добавляет к нему токены, правила использования компонентов, описание состояний и связь с кодом. UI-kit отвечает на вопрос «как выглядит кнопка», дизайн-система — «какую кнопку здесь поставить и почему».
Нужна ли дизайн-система небольшому сайту?
Полноценная — обычно нет. Сайту из нескольких страниц хватит аккуратного UI-kit с состояниями элементов, сеткой и цветами, вынесенными в переменные. Это фундамент, на котором дизайн-систему можно достроить, если сайт вырастет в сервис или появится второй продукт.
Можно ли сделать дизайн-систему для уже работающего продукта?
Можно, и так бывает чаще всего. Начинают с инвентаризации: собирают все варианты кнопок, полей и цветов, которые реально есть в интерфейсе, и сводят их к единому набору. Переводить продукт на новые компоненты лучше постепенно, по разделам, а не одним большим релизом.
Кто должен поддерживать дизайн-систему?
У системы должен быть владелец — дизайнер или небольшая группа из дизайнера и фронтенд-разработчика. Они принимают изменения, следят, чтобы макеты и код не расходились, и ведут журнал изменений. Без владельца система быстро устаревает и команда возвращается к локальным решениям.
