Дизайн-система: з чого вона складається і як перевірити, що нею користуються

Дизайн-система живе в продакшн-HTML. Не у Figma, не в репозиторії з компонентами. Її видно в тому, скільки різних відтінків сірого реально віддається браузеру, скільки на сайті варіантів кнопки «Купити» і чи однаково поводиться фокус на клавіатурі в чекауті й у формі зворотного зв'язку. Усе інше — наміри.

Нижче — те, з чого систему складають, і як побачити власними очима, користуються нею чи ні.

Що ламається, коли системи немає

Симптоми впізнавані. У зібраному CSS живе 40 відтінків сірого, бо кожен новий екран приносив свій. Кнопка «Відправити» на трьох сторінках має три різні висоти. Розробник, отримавши макет нового розділу, витрачає півдня на з'ясування того, який саме відступ тут «правильний», і врешті бере той, що стояв у сусідньому компоненті.

Дорожче обходиться інше — неможливість швидко змінити щось глобально. Бренд змінює основний колір: у системі це правка одного токена. Без системи — пошук по всьому репозиторію, тиждень правок і майже гарантовано забутий hover десь у футері старого лендінга.

Три рівні: токени, компоненти, композиція

Рівень 1: токени

Токени — атомарні значення, на які посилається все інше. Жодного «магічного» числа у компоненті бути не повинно.

:root {
  /* Кольори */
  --color-primary-50: #f0fdf4;
  --color-primary-500: #22c55e;
  --color-primary-900: #14532d;

  /* Типографіка */
  --font-family-sans: 'Inter', system-ui, sans-serif;
  --font-size-sm: 0.875rem;
  --font-size-base: 1rem;
  --font-size-lg: 1.125rem;

  /* Відступи */
  --spacing-1: 0.25rem;
  --spacing-2: 0.5rem;
  --spacing-4: 1rem;
  --spacing-8: 2rem;

  /* Тіні */
  --shadow-sm: 0 1px 2px rgba(0, 0, 0, 0.05);
  --shadow-md: 0 4px 6px rgba(0, 0, 0, 0.1);
}

Правило, яке економить найбільше суперечок: у компоненті не можна писати колір напряму. Тільки змінна. Немає потрібного відтінку — це привід поговорити про токен, а не додати ще один хардкод.

Рівень 2: базові компоненти

// Button.tsx
interface ButtonProps {
  variant: 'primary' | 'secondary' | 'ghost'
  size: 'sm' | 'md' | 'lg'
  children: React.ReactNode
  isLoading?: boolean
}

export function Button({
  variant = 'primary',
  size = 'md',
  children,
  isLoading
}: ButtonProps) {
  return (
    <button
      className={cn(
        'inline-flex items-center justify-center',
        'font-medium transition-colors',
        'focus-visible:outline-none focus-visible:ring-2',
        variants[variant],
        sizes[size]
      )}
      disabled={isLoading}
    >
      {isLoading && <Spinner className="mr-2" />}
      {children}
    </button>
  )
}

Зверніть увагу на focus-visible:ring-2. Обведення фокуса — єдиний спосіб для людини, яка ходить сторінкою з клавіатури, зрозуміти, де вона зараз. Найчастіше його вбиває звичка писати outline: none у ресеті, щоб прибрати «некрасиву рамку», і нічого не повернути натомість. Коли кільце вшите в базовий компонент, про доступність не треба згадувати на кожному екрані окремо.

Рівень 3: композиція

// Card.tsx
export function Card({ children }: { children: React.ReactNode }) {
  return (
    <div className="rounded-xl border bg-card p-6 shadow-sm">
      {children}
    </div>
  )
}

Card.Header = function CardHeader({ children }) {
  return <div className="mb-4">{children}</div>
}

Card.Title = function CardTitle({ children }) {
  return <h3 className="text-lg font-semibold">{children}</h3>
}

Card.Content = function CardContent({ children }) {
  return <div className="text-muted-foreground">{children}</div>
}

Інструменти

Для дизайну: Figma для самих компонентів, Figma Tokens (Tokens Studio) для синхронізації значень із кодом, Storybook як спільна вітрина — дизайнер відкриває там реально зібраний компонент.

Для розробки: Tailwind CSS для утиліт, Radix UI як доступні примітиви — діалоги, дропдауни, тултипи, комбобокси, тобто рівно ті елементи, самописні версії яких майже завжди виходять недоступними з клавіатури. CVA для варіантів.

Набір інструментів мало що вирішує сам по собі. Ми міряли два інтернет-магазини на одній і тій самій OpenCart: TTFB 126,3 мс у одного і 1 544,5 мс у іншого (наш зовнішній HTTP-вимір, 31.07.2026). Різниця у дванадцять разів. Платформа однакова, дисципліна різна. З дизайн-системами так само: Tailwind і Radix не заважають зробити безлад, вони лише знімають частину рутини.

Адаптивність як правило системи

Google індексує сайти за мобільною версією (mobile-first indexing — це описано в документації Google Search Central). Тобто те, що бачить смартфон, і є тим, що бачить пошуковик. Механізм прямий: якщо на мобільному ламається меню, фільтр не відкривається, а кнопка дії ховається під клавіатурою — цей трафік не конвертується, хоча вже оплачений рекламою або витраченим на SEO часом. Мобільна робота не приводить нових людей. Вона припиняє втрачати вже приведених.

Чесна межа: мобільний viewport у розмітці — це необхідний мінімум. Доказом зручності він не є. Зовні виміряти можна лише факт наявності. Наскільки легко пройти чекаут великим пальцем однієї руки, показують тільки живі сесії. У B2B-каталогах частина закупівельників справді працює з десктопа, і там пріоритет мобільної версії нижчий — це чесніше сказати, ніж продавати мобільну оптимізацію як універсальний пріоритет.

Тому брейкпоінти і типографічна шкала мають бути токенами. Інакше кожен розробник вигадує їх заново, і в бандлі з'являється медіазапит на 767px поруч із 768px.

Доступність: два правила, які закривають більшість проблем

Контраст тексту до фону не нижче 4.5:1 для звичайного розміру — це критерій 1.4.3 у WCAG 2.2 від W3C, не чиясь думка. Перевіряється у DevTools за секунду, закладається один раз у палітру токенів. Провалюється зазвичай не основний текст, а плейсхолдери в полях і сірі підписи під заголовками — усе те, що робили «світлішим, щоб не сперечалось із контентом».

Друге правило — prefers-reduced-motion. Медіазапит описаний у MDN; людям з вестибулярними розладами анімовані переходи буквально викликають нудоту. Обробіть його в базовому шарі стилів, і жоден новий компонент про це не забуде.

Як перевірити, чи системою реально користуються

Тут зазвичай ставлять вигадану ціль на кшталт «покриття понад 80%». Ціль без методу вимірювання нічого не варта. Метод простий: беріть продакшн і рахуйте.

Скільки насправді кольорів і розмірів шрифту в зібраному CSS:

# унікальні hex-кольори у бандлі
grep -oE '#[0-9a-fA-F]{3,8}' dist/assets/*.css | sort -u | wc -l

# усі розміри шрифту з частотою
grep -oE 'font-size:[^;]+' dist/assets/*.css | sort | uniq -c | sort -rn

Мініфікатор частину hex схлопне у скорочену форму, тож число вийде приблизним — для рев'ю цього досить. Якщо в токенах десять кольорів, а в бандлі їх 60 — система існує тільки на папері.

Так само перевіряється будь-яке правило, записане в систему. Наприклад, «усі зображення нижче першого екрана вантажаться відкладено»:

curl -s https://example.com/catalog | grep -coE '<img[^>]*'
curl -s https://example.com/catalog | grep -coE '<img[^>]*loading="lazy"'

Ми рахували саме так на чужих сайтах. У роздрібного магазину садового інструменту відкладено вантажаться 66 з 69 зображень, тобто 96% — правило застосоване майже всюди. У магазину засобів самооборони — 154 з 190, це 81%: третина картинок правило пропустила (обидва заміри наші, зовнішні, 31.07.2026). Один рядок у терміналі дає число, з яким уже є про що говорити на рев'ю: чому саме ці шаблони випали.

Третій зріз — вага документа. У партії з шістнадцяти виміряних нами сайтів найлегша сторінка віддавалася в 102,1 КБ HTML, найважча — 751,2 КБ. Роздутий HTML часто означає, що замість одного компонента в шаблон копіювали розмітку.

Порядок робіт

Аудит іде першим: зібрати всі існуючі кнопки, поля і картки в один файл і подивитися на них поруч. Зазвичай саме тут стає видно, що варіантів кнопки не три, а одинадцять.

Далі фундамент: токени, налаштування інструментів, п'ять-сім найчастотніших компонентів. Не намагайтеся покрити все одразу — компонент, який ніхто не використовує, це мертвий код із витратами на підтримку.

Потім система росте разом із продуктом. Новий компонент додається тоді, коли той самий патерн знадобився втретє. Не тоді, коли хтось передбачив, що знадобиться.

Скільки це займе — залежить від того, скільки екранів уже написано і чи є в команді людина з правом сказати «ні» новому варіанту кнопки. Без цієї ролі система розповзається за кілька спринтів незалежно від якості токенів.

Документація компонента

Для кожного компонента корисно тримати опис призначення, приклади використання, Props API і нотатки з доступності. Окремо — явні заборони. Вони важать не менше за приклади:

Button — основний інтерактивний елемент для дій користувача.

Primary — головна дія на сторінці.
Secondary — другорядні дії.
Не використовуйте більше одного Primary на екрані: якщо головних дій дві, значить, жодна не головна.

Чого дизайн-система не дає

Вона не робить продукт зрозумілим: ідеально консистентний інтерфейс з поганою логікою залишається поганим інтерфейсом, просто акуратним. У перші місяці вона не прискорює розробку, а забирає час. І пріоритетів вона не розставляє — якщо у вас відвалюється чекаут, дизайн-система почекає.

Що вона дає точно — можливість змінювати вигляд продукту передбачувано і перевіряти стан справ однією командою в терміналі, а не суперечкою на планерці.

Потрібен погляд збоку на ваш фронтенд? Напишіть нам — подивимось, що реально віддається браузеру.