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

На ранней стадии: получить поддержку руководства
На среднем этапе: улучшить кодовую базу и единообразие дизайна
На продвинутом этапе: масштабировать процессы, ускорить поддержку, оптимизировать рабочие процессы

Мы так и сделали в Doctolib. Попутно это помогло нам избавляться от устаревшего кода и следить, чтобы разработчики не писали кастомные решения там, где можно использовать готовые компоненты. Для этого мы внедрили методы отслеживания и специальные инструменты для команд.

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

Начнём с Figma
С Figma проще — там хотя бы есть что посчитать.

Дизайнеры работают с несколькими библиотеками компонентов. Мы придумали систему обозначений через эмодзи:
💠 Oxygen — базовые компоненты. Атомы системы. Они независимы друг от друга и не содержат бизнес-логики.
🧩 Modules — модули с бизнес-логикой. Обычно собраны из компонентов Oxygen.
💟 Icons — библиотека иконок.

Мы в Figma просто считаем компоненты с эмодзи и без них. Но есть куча нюансов:

Шрифты: Если текст использует правильный стиль шрифта и цвета (или переменную) — засчитывается.
Вспомогательные штуки (стрелки, пометки для разработчиков, стикеры с котиками) — игнорируем.
Устаревшие компоненты с эмодзи 💠, которые заменили на ☠️ — не засчитываются.

С кодом сложнее. Используем две системы одновременно:

Первая работает похоже на Figma. Наши компоненты помечены data-атрибутом со статусом: Oxygen (актуальные официальные), устаревший или не рекомендованный.

Вторая — правила ESLint генерируют комментарии в коде, которые тоже учитываем.

Пример: официальный компонент, переписанный через кастомный CSS, считается наполовину совместимым. Компонент-то из дизайн-системы, но правило ESLint нарушено.

По срокам учитываем только файлы, которые редактировали за последние 30 дней. Смотреть на архивные файлы смысла нет.

Мы разобрались, как рассчитать дизайн-систему — и что дальше?
Следующий шаг — дать разработчикам реально работать с этим. Поэтому мы собрали для команд набор специальных инструментов.

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

Этот самодельный плагин сканирует активную страницу файла и показывает:

• общий процент соответствия
• процент соответствия для каждой секции и фрейма
• разбивку элементов по секциям/фреймам (сколько Oxygen-компонентов, модулей и проблемных элементов)
• список ссылок на слои, которые нужно исправить

Мы не отслеживаем статистику использования плагина, но результаты говорят сами за себя. За четыре месяца команда подняла средний показатель соответствия с 47% до 86%.

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

OxyScan доступен в Figma Community. Можете попробовать (только используйте ту же систему эмодзи, что указана в описании).

На основе OxyScan мы создали автоматизацию для извлечения данных в дашборд. Скрипт запускается каждую ночь, сканирует все файлы в указанных командах Figma и находит страницы с высокой детализацией. Эти страницы отмечаются эмодзи 📘 — так сканер понимает, какие из них уже переданы разработчикам.

У каждой команды есть свой дашборд, где видно:

• Процент соблюдения стандартов и его динамику
• Какие компоненты устарели или помечены как deprecated — со ссылками на конкретные файлы
• Все нарушения правил ESLint с путями к файлам

Чтобы понять, какие файлы относятся к какой команде, мы используем функцию code owners в Github.

Чтобы команды могли видеть технический долг не только в виде списков URL или графиков на дашборде, мы сделали инструмент, который показывает статус компонентов прямо на боевом сайте.

Инструмент называется X-Ray — это расширение для Chrome, которое подсвечивает компоненты цветом в зависимости от их состояния: актуальные, устаревшие или вообще снятые с поддержки. Если компонент переопределён через CSS или использует старые свойства, он автоматически помечается как несоответствующий стандартам.

Вот как это выглядит на главной странице:

• Зелёным — актуальные компоненты (заголовки Headline и Search)
• Оранжевым — устаревшие компоненты (поля поиска)
• Красным — снятые с поддержки компоненты (правая кнопка в верхнем меню)

Что не подсвечено — то вообще не из дизайн-системы.

С этими инструментами команды стали внимательнее следить за соответствием своего кода стандартам дизайн-системы. Это помогает развивать саму систему — когда люди видят конкретные метрики, они начинают исправлять проблемы.

Сейчас работаем над оценкой качества компонентов. Хотим смотреть не только на то, правильно ли используются готовые компоненты, но и на качество их кода и доступность.