Tvoříme tokeny jako lidé, ne jako roboti
Onehdá jsem takhle přemýšlel, jakým způsobem pojmenovávat design tokeny tak, aby to bylo logické, čitelné nejen pro mě ale i pro všechny co s tím příjdou do styku, ve jménech nebyl zmatek. A taky aby se v tom neškrábali ve vlasech vývojáři.
To onehdá vlastně bylo, když jsme měli z jednoho výchozícho tématu udělat další čtyři a když jsme zjistili, že se stávající sadou tokenů to ale fakt nepůjde.
A tak jsem chtěl systém, který přežije víc než ty čtyři témata, ale potenciálně víc. Který unese nějaké to redesignové kolečko, a který se nezhroutí pod požadavky UX designérů. Který bude chápat i někdo, kdo s ním předtím běžně nepracoval. A až jednou, příští rok na podzim, bude urgentní potřeba změnit řez fontu v nadpisu AccordeonPanelu, bude to brnkačka na 10 minut.
Výsledkem procesu byla namingová struktura, která má pět částí. Každá z nich se přidá do názvu tokenu jen tehdy, když je relevantní. Nehoníme se za rigidním stromem, kde má všechno pět úrovní, i když třeba čtyři z nich nic neříkají.
Zhruba to vypadá takto:
Component
Začínáme vždy názvem komponenty. Tím se definuje základ – tlačítko, tooltip, tabmenu, message, cokoliv. To je povinné. Vždy.
button tooltip message
Variant
Pokud má komponenta více než jednu variantu (například primary, secondary u tlačítka), pojmenujeme ji. Pokud ne, přeskočíme.
button.primary
Part
Má komponenta v rámci varianty další části? Třeba text, ikonu, titulek? Pokud ano, pojmenujeme ji.
button.primary.text tabmenu.icon message.title
State
Má část nebo varianta různý stav? Hover, disabled, active? Jestli ano, přidáme ho. Pokud ne, můžeme ignorovat.
button.primary.text.disabled
Property
Nakonec, vlastnosti. O jakou vlastnost jde? Barvu, font family, velikost, gap, padding? Vlastnost by měl být finální údaj v řetězci.
message.text.fontFamily
Příklad ze života
Komponenta je jasná, button, má varianty, typicky je to primary a secondary nebo outline. Má několik součástí například ikonu a text, a text může mít několik stavů, base, hover, a třeba disabled. Na komponentní token je potom navázaná semantická hodnota pro tlumenou barvu textu.
Takhle jednoduše můžeme zapsat rozdílné fonty pro nadpis a běžný text u komponenty Message. U typografie nemáme žádné varianty nebo stavy, pouze dvě části.
Pravidlo: nepřidávej zbytečnosti
Celý naming systém by měl ungovat jako filtr – pokud některý z kroků nedává smysl (například tooltip nemá varianty ani části), jednoduše ho přeskočíme. Token jako
tooltip.default.base.normal.paddingInline
by vůbec neměl vzniknout.
Čili, ano, cílem je vymyslet si takový naming system aby fungoval pokud možno vždy a všude, ale je pak nesmysl se ho zuby nehty držet při vymýšlení jmen pro parametry které reálně neexistují. Řetězec component.variant.state.part.property mě osobně zatím funguje všude, ale pokud bych ho nesprávně používal, polezou z něho nesmyslné názvy - tokeny je potřeba pojmenovávat lidsky a s rozumem. Nepíšeme to, co neexistuje.
Navíc: doplnit token pro nový stav nebo část je vždy snadnější, než se snažit nacpat ho do příliš striktní struktury. Takhle zajistíme, že náš design systém bude časem stárnout důstojně – a ne se lámat pod vlastní vahou.
Tenhle přístup používáme s úspěchem i v praxi – konkrétně v design systémech VIGo a SignFace, kde se osvědčil jak během rychlého vývoje, tak při klidnější fázi údržby. Strukturu tokenů se nám daří udržovat konzistentní a čistou. Výjimkou jsou jen výjimečně složité organismy, které ale zpravidla vychází z velmi specifických požadavků klienta – v běžné praxi se s nimi jeden moc často nesetká.
Shrnutí
Pokud stavíš vlastní design systém, nechceš, aby se ti z toho časem stal nečitelný labyrint. Struktura kterou jsem tady popsal, je jednoduchá, rozšiřitelná a srozumitelná bude i do budoucna. Nepřemýšlíš nad tím, co tam být musí, ale co tam dává smysl. Přesně jako když stavíš dobrý design – zbavuješ se zbytečného, ale ne funkčního.
A to je přístup, kterému můžeme věřit. Protože design token není jen hodnota. Je to pojmenovaná myšlenka. A ta by měla být jasná každému, kdo ji čte.