dyzajn tokenyTakéDesignové tokeny, Design token, Style tokensPokročilý
Definice
Design tokeny jsou pojmenované hodnoty vizuálních rozhodnutí, jako jsou barvy, odsazení, poloměry rohů nebo velikosti písma, uložené odděleně od kódu i od návrhu. Místo konkrétního zápisu #0B5FFF se v designu i v aplikaci odkazuje název color.action.primary, takže jedna změna hodnoty se promítne do webu, mobilní aplikace i dokumentace současně.
Nezaměňujte: Design token je pojmenovaná hodnota v návrhovém systému, což nemá nic společného s autentizačním tokenem ani s tokenem v jazykových modelech.
Proč se hodnoty pojmenovávají
Barva tlačítka existuje ve firmě obvykle na pěti místech naráz: ve Figmě, v CSS webu, v iOS a Android aplikaci a v šabloně e-mailů. Když se odstín změní, někdo musí najít všech pět výskytů. Design tokeny tuhle vazbu obracejí: hodnota žije na jednom místě pod stabilním názvem a všechny platformy si ji z něj generují. Rebranding se pak mění v úpravu jednoho souboru a spuštění buildu, ne v archeologii napříč repozitáři.
Vrstvy tokenů
Zavedená praxe pracuje se třemi úrovněmi, které se liší mírou abstrakce.
- Primitivní (globální) tokeny popisují surové hodnoty bez významu:
blue.600,space.4. Nikdy se nepoužívají přímo v komponentě. - Sémantické tokeny nesou záměr:
color.text.danger,color.surface.raised. Odkazují na primitivní token a tvoří veřejné rozhraní design systému. - Komponentové tokeny popisují jedno konkrétní místo:
button.primary.background. Používají se tam, kde komponenta potřebuje výjimku.
Právě sémantická vrstva umožňuje tmavý režim nebo režim s vysokým kontrastem: mění se jen to, na jaké primitivum sémantický token ukazuje, komponenty zůstávají beze změny.
Cesta od Figmy do buildu
Zdrojem pravdy bývá strukturovaný soubor, typicky JSON podle formátu DTCG (Design Tokens Community Group), kde má každý token hodnotu a typ. Transformační nástroj z něj vygeneruje CSS custom properties pro web, Swift nebo Kotlin konstanty pro mobil a JSON pro dokumentaci. Generování běží v CI, takže vygenerované soubory nikdo needituje ručně: přepsaly by se při dalším buildu.
{
"color": {
"brand": { "600": { "$type": "color", "$value": "#0B5FFF" } },
"action": { "primary": { "$type": "color", "$value": "{color.brand.600}" } }
}
}Kde se to typicky rozbije
Nejčastější potíž není technická, ale pojmenovací. Token color.blue.primary vypadá neškodně, dokud primární barva nezmodrá na zelenou: název pak lže a nikdo si ho netroufne přejmenovat. Druhým problémem je inflace: pár set tokenů nikdo neudrží v hlavě a designéři začnou hodnoty psát natvrdo. Zdravá sada má desítky sémantických jmen, ne stovky.
Třetí past je jednosměrný tok. Pokud tokeny vznikají v kódu a do Figmy se přepisují ručně, obě strany se rozejdou během několika sprintů. Vyplatí se určit jeden směr synchronizace a druhý zablokovat.
Co tokeny nevyřeší
Design tokeny popisují hodnoty, nikoli chování. Neřeknou, kdy je tlačítko zakázané, jak se komponenta chová při přetečení textu ani zda je kontrast textu dostatečný podle přístupnosti. Kontrolu kontrastních poměrů je nutné přidat jako samostatný test nad vygenerovanými páry barev, protože samotný token o svém použití nic neví.
Příklady z praxe
Tmavý režim bez duplikace komponent
E-shop potřebuje tmavý režim. Místo druhé sady stylů se přemapují sémantické tokeny: color.surface.default ukazuje ve světlém motivu na gray.50 a v tmavém na gray.900. Komponenty se nemění vůbec, protože se odkazují jen na sémantická jména. Přepnutí motivu obstará atribut na kořenovém elementu.
:root { --color-surface-default: var(--gray-50); --color-text-default: var(--gray-900); } [data-theme="dark"] { --color-surface-default: var(--gray-900); --color-text-default: var(--gray-50); } .card { background: var(--color-surface-default); color: var(--color-text-default); }Jedna změna odsazení napříč platformami
Tým zjistí, že základní rozestup 8 px je v mobilní aplikaci příliš těsný, a zvětší space.3 ze 12 na 14 px. Úprava se provede v zdrojovém JSON souboru, CI pipeline vygeneruje nové CSS proměnné pro web a Kotlin objekt pro Android. Ruční zásah do dvou repozitářů odpadá a obě platformy zůstanou vizuálně shodné.
// vygenerováno z tokens.json, needitovat object Spacing { val space3 = 14.dp val space4 = 16.dp }
Časté omyly
- MýtusDesign tokeny jsou jen jiný název pro CSS proměnné.
- Ve skutečnostiCSS custom properties jsou jedním z výstupů, nikoli zdrojem. Tokeny jsou platformně neutrální definice, ze kterých se generuje CSS, Swift, Kotlin i XML pro e-mailové šablony. Web je typicky jen jeden z konzumentů.
- MýtusStačí vyexportovat barvy z Figmy a tokeny jsou hotové.
- Ve skutečnostiExport barev dá primitivní hodnoty bez významu. Užitek vzniká až sémantickou vrstvou a dohodnutým názvoslovím, které přežije změnu odstínu. Bez ní vznikne jen seznam hexů s jinými jmény.
- MýtusTokeny mají smysl jen ve velké firmě s design systémem.
- Ve skutečnostiI jednostránkový web profituje z několika desítek tokenů, pokud má tmavý režim nebo více značek. Náklad je jeden JSON soubor a build krok; přínos roste s počtem míst, kde se hodnota opakuje.
Časté dotazy
- Jak pojmenovávat design tokeny, aby jména vydržela?
- Design tokeny je vhodné pojmenovávat podle role, ne podle vzhledu. Název color.action.primary přežije změnu odstínu, zatímco color.blue.main začne po rebrandingu lhát. Osvědčená struktura jde od obecného ke konkrétnímu: kategorie, role, varianta, stav, tedy například color.text.danger.hover. Primitivní vrstva smí obsahovat popis vzhledu (blue.600), protože se nepoužívá přímo v komponentách. Počet sémantických jmen je dobré držet nízko: pokud si designér nedokáže vybavit správné jméno, sáhne po natvrdo zapsané hodnotě a systém přestane platit.
- Jaký formát souboru se pro design tokeny používá?
- Pro design tokeny se nejčastěji používá JSON ve specifikaci DTCG od Design Tokens Community Group při W3C. Každý token má klíč $value a $type, hodnoty se mohou odkazovat na jiné tokeny složenými závorkami. Formát je záměrně platformně neutrální, takže z jednoho souboru vzniká CSS, Swift, Kotlin i dokumentace. Řada týmů používá vlastní JSON strukturu s transformačním nástrojem, což funguje také, jen se hůř sdílí mezi nástroji třetích stran. Specifikace je stále ve vývoji, proto se detaily mezi verzemi nástrojů liší.
- Kdo má design tokeny vlastnit, designéři nebo vývojáři?
- Design tokeny obvykle vlastní designový tým co do hodnot a názvosloví, zatímco vývojáři vlastní generování a distribuci. Praktické je držet jeden zdroj pravdy a jeden směr synchronizace: buď vznikají ve Figmě a exportují se do repozitáře, nebo žijí v repozitáři a do Figmy se importují. Obousměrná ruční synchronizace se rozejde velmi rychle. Změna tokenu by měla procházet stejným review procesem jako změna kódu, protože dopad má na všechny produkty naráz.
- Kolik design tokenů je rozumné mít?
- Rozumná sada design tokenů obsahuje řádově desítky sémantických jmen a k tomu širší primitivní paletu. Typický produkt vystačí s dvaceti až padesáti barevnými rolemi, šesti až osmi kroky odsazení, čtyřmi poloměry rohů a pěti až sedmi velikostmi písma. Pokud počet komponentových tokenů roste rychleji než počet komponent, je to signál, že sémantická vrstva chybí nebo je špatně navržená. Menší sada s jasnými pravidly se používá častěji než rozsáhlý katalog, ve kterém nikdo nic nenajde.
Zdroje
- Design Tokens Community Group(otevře se v novém okně)
- Using CSS custom properties (variables)(otevře se v novém okně)
- CSS Custom Properties for Cascading Variables Module Level 1(otevře se v novém okně)
- Web Content Accessibility Guidelines (WCAG) 2.2(otevře se v novém okně)
Související pojmy
