Alexandra Lobanova

Почему дизайн-система не работает: 5 ошибок, которые я вижу в крупных продуктовых командах

Все хотят дизайн-систему. Но почти никто не хочет управлять ею как продуктом.

За последние годы я видела десятки ситуаций, когда компания «внедрила дизайн-систему», но через полгода:

  • компоненты дублируются,
  • разработчики не используют библиотеку,
  • дизайнеры «чуть-чуть кастомизируют» всё подряд,
  • а UI снова начинает расползаться.

Проблема почти никогда не в Figma. И не в людях.

Проблема в том, что дизайн-систему воспринимают как файл, а не как инфраструктуру.

Разберу 5 ошибок, которые чаще всего всё ломают.

Ошибка №1. Дизайн-система = UI-kit

Если у вас есть библиотека компонентов — это ещё не дизайн-система.

UI-kit — это слой представления.

Дизайн-система — это:

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

Когда в основе нет токенов, начинается хаос.

Пример:

  • В библиотеке 12 оттенков серого.
  • В коде используются 17.
  • В новых макетах появляется 18-й, потому что «чуть светлее».

Если нет единого source of truth (design tokens + их синхронизация с кодом), то визуальная консистентность невозможна по определению.

Дизайн-система без токенизации — это просто набор красивых компонентов.

Ошибка №2. Нет versioning и changelog

Это самая недооценённая часть.

Если компонент меняется, должно быть понятно:

  • что изменилось,
  • когда,
  • почему,
  • breaking change это или нет,
  • что нужно сделать продуктовым командам.

Без версионирования происходит следующее:

  1. Компонент обновили.
  2. Половина проектов не знает.
  3. В одном месте старый border-radius, в другом новый.
  4. Через 3 месяца никто не понимает, где истина.

Минимум, который должен быть:

  • semantic versioning (major / minor / patch),
  • changelog,
  • понятная логика релизов,
  • архив версий.

Если этого нет — дизайн-система не масштабируется.

Ошибка №3. Нет связи с разработкой

Очень часто дизайн-система живёт в Figma отдельно, а кодовая библиотека — отдельно.

Что из этого получается:

  • в макете есть состояние skeleton, в коде его нет,
  • в коде есть disabled-variant, в макете его нет,
  • пропсы называются по-разному,
  • токены не совпадают.

В идеале должны быть:

  • единая модель именования,
  • синхронизированные токены,
  • одинаковая структура состояний,
  • договорённость о том, что считается «готовым компонентом».

Иначе библиотека превращается в декоративный слой, который разработчики обходят стороной.

Ошибка №4. Нет ownership

Кто отвечает за развитие дизайн-системы?

Очень часто ответ звучит так:

«Ну… команда дизайна».

Это не ownership. Это размытая ответственность.

Должно быть:

  • конкретное лицо или core-команда,
  • backlog,
  • приоритизация,
  • roadmap,
  • SLA по запросам команд.

Без этого дизайн-система становится свалкой:

  • добавили variant «временно»,
  • забыли удалить,
  • сделали override,
  • сделали локальную копию компонента,
  • через год их уже три версии.

Дизайн-система — это продукт.

А продукт без владельца умирает.

Ошибка №5. Нет документации и сценариев использования

Компонент без документации — это пол-компонента.

Что должно быть описано:

  • все состояния (default, hover, active, disabled, loading, skeleton),
  • ограничения,
  • когда нельзя использовать,
  • edge-cases,
  • взаимодействие с другими компонентами,
  • accessibility-требования.

Без этого дизайнеры начинают «додумывать», а разработчики — импровизировать.

И именно в этот момент система перестаёт быть системой.

Что на самом деле делает дизайн-систему работающей

Если коротко — три слоя:

1. Архитектура

  • токены,
  • структура,
  • атомарность,
  • логика разбиения файлов,
  • единый naming.

2. Управление

  • versioning,
  • changelog,
  • релизы,
  • backlog,
  • roadmap.

3. Коммуникация

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

Когда эти три слоя работают вместе — дизайн-система начинает давать эффект:

  • сокращается time-to-market,
  • снижается количество визуальных багов,
  • уменьшается объём согласований,
  • разработка предсказуема.

Самое важное

Дизайн-система — это не про «красиво».

Это про управляемость.

Про предсказуемость интерфейса.

Про масштабирование команд.

Про снижение когнитивной нагрузки.

Про экономику.

И если воспринимать её как файл в Figma — она будет разваливаться снова и снова.

А если относиться к ней как к инфраструктуре продукта — она начинает работать.

11