FISYCO

Публичная бета
РазрывСтоимостьКак работаетПродуктБезопасность
Войти

Как измерить здоровье дизайн-системы, а не угадывать

6 мин чтения

Дизайн-системы
Read in English
Segmented health ring with one orange segment next to a list of findings, one of them highlighted

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

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

Коротко
- Здоровье дизайн-системы измеряют четырьмя сигналами: расхождения, охват, обходы и время исправления.
- Внедрение измеряют только 41% команд (zeroheight 2026), а в опросе Sparkbox 2022 года налаженное отслеживание метрик было лишь у 16%.
- Измерения на стороне кода отстают: только 9% респондентов назвали специальный трекер внедрения в коде среди своих инструментов измерения (zeroheight Design Systems Report 2026).
- Сведите расхождения и обходы в один показатель, взвешенный по охвату, отслеживайте рядом время исправления, а полный список находок держите на расстоянии одного клика.

Почему ощущение не работает

Ощущение складывается из того, что человеку довелось увидеть. Дизайнер, который неделю сидел над экраном настроек, видит его проблемы повсюду. Разработчик, который только что навёл порядок в файле токенов, видит аккуратную систему. Оба правы про свой угол и ошибаются про целое.

Без общего измерения работа над дизайн-системой проигрывает фичам, уборки глохнут, потому что никто не может показать результат, а каждый квартал возвращается один и тот же спор. Выиграть этот спор всё труднее. Авторы zeroheight Design Systems Report 2026 опросили 147 практиков, большинство — из компаний, где работает 1 000+ человек. 40% из них недовольны тем, как им удаётся заручиться поддержкой своей дизайн-системы. Годом ранее таких было 23%.

Что команды измеряют сегодня

Большинство команд измеряют мало. По данным отчёта zeroheight 2026, внедрение измеряют 41% команд, согласованность продукта — 26%, а ROI — всего 5%. На вопрос, какими инструментами они измеряют, 37% респондентов назвали аналитику репозитория кода и только 9% — специальный трекер внедрения в коде. В более старом Sparkbox Design Systems Survey 2022 (219 ответов) налаженное отслеживание метрик или отчётность по дизайн-системе было лишь у 16%.

Зрелые команды показывают, как это выглядит на практике. Pinterest измеряет внедрение на стороне дизайна как долю слоёв компонентов дизайн-системы среди всех слоёв на страницах передачи в разработку и учитывает только файлы, которые редактировали за последние две недели (Figma Blog, 2023). Команда Paste в Twilio выяснила, что число загрузок из npm ничего не говорит о том, кто какие части использует. Поэтому она сделала инструмент, который читает импорты файл за файлом (Twilio, 2021).

Atlassian идёт дальше и перекрывает обходы в самом источнике. Правила ESLint вроде ensure-design-token-usage помечают значения, которые должны быть токенами, а остальное вычищают кодмоды (Atlassian Design System).

Четыре сигнала здоровья дизайн-системы

Полезное измерение — то, которое можно пересчитать автоматически и сравнить во времени.

Охват превращает список в приоритеты. Цвет, уехавший в компоненте, который стоит на каждом экране, важнее десятка разовых значений на забытой странице админки.

Обходы показывают, пользуются ли системой на самом деле. Отступ, вписанный руками, пока не ошибка. Он просто вне системы и не последует за следующим изменением.

Время исправления показывает, работает ли процесс. Если расхождения находят быстро, а живут они месяцами, проблема во владении, а не в видимости.

Как собрать каждый сигнал

Каждый сигнал можно собирать автоматически, никого не прося заполнять таблицу:

  • Расхождения: сравнивайте имена, значения и режимы токенов в Figma и в коде, сопоставляя их по стабильному ID, а не по имени. Почему так, объясняет руководство по работе с токенами.
  • Охват: считайте файлы, которые импортируют или используют каждый токен и компонент.
  • Обходы: ищите правилом линтера или поиском по коду литералы в hex и пикселях там, где есть токен. Генерируемые папки исключайте.
  • Время исправления: записывайте, когда каждую находку увидели впервые и когда её устранили.

Показатель здоровья дизайн-системы: одно число и детали за ним

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

Простой вариант взвешивает находки по охвату. Например (пример условный): если отслеживается 2 400 использований токенов и компонентов и 120 из них затронуты открытыми расхождениями или обходами, здоровье равно 100 × (1 − 120 ÷ 2 400) = 95.

Время исправления в показатель не входит. Отслеживайте его рядом как тренд, например медианное число дней, которое находка остаётся открытой.

Честным число держат два правила:

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

Как показывать здоровье дизайн-системы разным людям

Одним и тем же данным нужны три среза:

  • Руководству: показатель, его тренд и несколько расхождений с самым большим охватом.
  • Дизайну: утверждённые решения, которые так и не дошли до продакшена.
  • Разработке: где код обходит систему, с предложенным исправлением для каждой находки.

Когда все смотрят на одни и те же находки, разговор переходит от «всё плохо?» к «что из этого чиним первым?».

Смотрите на показатель в постоянном ритме, например раз в спринт. Тренд за несколько недель говорит больше любого отдельного значения.

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

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

Измерять внедрение в Figma или в коде?

И там, и там, но это ответы на разные вопросы. Внедрение в Figma показывает, пользуются ли системой дизайнеры. Внедрение в коде показывает, получают ли её клиенты. Если можете измерять только одно, измеряйте код, потому что именно он уходит в продакшен.

Не слишком ли упрощает один показатель?

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

Как измерять, не добавляя команде работы?

Автоматизируйте. Пересчитывайте на каждый push или публикацию дизайна. Метрика, которой нужен ручной ввод, устареет ко второму месяцу.

Как FISYCO измеряет здоровье

Мы сделали FISYCO, чтобы это измерение шло непрерывно. Он индексирует ваш код на каждый push и сравнивает его с дизайном из ваших библиотек Figma. Отчёт о здоровье показывает расхождения, их охват и обходы токенов и компонентов. Исправления проверяются рендерингом, прежде чем прийти pull request'ами. Посмотрите, что FISYCO умеет сегодня.

Измерить свою дизайн-систему
#Управление#Расхождения
KK

Автор статьи

Kirill Karpov

Основатель FISYCO

Кирилл Карпов — основатель FISYCO, инструмента контроля дизайн-системы, который держит Figma и код продакшена в согласии.

Держите дизайн-систему и код в согласии

FISYCO связывает библиотеки Figma с кодовой базой, находит расхождения и присылает правку пулреквестом.

Начать бесплатно

Похожие статьи

5 мин чтения

Дизайн-системы

Почему продакшен тихо расходится с дизайн-системой

Расхождение дизайна и кода редко возникает из-за одной большой ошибки. Разбираем, откуда оно берётся, почему его никто не видит и когда оно начинает стоить денег.