Дизайн-система: когда она окупается, а когда это дорогая игрушка

UI-кит, библиотека компонентов и дизайн-система — три разные вещи

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

UI-кит — это набор переиспользуемых элементов в Figma: компоненты с вариантами, стили текста и цвета, сетка. Он решает задачу «не рисовать заново» и делается за 40–80 часов. Библиотека компонентов — это тот же набор в коде: типизированные компоненты, которые фронтенд подключает вместо копипасты. Она решает задачу «одинаково в проде» и стоит 80–200 часов в зависимости от количества элементов. Дизайн-система — это UI-кит плюс библиотека плюс правила применения, документация, версионирование, процесс контрибуции и человек, который за всё это отвечает.

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

Поэтому первый вопрос перед стартом — не «какие компоненты нам нужны», а «как сформулирована боль». Если она звучит как «долго рисуем макеты» — вам нужен UI-кит. Если «в проде всё выглядит по-разному» — библиотека компонентов. Если «запуск второго продукта занимает квартал, и половина этого времени уходит на переизобретение интерфейса» — вот теперь речь действительно про систему.

• UI-кит: компоненты и стили в Figma. 40–80 часов, поддержка почти не нужна.
• Библиотека компонентов: тот же набор в коде с типизированными пропсами. 80–200 часов.
• Дизайн-система: кит плюс библиотека плюс правила, документация, версии и владелец. От 150 часов на v1 и постоянная стоимость владения.
• Дисциплина именования стоит ноль часов и снимает половину споров. Начинайте с неё.

Три слоя настоящей системы и то, что добавляют зрелые команды

Первый слой — визуальный. Это токены и компоненты в Figma: семантические цветовые переменные, шкала типографики, шкала отступов, радиусы, тени, набор компонентов с вариантами и авто-лейаутом. Ключевое слово здесь — семантические. Токен с именем surface-elevated переживёт ребрендинг, токен с именем grey-100 придётся переименовывать во всех макетах, как только палитра изменится. Это единственное решение первого слоя, которое почти невозможно исправить дёшево.

Второй слой — кодовая библиотека. Компоненты во фреймворке проекта, с описанными свойствами, обработкой клавиатуры, фокусом, состояниями загрузки и ошибки. Здесь система впервые начинает экономить деньги: пока компонент существует только в Figma, разработчик всё равно пишет разметку с нуля и принимает десяток микрорешений, которых нет в макете. Слой два убирает именно эти микрорешения, и именно поэтому системы, остановившиеся на слое один, не окупаются никогда.

Третий слой — гайдлайны: когда применять компонент, а когда нет, как формулировать тексты кнопок и ошибок, какие правила по контрастности и доступности обязательны, как ведут себя пустые состояния. Этот слой чаще всего пропускают, потому что он не выглядит как результат. Но именно он отвечает на вопрос, который возникает у каждого нового дизайнера в первую неделю: «у нас три вида уведомлений, какой брать?» Без ответа человек добавляет четвёртый.

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

Тест на порог: нужна ли вам дизайн-система прямо сейчас

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

Интерпретация простая. От 0 до 4 баллов — системы не нужно, нужен UI-кит и один документ на две страницы с правилами именования слоёв и компонентов. От 5 до 8 — соберите библиотеку компонентов в коде и токены, но не заводите отдельный процесс, документацию и владельца: это преждевременно. От 9 баллов — стройте минимальную систему по составу из раздела ниже и сразу закладывайте бюджет на поддержку, иначе она умрёт через два квартала.

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

Считаем окупаемость: часы, ставка и точка безубыточности

Формула у окупаемости примитивная, и именно поэтому её почти никто не считает: экономия за спринт = сэкономленные часы на человека × количество людей × внутренняя стоимость часа. По практике дизайнер, работающий с готовыми компонентами и токенами, экономит 4–6 часов за двухнедельный спринт, фронтендер — 6–10 часов, потому что убирается не только вёрстка, но и обсуждение состояний, отступов и поведения на брейкпоинтах.

Возьмём типичную команду: 4 дизайнера и 8 фронтендеров. Экономия за спринт получается около 4×5 + 8×8 = 84 часа. При внутренней стоимости часа в 2 000–3 500 ₽ — вилка, в которую попадает большинство российских продуктовых команд — это 170 000–290 000 ₽ за спринт, или примерно 340 000–590 000 ₽ в месяц. Сборка v1 в такой конфигурации стоит 250–350 часов, поддержка — 20–30 часов в месяц.

Но честный расчёт обязан учесть три вещи, которые обычно выпадают. Первая — первые два спринта после внедрения команда работает медленнее, а не быстрее: люди ищут компоненты, спорят с ограничениями, дописывают недостающее. Закладывайте минус 20–30% скорости на месяц. Вторая — миграция существующих экранов. Её либо делают постепенно, либо не делают вообще, и тогда в продукте два интерфейса одновременно. Третья — обучение и документация: без них экономия на человека падает вдвое, потому что искать компонент дольше, чем написать свой.

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

Минимально жизнеспособная система: что входит в v1 и что не входит

Первое, что делается, — токены, и делаются они по ролям, а не по значениям. Цвет: поверхности (фон, поднятая поверхность, оверлей), контент (основной, вторичный, приглушённый, инвертированный), акцент и его состояния, семафор из четырёх статусов (успех, предупреждение, ошибка, информация), границы. Типографика: 5–7 стилей, не двадцать. Отступы: шкала на базе 4 или 8 пикселей, максимум восемь значений. Радиусы: три. Тени: три уровня. И карта z-index, зафиксированная один раз, чтобы модалка навсегда перестала оказываться под выпадающим списком.

Дальше — 12–15 компонентов, которые закрывают около 80% интерфейса любого продукта: кнопка, поле ввода, многострочное поле, селект, чекбокс и радио, переключатель, модальное окно, всплывающая подсказка, тост или уведомление, карточка, таблица, вкладки, пагинация, аватар, бейдж. Всё, что не попало в этот список — календарь-планировщик, дерево, редактор, сложные графики — делается точечно под задачу и добавляется в систему только тогда, когда понадобится второй раз.

Состояния — это половина ценности системы и та часть, которую чаще всего забывают. Для каждого интерактивного компонента нужны: обычное, наведение, фокус с клавиатуры (именно видимый фокус, а не убранный outline), нажатие, отключено, загрузка, ошибка. Для контейнеров — пустое состояние, состояние загрузки и состояние ошибки загрузки. Компонент без описанных состояний экономит дизайнеру десять минут и стоит разработчику полдня на выяснение, что показывать, пока грузятся данные.

Чего в v1 быть не должно: тёмной темы, если она не в требованиях прямо сейчас; собственного набора иконок, нарисованного с нуля, — берите открытый набор и дорисовывайте недостающее; мультибрендинга; сложной анимационной библиотеки; портала документации с поиском и версиями. Всё это добавляется на втором круге, когда система уже доказала, что ею пользуются. Сборка v1 в таком составе занимает 150–250 часов; в Veltos.Tech работы по UX/UI начинаются от 60 000 ₽, и минимальная система обычно собирается за 4–6 недель параллельно с текущими задачами продукта.

• Токены по ролям, а не по значениям: surface-elevated переживёт ребрендинг, grey-100 — нет.
• 12–15 компонентов покрывают около 80% интерфейса. Остальное — по факту второго обращения.
• Семь состояний на интерактивный компонент и три на контейнер — это не перфекционизм, а экономия дней разработки.
• Тёмная тема, свои иконки и портал документации — только во второй итерации.

Синхронизация дизайна и кода — место, где системы умирают

Типичная смерть дизайн-системы выглядит так: в Figma всё аккуратно, в коде отставание на три месяца, дизайнер рисует по новым токенам, разработчик собирает по старым, продукт выглядит как два разных продукта. Через полгода команда перестаёт открывать библиотеку, потому что «там всё равно неактуально». Проблема не в людях и не в дисциплине, а в отсутствии механической связи между двумя источниками правды.

Рабочая схема выглядит так. Переменные Figma экспортируются в JSON, JSON собирается инструментом трансформации токенов в CSS-переменные, TypeScript-константы и, если нужно, в форматы для мобильных платформ. Сборка запускается в CI, а не руками дизайнера в пятницу вечером. С этого момента изменение цвета в Figma доезжает до прода одним пул-реквестом, а не письмом с просьбой «поправьте, пожалуйста, оттенок». Настройка этого конвейера — 20–40 часов, и это лучшие 40 часов во всём проекте.

Поведение компонентов живёт в Storybook, и это единственный источник правды по интерактиву. Макет показывает, как выглядит; Storybook показывает, как работает: все состояния, все варианты пропсов, поведение с клавиатуры, крайние случаи с длинным текстом и пустыми данными. Дизайн-ревью, которое проводится по Storybook, а не по картинкам, находит заметно больше расхождений — просто потому, что картинку невозможно «протыкать».

Версионирование и владение — последний кусок. Система версионируется как библиотека: семантические версии, changelog, устаревание компонента с периодом в один-два релиза, а не мгновенное удаление. Владельца нужно назвать поимённо, а его время — включить в спринт как обычную задачу, а не как «сделает, когда будет свободен». Три работающие модели финансирования: 10–15% времени одного дизайнера и одного фронтендера; отдельная маленькая команда при 25+ разработчиках; федеративная модель, где продуктовые команды контрибьютят, а владелец только ревьюит. Не работает ровно одна модель — «делаем в свободное время».

• Переменные Figma → JSON → CSS и TS через сборку в CI. Руками — не работает дольше квартала.
• Storybook — источник правды по поведению. Ревью по Storybook, а не по картинкам.
• Семантические версии, changelog и устаревание с периодом, а не молчаливое удаление компонента.
• Владелец назван поимённо, его время в спринте. «В свободное время» — это план закрытия системы.

Внедрение: почему команда игнорирует систему и что с этим делать

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

Четвёртая причина самая разрушительная: контрибуция требует недели согласований. Если добавить вариант кнопки можно только через комитет, два ревью и релизный цикл, команда просто перестанет предлагать изменения и начнёт обходить систему. Рабочий норматив — предложение принимается или отклоняется за 1–2 рабочих дня, а простые дополнения вроде нового размера или иконки проходят без обсуждения вовсе.

Что чинит внедрение на практике. Метрика покрытия: доля экранов и компонентов в продакшене, собранных из системы, замеряется раз в месяц и обсуждается. Канал поддержки со сроком ответа — вопрос про компонент не должен висеть три дня. Явно разрешённое отклонение: команда имеет право сделать по-своему, если фиксирует это в трекере, и через два таких случая компонент попадает в бэклог системы. Онбординг на 30–40 минут для каждого нового человека. И линтер или автопроверка, которая ловит захардкоженные цвета и отступы в пул-реквестах.

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

Частые вопросы

Услуги по теме

• UX/UI дизайн сайтов и приложенийПроектируем интерфейсы, которые доходят до продакшена: от исследования и структуры до UI-кита и передачи в разработку. Всё живёт в Figma как компоненты с реальными состояниями и брейкпоинтами, а не как папка со статичными картинками. Один и тот же процесс работает для лендинга, корпоративного сайта, интернет-магазина, веб-приложения и мобильного продукта.
• Разработка сайтов под ключДелаем сайты, которые не разваливаются через полгода: от одностраничника на CMS до магазина и веб-приложения на React и Next.js. Один подрядчик на дизайн, код, интеграции и запуск.
• Разработка веб-приложений и Telegram Mini AppКогда сайта уже мало и нужен продукт: личный кабинет, дашборд, внутренний сервис или Mini App внутри Telegram. Проектируем архитектуру, пишем бэкенд и фронтенд, доводим до релиза.

Читать дальше

• UX-исследования без бюджета лаборатории: что реально даёт результатБольшинству команд не нужен отдел исследований — им нужно перестать угадывать. Разбираем методы по стоимости и отдаче, объясняем правило пяти пользователей и его важную оговорку, показываем, как превратить находки в решения без отчёта на 60 страниц.
• Редизайн сайта без потери трафика: этапы, риски и SEO-чеклист переездаПоловина запросов на редизайн — это на самом деле проблемы контента, скорости или оффера. Разбираем, как отличить одно от другого, почему поэтапный вывод безопаснее большого запуска и что должно быть в чеклисте переезда, чтобы не потерять органику.
• Сколько стоит разработка сайта в 2026: разбор сметы по строкамРазбираем смету на разработку сайта построчно: сколько стоит аналитика, дизайн, вёрстка, бэкенд и интеграции, какие расходы всегда появляются после запуска и на чём можно сэкономить без последствий.