Design systémy: najprv tokeny

Väčšina design systémov padá na tom istom mieste: začínajú komponentmi.

Niekto otvorí Figmu, navrhne button. Niekto iný otvorí editor a button nakóduje. O šesť týždňov je tam štyridsaťsedem buttonov naprieč dvanástimi komponentmi a nikto nevie vysvetliť, ktorý spacing token používa padding karty, alebo či je hover farba navigácie tá istá ako hover farba linku, alebo prečo error state na jednom formulári vyzerá inak ako error state na tom vedľa.

Riešením nie je „napíš style guide”. Riešenie je štrukturálne. Začni s tokenmi. Vydaj tokeny skôr, než existuje akýkoľvek komponent. Funguje to z toho istého dôvodu, prečo to ľudia tak často preskakujú — v prvom týždni to nevyzerá ako progress.

Čo to vlastne znamená najprv tokeny

Tokeny sú atómy. Farby, spacing hodnoty, typografické škály, trvania pohybu, šírky borderov. Nemajú vlastnú vizuálnu identitu — sú to len pomenované hodnoty.

Tokens-first znamená, že tvoj prvý commit na novom projekte je súbor tokens.css. Pred layout shell-om. Pred navigáciou. Pred prvou stránkou. Definuješ celú vizuálnu slovnú zásobu a každý nasledujúci riadok CSS alebo JSX musí použiť token alebo zdôvodniť, prečo nie.

Obmedzenie, ktoré sa v prvom týždni zdá pomalé, je presne to, čo drží design konzistentný v šiestom mesiaci.

Takto otváram svoj tokens.css na novom projekte:

:root {
  /* Surface */
  --bg:    #0A0A0B;
  --bg-2:  #0F0F10;
  --bg-3:  #121215;
 
  /* Foreground */
  --fg:    #F5F5F3;
  --fg-2:  #D4D4D2;
  --fg-3:  #9A9A98;
 
  /* Rules */
  --rule:        rgba(245, 245, 243, 0.08);
  --rule-strong: rgba(245, 245, 243, 0.18);
 
  /* Type scale */
  --t-h1:    clamp(2.5rem, 6vw, 6.25rem);
  --t-body:  1rem;
  --t-micro: 0.6875rem;
 
  /* Spacing */
  --sec:   clamp(3.5rem, 8vw, 7.5rem);
  --pad:   clamp(1.25rem, 4vw, 3rem);
  --stack: clamp(1rem, 2vw, 2rem);
}

Zatiaľ tu nie je nič vizuálne. Ale každé rozhodnutie o tom, ako vyzerá karta, čo button robí pri hoveri, aký padding dostane sekcia — je obmedzené na hodnoty, ktoré už existujú.

Prečo sa to skladá

Tri skladajúce sa benefity, v poradí ako rýchlo ich pocítiš.

1 · Design-dev sync prestane byť problém. Keď Figma súbor aj CSS súbor konzumujú tie isté pomenované tokeny, neexistuje žiadne „aký padding tu designér použil?" Designér použil --pad. Engineer použije var(--pad). Handoff je štrukturálny, nie interpretačný.

2 · Rebrand sa stáva opraviteľným za jedno popoludnie. Túto stránku (nkovalcin.com v3) som počas P0 prestaval štyrikrát, kým som usadil aktuálny smer. Každý prestav bol edit tokens súboru a reflow komponentov. Žiadne prehrabávanie sa cez 40 komponentov pri hľadaní hardcoded farieb. Stránka je tokens súbor, zosilnený.

3 · Dark mode, light mode, accessibility bumpy sú triviálne. Ak je každá hodnota token, prehodenie do light modu je prepis jedného bloku. Boost kontrastu pre AA compliance je zmena troch hodnôt. Keď sú farby hardcodované, každé z toho sa stáva víkendovým projektom.

Problém disciplíny

Tokens-first padá z toho istého dôvodu ako väčšina engineeringových praktík: nikto to nevynucuje po treťom týždni.

Pokušenie, keď v stredu poobede zízaš na button a snažíš sa do piatka odoslať feature, je napísať padding: 12px. Je to rýchlejšie. Funguje to. Nikto to nepôjde reviewovať.

O tri mesiace máš v codebase 800 inštancií padding: 12px a design tím chce posunúť základný spacing rhythm na 14px. Takto sa hromadí design debt — jedna pragmatická skratka po druhej, žiadna z nich sa sama o sebe nezdala dôležitá.

Dve taktiky, ktoré fungujú:

Napíš lint pravidlo. Stylelint má declaration-property-value-allowed-list, ktoré označí akúkoľvek raw pixel alebo hex hodnotu. Hluk je v prvom týždni bolestivý. Potom chytí všetko. Lint pravidlo je disciplína.

Píš tokeny PRÍLIŠ agresívne. Ak sa chystáš použiť padding: 12px, najprv sa spýtaj: nemal by tu byť --pad-sm token? Zvyčajne je odpoveď áno. Pridaj ho, použi ho. Časom tvoj tokens súbor narastie tak, aby pokryl skutočnú slovnú zásobu, ktorú tvoj design používa — a lint pravidlo bude menej hlučné.

Druhú taktiku väčšina tímov preskočí. Napíšu lint pravidlo, dva týždne s ním bojujú, potom ho vypnú. Riešenie nie je vypnúť pravidlo — je priznať, že tvoj tokens súbor je neúplný, a rozšíriť ho.

Čo netokenizovať

Tokeny sú pre slovnú zásobu. Nie sú pre gramatiku.

Netokenizuj layout špecifiká. Grid templates, flexbox patterny, aspect ratiá — to sú per-komponent rozhodnutia, nie zdieľaná slovná zásoba. Vnútorný grid kartovej komponenty nie je token; gap medzi children gridu možno áno (--gut).

Netokenizuj komponentovo-špecifické magické čísla. Polomer 6px live-dotu nepotrebuje --livedot-size token. Daj to len do CSS komponenty. Tokeny sú pre veci, ktoré sa opakujú naprieč ≥3 komponentmi.

Nepredbiehaj sa s generickými škálami, ktoré nepoužiješ. Nerob --fg-1 až --fg-9. Použiješ tri z nich. Urob --fg, --fg-2, --fg-3 a --fg-4 a skonči. Každý token, ktorý definuješ, je rozhodnutie, ktoré sa musí udržiavať — a väčšina estetických škál má 4–5 zmysluplných zastávok, nie deväť.

Ak začínaš projekt a chceš pomoc so štruktúrovaním tokenov skôr, než vydáš jeden komponent, to je súčasť toho, ako vediem discovery sprinty.

Kick-off rituál

Keď začínam novú spoluprácu, prvý trojdňový blok je vždy:

Deň 1 — Color tokeny (surface + foreground + rules + signals). Vydaj jednu stránku, ktorá renderuje veľké bloky každej farby s jej názvom. Pozri sa na skutočné hodnoty v skutočnom UI chrome. Upravuj, kým to nesedí. Browser je source of truth, nie Figma súbor.

Deň 2 — Type tokeny + scale. Vydaj demo stránku type-scale. Veľkostné triedy od H1 po mono-small, každá s labelom. Skontroluj v prehliadači, na mobile, na skutočnom hardvéri, ktorý budú používať cieľoví používatelia. Uprav.

Deň 3 — Spacing + motion. Vydaj stránku section-rhythm s variáciou var(--sec) medzi sekciami. Skontroluj vertikálny rytmus na dlhom scrolle. Uprav.

Až po tretí deň sa začínajú komponenty.

Pravidlo jedného týždňa

Ak tvoj tokens súbor neprežije týždeň feature práce bez toho, aby niekto chcel hardcodovať hodnotu, tokens súbor je zlý.

Vráť sa. Pozri sa, čo bolo hardcodované. Je to buď niečo, čo by mal byť token (a nie je), alebo komponentovo-lokálna hodnota (a nikdy nemala lákať k tokenizácii).

Dobrý tokens súbor je malý. Možno 30–50 pomenovaných hodnôt, spolu. Ak si na 200 tokenoch a rastieš, zamiešal si si slovnú zásobu s gramatikou a lint pravidlá s tebou budú bojovať večne.

Drž to malé. Drž to opinionated. Drž to ako prvé.

Takeaways — čo vydať tento týždeň

• Otvor nový tokens.css skôr, než otvoríš čokoľvek iné. Aj na napol postavenom projekte. Refactoruj smerom k nemu.
• Stropuj počet tokenov. 30–50 pomenovaných hodnôt. Ak si nad tým, zauditni, čo vôbec nemá byť tokenom.
• Zapni Stylelint pravidlo v deň jedna. Týždeň s ním bojuj. Potom sa stane neviditeľným.
• Postav tokens demo stránku. Vlastne tri stránky — jednu pre farbu, jednu pre typografiu, jednu pre spacing. Použi ich ako source of truth pre design reviews.
• Odmietaj hardcoded hodnoty pri code review. Každá pixel hodnota alebo hex kód, ktorý sa dostane do repa bez odkazu na token, je technický dlh. Chyť to v PR, nie v šiestom mesiaci.
• Re-audituj tokeny každý kvartál. Vymaž tie, ktoré nikto nepoužíva. Povýš opakované hardcoded hodnoty na nové tokeny. Súbor žije, nie je zamrznutý.

Disciplína je malá, ale neodpúšťajúca. Nový projekt s 30 starostlivo vybranými tokenmi, vynútenými lint pravidlom, sa vydáva rýchlejšie a krajšie ako ten istý projekt s komponentmi napísanými proti vibes. Tokens súbor je tvoj design systém, zosilnený.

Súvisiace: Stavanie moderných webových aplikácií v 2026 · Vlastniť svoj stack v 2026 · Ako vediem discovery sprinty