Перепост статьи из моего личного блога.
Зачем вообще нужна дизайн-система? В первую очередь, для стабилизации и ускорения проектирования с разработкой. Затем — для унификации пользовательского опыта. Идея хорошая, однако иногда вместо этого мы просто получаем барьер на каждом шаге. Перекрасить кнопку? Согласование. Новый элемент или паттерн? Дизайн-комитет. А/В-тест? Сначала в ДС.
Команда учится делать не «лучше», а «правильнее». Развитие продукта замирает, потому что «в системе так не принято». Это и есть ДС-тюрьма: удобно сторожам, плохо заключённым.
Признаки проблемы
Если вы нашли у себя хотя бы 2-3 из указанных ниже симптомов, то эта статья для вас:
Унификация ради унификации. Понятно, почему нельзя, непонятно — зачем.
Любая, даже самая мелкая, фича сначала упирается в дизайн-систему. Маркетинговые лендинги-однодневки не создаются на скорую руку по гайдам, а вынуждены проходить полноценную верификацию.
Метрики и эксперименты застревают, потому что гипотезы ждут внедрения в ДС дольше, чем живёт бизнес-задача.
Часто звучит «в системе так не предусмотрено», и на этом обсуждение заканчивается.
Команда обходит систему втихаря, если ДС не помогает, а мешает. В итоге создаются костыли и подпольные клоны библиотек.
Медиана времени от «хочу» до «запустили» растёт месяц за месяцем. ДС начинают воспринимать не как инструмент, а как бюрократию.
Уходят лучшие практики: упор делается на контроль и одинаковость, а про доступность или производительность забывают.
Дизайнеры и разработчики начинают дублировать работу вне ДС, тратя двойные усилия.
Дизайн ради дизайна: решения принимаются для красоты системы, а не для пользы продукта.
Люди перестают воспринимать ДС как источник ценности: обновления видятся как «еще одна миграция».
Конечно, бывает по-разному. Например, для маленькой команды некоторые признаки «токсичности» могут быть нормой, а не проблемой, потому что ресурсов мало. В энтерпрайзе же признаки вроде «медианы времени до изменения UI» могут быть искажены внешними факторами (такими как compliance с регуляциями). Но в целом, это десяток чётких показателей того, что с ДС есть какие-то проблемы.
Корни проблемы
Чтобы понять, почему так происходит, давайте разберём типичные причины токсичности дизайн-систем.
Подмена цели
Вместо «чтобы быстрее и надёжнее» проповедуется «чтобы всё одинаковое». Изначальная задача дизайн-системы — ускорять работу и повышать надёжность интерфейсов. Но на практике она часто превращается в инструмент одинаковости ради одинаковости. Экран выглядит «по гайду», но продукт не становится ни быстрее, ни удобнее. Ценность смещается с пользы для пользователя и команды на косметическую унификацию.
Решение: пересобрать цель ДС и зафиксировать её в понятной форме. Главный показатель — скорость и надёжность работы. Одинаковость интерфейсов должна быть лишь средством, а не самоцелью.
Ошибка уровня абстракции
Компоненты проектируются слишком высокоуровневыми и жёсткими, как будто «на все случаи жизни». В итоге реальным продуктовым задачам они не подходят: дизайнеры и разработчики вынуждены обходить ограничения, городить костыли и тратить время на адаптацию.
Решение: делать элементы от простого к сложному, предусматривать варианты настройки. Строить их на основе реальных задач, а не абстрактных идеалов.
Полицейская модель управления
Вместо поддержки Design Ops начинает работать как надзорный орган. Любое отклонение воспринимается как нарушение, решения проверяются по букве гайдлайна. Это убивает инициативу, рождает страх ошибиться и стимулирует команды обходить систему тайком.
Решение: перевести Design Ops в сервисную модель. Ввести сроки ответов, понятную поддержку и чёткую роль «помощников», а не «надзирателей».
Недостаток обратной связи
ДС-команда редко общается с продуктовой командой и разработчиками. В результате её решения оторваны от реальных задач и проблем пользователей.
Решение: наладить регулярные встречи, показывать новые компоненты до внедрения, собирать обратную связь через чаты и опросы.
Замороженные токены
Равно как и отсутствие версионности. Базовые цвета, шрифты и отступы застывают навсегда. Даже небольшое изменение превращается в длинную и болезненную миграцию, которая блокирует работу продукта. Из-за этого обновления откладываются месяцами, а интерфейсы устаревают.
Решение: ввести простую систему версий и сроков поддержки. Старые варианты объявлять «устаревающими» заранее, давать автоматические инструменты для перехода и выпускать обновления по расписанию.
Отсутствует экспериментальный контур
В системе нет «песочницы» для быстрых проб. Любая гипотеза должна пройти тот же тяжёлый процесс, что и серьёзные обновления. В результате простые идеи застревают и не доходят до пользователей.
Решение: создать отдельный слой для экспериментов, где допускаются быстрые и лёгкие проверки. В основную систему поднимать только то, что доказало ценность и устойчивость.
Недостаток прозрачности
Участники не понимают, кто и на основе каких критериев принимает решения о дизайн-системе, отклонении или принятии инициатив. Это рождает недоверие и ощущение произвола.
Решение: сделать процесс открытым. Публиковать заявки и критерии оценки, вести видимый статус инициатив.
Гейткипинг без SLA
Ревью и согласования могут тянуться неделями. Нет прозрачных сроков, непонятно, когда ждать ответа. Решения расплывчаты, инициативы остывают, а команда теряет энергию и интерес к изменениям.
Решение: ввести фиксированные сроки для рассмотрения (например, 3 дня), назначать ответственных для каждой инициативы.
Отсутствие приоритизации
В дизайн-систему пытаются внести всё подряд, не разделяя на must-have и nice-to-have. Это перегружает команду, размывает ценность и создаёт ощущение работы без реального результата.
Решение: научиться расставлять приоритеты по пользе для продукта, бизнеса и пользователей. Сначала ключевые вещи, потом второстепенные.
Игнорирование локальных контекстов
Региональные, брендовые или продуктовые особенности не учитываются. Всё загоняется в одну колею, из-за чего команды вынуждены создавать подпольные обходы.
Решение: предусматривать слой настроек под контексты. Разрешать локальные изменения через понятные механизмы, а не через подпольные костыли.
Отсутствие SLA и метрик самой ДС
Никто не замеряет, ускоряет ли система работу, снижает ли затраты и повышает ли качество. Без данных невозможно понять, приносит ли ДС пользу или только создаёт нагрузку. Всё происходит или «по ощущениям» или «по принуждению».
Решение: ввести набор простых показателей. Замерять их регулярно и менять процессы по результатам. Ниже — примеры таких показателей.
Метрики токсичности дизайн-системы
На самом деле, измерить эффективность ДС вообще не сложно. Вот вам несколько типовых метрик (важно понимать, что их нужно адаптировать и дополнять под реалии своей команды/процессов/продукта).
median time to ui change Среднее время (желательно медиана) до изменения UI. Работает, если есть какие-то исторические данные. Просто сравните показатель до внедрения ДС и после, чтобы понять, реально ли система ускоряет работу.
% blocked PR Процент запросов (например, product request), заблокированных аргументом «не соответствует ДС». Доля задач, которые останавливаются не по сути, а из-за формальных правил.
number of forks & overrides Количество (да и вообще наличие) форков от репозитория с ДС и локальных override'ов. Сколько команд вынуждены городить обходные решения вместо использования ядра.
adoption rate Какие продукты реально подключены к ядру ДС и используют его обновления, а какие живут на клон-сборках и по сути поддерживают собственные версии.
number of experiments Количество экспериментов по сравнению с прошлым периодом. Если гипотезы стали запускать реже — система мешает развитию. Тут могут быть и другие причины, поэтому на этот показатель нужно опираться осторожно.
time to review Среднее время на ревью и согласование изменений в ДС. Если этот процесс занимает недели, значит система тормозит.
contribution success rate Доля предложений в дизайн-систему, которые дошли до внедрения. Если большинство инициатив отбрасывается или зависает, то ДС становится барьером.
update lag Задержка между выпуском новой версии ядра ДС и фактическим обновлением продуктов. Большие лаги показывают, что миграции слишком болезненны.
a11y & performance coverage Процент компонентов, проверенных на доступность и производительность. Если метрика не растёт, ДС концентрируется на унификации, а не на качестве.
user satisfaction Удовлетворённость продуктовых команд работой с ДС (например, через регулярные опросы).
Если исторических данных нет, можно использовать альтернативы: опросы, журналы использования (например, в Figma Library Analytics можно анализировать использование компонентов за последний год).
Не доверяйте только одной метрике, делайте связки, кросс-чек. Если медиана времени растёт, но adoption высокий — проблема не в ДС, а в процессах (например, гейткипинг).
Используйте триангуляцию. Например, 3+ метрики + качество: процент заблокированных + доля форков + опросы. Если заблокированных много, но форков мало — команды просто игнорируют ДС. Если форков много — ДС недостаточно гибкая.
Один показатель (например, рост экспериментов) может быть из-за сезонного пика, а не из-за качества ДС. Комбинируйте с бизнес-метриками (ROI, time-to-market) для полной картины.
Итог
Дизайн-система должна быть хорошо понятной дорогой с разметкой и ограждениями, а не тюрьмой с решётками. Её задача — помогать быстрее и надёжнее создавать продукты, а не тормозить команды ради культа унификации. Если вы заметили признаки токсичности, это повод перестроить цели, процессы и метрики. Сделайте систему помощником, а не надзирателем — и она станет инструментом роста, а не барьером.
Ну и по традиции, мой тг-канал и сайт. В первом я пишу всякое про управление, дизайн, разработку и аналитику, а на втором можно узнать, кто я такой и почему всё это себе позволяю.