Більшість аудитів дизайн-системи затягуються на тижні, тому що намагаються охопити все одразу. Насправді за один фокусний день можна зібрати 80% важливої інформації і скласти чіткий план дій.
Ось структура аудиту, перевірена на десятках проектів. Від 0 до повного звіту — за 8 годин.
Ранок: інвентаризація (2 години)
Першим кроком — зрозуміти що взагалі є. Не оцінювати якість, просто зібрати список.
Компоненти: відкрийте Figma-файл дизайн-системи і виписайте всі компоненти. Скільки їх? Чи є дублікати (Button і ButtonPrimary як окремі компоненти)? Чи всі вони справді використовуються в продукті?
Токени: скільки їх? Яка архітектура (primitive/semantic/component)? Чи є токени в коді, і чи вони синхронізовані з Figma?
Документація: що задокументовано, а що ні? Де живе документація?
День: аналіз (4 години)
Тепер — якість. Перевіряємо чотири виміри:
1. Консистентність — чи виглядають однакові компоненти однаково? Відкрийте продуктовий файл і порівняйте з системою. Типові знахідки: кнопки різних розмірів що мають бути однаковими, spacing що не відповідає токенам, shadow що захардкоджені замість змінних.
2. Покриття — чи система покриває реальні юзкейси продукту? Шукайте елементи в продукті, яких немає в системі — це gap. Шукайте компоненти в системі, яких немає в продукті — це dead weight.
3. Технічний борг — чи є компоненти без Auto Layout? Чи є hardcoded кольори замість токенів? Запустіть пошук по Figma: будь-який "Frame" без Auto Layout у компонентах — підозрілий.
4. Accessibility — перевірте контраст ключових текстових елементів через Figma A11y плагін. Перевірте наявність focus states у компонентах.
Quickwin: знайдіть всі захардкоджені кольори у Figma через плагін "Variables Cleaner" або "Token Cop". Зазвичай їх від 30 до 200 навіть у "зрілих" системах.
Вечір: пріоритизація і звіт (2 години)
Зберіть всі знахідки в один список. Категоризуйте кожну по двох вимірах: вплив (critical / high / medium / low) і зусилля (hours / days / weeks).
Критичні проблеми — ті, що прямо впливають на якість продукту (accessibility fails, missing компоненти що використовуються). Косметичні — naming inconsistencies, застарілі screenshotи в документації.
Матриця пріоритетів
- Починати зараз: Critical impact + Low effort (quick wins)
- Планувати наступний спринт: Critical impact + High effort
- Робити між спринтами: Low impact + Low effort
- Можливо ніколи: Low impact + High effort
Формат звіту що сприймається
Два слайди: executive summary (3 числа — скільки компонентів, скільки проблем знайдено, скільки критичних) і деталізований список проблем з пріоритетами. Уникайте довгих текстів — PM і розробники читають списки, не есе.
Аудит без плану дій — аудит у нікуди. Завершуйте день конкретним списком: що, хто, коли.