Дизайн-система — зачем она бизнесу и когда она окупается

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

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

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

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

Что дизайн-система даёт бизнесу

Скорость. Новый экран собирается из готовых частей. Дизайнер не рисует очередную таблицу, разработчик не верстает её заново. Время уходит на логику экрана, а не на пиксели.

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

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

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

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

Читаемость и доступность. Контраст текста, размер шрифта, заметное выделение активного поля решаются один раз — на уровне токенов и компонентов, а не на каждом экране. Для продуктов, которыми пользуются люди постарше, это особенно важно.

Где дизайн-система окупается быстрее всего

В сложных B2B-продуктах. Для тендерной площадки ETS Tender я делал продуктовый дизайн — от логики процессов до интерфейсов. Канбан-модель там работает для тендеров, сделок и согласований, а пользуются системой несколько ролей с разными правами. В таком продукте одни и те же элементы — карточки, статусы, кнопки действий, панели — повторяются по всей системе. Без общих правил интерфейс быстро расходится, и каждый новый экран начинает жить по своим законам.

В экосистемах из нескольких продуктов. У Atlas Tourism семь и больше продуктов: сайт, премиальный сервис, B2B-портал, букинг, онлайн-копилка, приложение паломника, генератор сертификатов. Всё — в одном визуальном языке и на общих данных. Тот же язык ушёл в печать: книгу паломника на 76 полос, брошюру и баннеры к выставке. Для паломника и партнёра это одна компания, а не набор разных сайтов.

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

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

• Лендинг или промо-сайт на сезон. Несколько экранов, которые не будут развиваться.
• MVP до проверки идеи. Здесь хватит минимума: токены и базовые компоненты. Полную систему строить рано — продукт может измениться после первых пользователей.
• Нет того, кто будет её поддерживать. Дизайн-система, которую не обновляют, быстро устаревает, и команда перестаёт ей верить.

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

И не стоит путать дизайн-систему с «дизайном подороже». Это рабочий инструмент, а не художественный проект. Если на неё уходит больше времени, чем на сам продукт, что-то пошло не так.

Дизайн-система в коде, а не только в Figma

Дизайн-система, которая живёт только в Figma, помогает дизайнеру, но не продукту. Бизнес получает пользу, когда у каждого компонента из макета есть такой же компонент в коде — с тем же названием, теми же состояниями и теми же токенами. Тогда разработчик собирает экран, а не перерисовывает его по картинке, и то, что утвердили в макете, совпадает с тем, что увидит пользователь.

У меня дизайн и разработка идут вместе, поэтому система с самого начала существует в обоих местах. В этом и главная экономия: решение принимается один раз и не теряется при передаче из макета в код.

Как начать, если продукт уже есть

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

Дальше порядок такой:

1. Выбрать по одному варианту на каждую задачу и описать токены.
2. Собрать компоненты со всеми состояниями — в макетах и в коде.
3. Записать правила: где какой компонент использовать и где нельзя.
4. Договориться, что новые экраны собираются только из системы.

Старые экраны можно переводить на систему постепенно — по мере того, как их всё равно дорабатывают. Останавливать продукт ради дизайн-системы не нужно.

Понять, что система работает, просто. Новый экран собирается из готовых частей без новых компонентов, дизайнер и разработчик называют элементы одинаково, а вопросы «а какой здесь отступ?» исчезают сами.

Дизайн-система окупается там, где интерфейс — рабочий инструмент, а не витрина на сезон. Если ваш продукт растёт и каждый экран живёт по своим правилам, посмотрите, как я делаю продуктовый дизайн и дизайн B2B-платформ. А начинать любую систему стоит с логики — о ней заметка «Зачем прототип до разработки».