Design tokenek
A design token névvel ellátott alapérték, például szín, spacing, typography vagy radius, amelyet több komponens és platform következetesen használhat.
Röviden
A design token névvel ellátott alapérték, például szín, spacing, typography vagy radius, amelyet több komponens és platform következetesen használhat.
Vizuálisan
A token jelentést ad a nyers designértékeknek
Ugyanazt a helyzetet kétféleképp nézd meg: először a tipikus hibát, utána azt a megoldást, amelyik jobban támogatja a felhasználó feladatát.
×
GYAKORI HIBA
#111, 16px, 8px mindenhol kézzel beírva
color: #111111;
padding: 16px;
border-radius: 8px;
/* ismételd mindenhol */
Nem derül ki, mely értékek tartoznak ugyanahhoz a szerephez, ezért egy globális módosítás sok kézi keresést és hibalehetőséget okoz.
✓
HELYES IRÁNY
text.primary, space.4, radius.md
text.primary
#111111
space.4
16px
radius.md
8px
button.primary
ink + white
A token neve a szerepet írja le, így a vizuális rendszer programozhatóbbá és következetesebbé válik.
Mit jelent a design tokenek?
A design token névvel ellátott alapérték, például szín, spacing, typography vagy radius, amelyet több komponens és platform következetesen használhat.
A tokenek elválasztják a jelentést a konkrét értéktől. Így például a `text.muted` szerepe stabil maradhat akkor is, ha a mögöttes hex érték változik.
A legfontosabb alapelvek
- Szemantikus neveket használj, ne csak gray500.
- A spacing skála legyen korlátozott.
- A tokenek kapcsolódjanak a komponensekhez.
- Ne tokenizálj minden egyszeri értéket szükségtelenül.
Gyakorlati példa
A `color.text.primary`, `color.text.muted`, `space.3`, `radius.md` elnevezésekből a fejlesztő érti a szerepet, nem csak egy nyers számot másol.
Szemantikus tokenekből épülő komponens
text.primary
space.4
radius.md
button.primary
Gyakori hibák
- Minden pixelérték külön token.
- Szemantika nélküli számozás kizárólag.
- Komponensben token helyett hardcode override-ok.
Hogyan alkalmazd a saját felületeden?
Ne izolált szabályként kezeld a témát. A design tokenek akkor működik jól, ha a felhasználó céljával, a tartalom fontossági sorrendjével és a teljes felület többi döntésével együtt vizsgálod.
Teszteld valós feladattal: adj a felhasználónak konkrét célt, figyeld meg, hol bizonytalanodik el, mit ért félre, és mely pontokon kell indokolatlanul gondolkodnia. A jó UI/UX döntés nem attól jó, hogy látványos, hanem attól, hogy kiszámíthatóbbá és könnyebbé teszi a feladat elvégzését.
A vizuális minőség és a használhatóság nem egymás ellenfelei. A jó felület mindkettőt ugyanannak a felhasználói célnak rendeli alá.
Mikor érett a rendszer?
Egy tervezési rendszer akkor kezd valódi értéket adni, amikor csökkenti az ismételt döntések számát, miközben nem akadályozza a megfelelő eltéréseket. Ha ugyanazt a gombot, formállapotot vagy spacinget minden csapat újra feltalálja, nincs közös rendszer; ha minden kivételt tilt a rendszer, túl merevvé vált.
A dokumentációt a valós használat alapján tartsd karban. Egy komponens akkor kész, ha a vizuális változatok mellett ismert a szemantikája, interakciója, állapotai, accessibility követelménye és az is, mikor nem szabad használni.
- csökken-e az egyedi override-ok száma
- ugyanaz a komponens minden állapotban következetes-e
- a design és kód ugyanazokat a tokeneket és szabályokat követi-e
Gyakori kérdések
Miért fontos a design tokenek?
A tokenek elválasztják a jelentést a konkrét értéktől. Így például a `text.muted` szerepe stabil maradhat akkor is, ha a mögöttes hex érték változik.
Mikor érdemes tesztelni?
Már korai wireframe vagy prototípus szinten is. Minél később derül ki egy alapvető használhatósági probléma, annál drágább lehet a javítása.