Никто не решает развалить дизайн-систему. Расхождение дизайн-системы копится по одной разумной правке за раз, и к моменту, когда его замечают, исправление уже стало отдельным проектом.
Коротко
- Расхождение дизайн-системы — это растущий разрыв между дизайном, который утвердила команда, и кодом, которым на самом деле пользуются клиенты.
- Только у 54% команд токены есть одновременно в дизайн-инструментах, коде и документации, и только у 40% есть хоть какой-то конвейер токенов (zeroheight Design Systems Report 2026).
- Обычно расхождение начинается в одном из пяти мест: переименование с одной стороны, значения, вписанные руками, токены без хозяина, ручной экспорт и изменения компонентов, которые никто не сверил с кодом.
- Его не видно, потому что ничего громко не ломается. Сделайте его видимым прямым сравнением двух копий и исправляйте обычными pull request'ами.
Что такое расхождение дизайн-системы?
Расхождение дизайн-системы — это разница между утверждённой дизайн-системой и её реализацией в продакшен-коде. Оно возникает потому, что каждая дизайн-система существует дважды. Дизайн держит утверждённую версию в Figma: переменные, стили, иконки и компоненты. Разработка держит свою копию в коде: CSS-переменные, файл токенов, пакет иконок, библиотеку компонентов.
Обе копии ведут разные люди, разными инструментами и в разном ритме. Ничто не заставляет их оставаться одинаковыми. Поэтому расхождение — не провал дисциплины. Это естественный исход двух копий, которые никто не сверяет.
Цифры это подтверждают. Авторы zeroheight Design Systems Report 2026 опросили 147 практиков дизайн-систем, большинство — из компаний, где работает 1 000+ человек. 86% их команд используют дизайн-токены, но только у 54% токены есть одновременно в дизайн-инструментах, коде и документации. В более раннем Sparkbox Design Systems Survey 2022 (219 ответов) 37% респондентов назвали «паритет между дизайном и кодом» одной из главных проблем.
Откуда берётся расхождение дизайн-системы
Обычно расхождение начинается в одном из пяти мест. Ни одно из них само по себе не ошибка. Каждое — разумное решение, принятое без взгляда на другую сторону.
Ручная работа по-прежнему норма. В отчёте zeroheight 2026 сказано прямо: «лишь у 40% команд налажен хоть какой-то конвейер токенов, а значит, они синхронизируют токены между дизайном, документацией и кодом вручную».
Сама Figma уже знает, когда меняется сторона дизайна. Её вебхук LIBRARY_PUBLISH сообщает, какие компоненты, стили и переменные создали, изменили или удалили при каждой публикации библиотеки. Обычно не хватает второй половины: того, что сверит это изменение с кодом.
Почему расхождение не видно
Расхождение тихое. Ничего не падает, если цвет кнопки чуть уехал или кольцо фокуса на пиксель тоньше утверждённого. Юнит-тесты проходят. Визуальное ревью ловит явные поломки, но скриншоты пятидесяти экранов рядом никто не сравнивает.
Поэтому у расхождения нет хозяина. Дизайн не видит код. Разработка не знает, какие различия задуманы. У руководства нет независимого способа проверить. На вопрос «продакшен всё ещё соответствует утверждённому?» ответить некому.
Измерять его руками тоже почти бесполезно. Мы убедились в этом, пока строили FISYCO: грубые подсчёты ошибаются в обе стороны, пропускают настоящие разрывы и помечают правильный код. Что сработало, мы описали в статье как измерить здоровье дизайн-системы.
Когда расхождение дизайн-системы становится дорогим
Расхождение превращается в затраты несколькими предсказуемыми путями:
- Повторная работа над решёнными вопросами. Дизайн и разработка дважды тратят время на уже принятые решения.
- Непоследовательные экраны. Клиенты видят реализацию, а не дизайн, который вы утвердили.
- Ребрендинг и смена темы. Каждое вписанное руками значение приходится искать вручную, файл за файлом.
- Сдвигающиеся релизы. Поздние исправления всплывают на ревью или после запуска, когда вносить их дольше всего.
- Потеря доверия к системе. Команды перестают на неё опираться и строят своё, а это ускоряет расхождение.
Команды эти затраты чувствуют: в опросе Sparkbox 2022 года 33% назвали соответствие дизайна и кода главным приоритетом. Последнюю цену труднее всего отыграть назад, потому что она накапливается. Когда люди считают дизайн-систему устаревшей, они перестают в неё вкладываться, и разрыв растёт быстрее.
Как держать расхождение под контролем
Ответ — не больше процессов и не строже ревью. Нужно сделать разницу между двумя копиями видимой, а её исправление дешёвым.
- Сравнивайте копии напрямую. Сверяйте имена, значения и режимы токенов, а не разглядывайте скриншоты.
- Читайте реальное использование, а не объявленные токены. Файл токенов говорит, что код должен использовать. Код говорит, что он использует на самом деле.
- Ранжируйте по охвату. Разошедшийся токен на двухстах экранах важнее десятка разовых значений.
- Исправляйте привычным путём. Доставляйте изменения pull request'ами, чтобы они проходили то же ревью, что и любой другой код.
- Начните с исходной точки. Зафиксируйте, насколько копии разошлись сегодня, чтобы через месяц понять, стало ли лучше.
Полезный отчёт о расхождениях выглядит примерно так (пример условный):
Выберите одну библиотеку, обычно токены или иконки, и измерьте её первой. Одна честная исходная точка стоит больше полного аудита, который никто не повторит.
О том, как исправлять сторону токенов, читайте в статье токены из Figma в код без ручного экспорта. Если всё упирается в переменные, плагин FISYCO для Figma отправляет их с любого тарифа Figma.
Частые вопросы
Расхождение дизайн-системы — это всегда проблема?
Нет. Некоторые различия задуманы, например эксперимент или ограничение платформы. Проблема — расхождение, о котором никто не знает. Когда различие видно, команда может осознанно принять его или исправить.
Могут ли визуальные регресс-тесты поймать расхождение?
Отчасти. Они ловят изменения между двумя версиями вашего же кода. Что утвердил дизайн, они не знают, поэтому компонент, который был неверным с самого начала, будет проходить каждый раз.
Как часто проверять расхождение?
Каждое изменение с любой стороны — шанс разойтись. Постоянное сравнение, которое запускается публикацией библиотеки в Figma или push'ем в код, ловит расхождение раньше квартального аудита.
Чем помогает FISYCO
Мы делаем FISYCO, чтобы закрыть именно этот разрыв. Он подключает ваш файл Figma и репозиторий, сравнивает две копии и показывает найденные расхождения, ранжированные по тому, какую часть продукта задевает каждое. Изменения из дизайна приходят pull request'ами. На стороне кода FISYCO готовит исправления, проверяет их рендерингом и только потом открывает pull request. Посмотрите, что FISYCO умеет сегодня.
