Design Tokens Community Group vydala stabilní specifikaci Design Tokens 2025.10. Pro týmy, které propojují návrh, kód a dokumentaci, to není jen nový zápis barev, mezer nebo typografie. Důležitější je, že tokeny začínají sloužit jako společné rozhraní mezi designem a vývojem. U takového rozhraní už nestačí vědět, jak se hodnota jmenuje. Tým musí vědět i to, kdo ji smí změnit a jak se změna dostane do vydané verze.

Design token se dá popsat jednoduše: je to pojmenované designové rozhodnutí. Třeba barva primárního tlačítka, mezera mezi kartami nebo styl nadpisu. V kódu může vypadat jako proměnná, ale jeho význam je širší. Token říká, že určitá hodnota má v systému konkrétní roli a má se používat stejně na více místech.

Právě tím se liší od obyčejné konstanty v CSS. Když vývojář změní jednu barvu v komponentě, mění jednu hodnotu. Když tým změní token color.action.primary, může tím zasáhnout web, mobilní aplikaci, dokumentaci i návrhový soubor. Taková úprava už nepatří jen do vrstvy vzhledu. Mění pravidlo, na které jsou napojené další části systému.

Co se v roce 2025 změnilo

Design Tokens Community Group oznámila 28. října 2025 první stabilní verzi specifikace Design Tokens 2025.10. Nejde o plné W3C Recommendation, ale o stabilní výstup Community Group. Prakticky to znamená, že autoři nástrojů a design systémů mají pevnější základ, o který se mohou opřít.

Specifikace má tři hlavní části. Format Module popisuje základní zápis tokenů. Color Module řeší barvy včetně barevných prostorů a průhlednosti. Resolver Module popisuje, jak se tokeny skládají pro různé situace, například pro světlý a tmavý režim nebo více značek.

Na první pohled je to další JSON. Pro větší týmy je ale podstatné, že společný zápis umožní tokeny lépe kontrolovat, verzovat a převádět do cílových prostředí. Tím se hlavní problém přesouvá. Už nejde jen o otázku, jak hodnoty zapsat. Důležitější je, kdo za ně odpovídá a jak se pozná, že změna nic nerozbila.

Token není jen hodnota

Specifikace nepracuje s tokenem jako s prostým párem název a hodnota. Token může mít $value, $type, $description, $extensions nebo $deprecated. Každá z těchto položek pomáhá udržet význam tokenu čitelný i mimo nástroj, ve kterém vznikl. $type určí, jestli jde o barvu, rozměr, stín nebo písmo. $description doplní kontext pro člověka. $deprecated dá jasně najevo, že token má náhradu a nemá se dál používat. $extensions pak nechává prostor pro údaje konkrétního nástroje, aniž by narušily společný zápis.

Důležité je i to, že typ se nemá jen odhadovat z hodnoty. U malé webové aplikace to možná projde. U systému, který generuje výstupy pro CSS, JavaScript, iOS, Android nebo dokumentaci, už je to riziko. Co jedna platforma snese jako volnější zápis, může jiná rozbít při převodu.

Specifikace také zpřesňuje pravidla pro názvy. Některé znaky v názvech tokenů a skupin nejsou povolené, upozorňuje se i na kolize názvů lišících se jen velikostí písmen. V JSONu může takový rozdíl vypadat nevinně. Při převodu do jazyků, souborů nebo balíčků z něj ale snadno vznikne chyba.

Největší přínos je tam, kde už je nepořádek

Design tokeny se nejvíc vyplatí tam, kde tým opravdu řeší roztříštěnost. Více platforem. Více značek. Tmavý režim. Několik repozitářů. Časté změny vizuálního jazyka. V takovém prostředí už nejde jen o pohodlné pojmenování barev. Jde o způsob, jak jedno rozhodnutí dostat na mnoho míst bez ručního opisování.

U malého projektu může být výsledek opačný. Pokud máte jednu aplikaci, jeden tým a pár základních stylů, zavedení celé tokenové vrstvy nemusí být první věc, kterou má smysl řešit. Tokeny samy design systém nevytvoří. Jen mu dají datový základ.

To je důležité i organizačně. Design systém není složka s tokeny. Je to soubor rozhodnutí, pravidel a odpovědností. Tokeny jsou jejich technický nosič. Pokud nikdo neví, kdo smí změnit barvu primární akce nebo odstranit starý typografický token, stabilní formát jen rychleji rozšíří stejný nepořádek.

Resolver ukáže, kde se hodnoty přepisují

Nejzajímavější část nové specifikace pro větší týmy je Resolver Module. V reálném projektu málokdy existuje jen jedna sada tokenů. Často máte základní hodnoty, k nim světlý a tmavý režim, variantu pro jinou značku, úpravy pro platformu a někdy i režim s vyšším kontrastem.

Bez jasných pravidel z toho rychle vznikne hromada souborů, kde není poznat, proč se ve výsledku použila právě jedna konkrétní hodnota. Resolver popisuje, jak se mají zdroje skládat a která hodnota má v daném kontextu vyhrát.

Tady se chyby rodí tiše. Build projde, JSON je platný, ale výsledek vypadá špatně. Tmavý režim přepíše barvu značky. Značka přebije přístupnější variantu. Mobilní sada změní typografii, kterou měla jen doplnit. Taková chyba se hledá hůř než překlep v CSS, protože vzniká až při skládání celého systému.

Resolver ale neřekne týmu, jak má vydávat balíčky, psát změnový záznam, schvalovat úpravy nebo testovat komponenty. Dává pravidla pro skládání tokenů. Pravidla pro vydávání a kontrolu změn si tým musí nastavit sám.

Zdroj pravdy není export z Figmy

Nástroje jsou důležité, ale nemá smysl čekat, že vyřeší odpovědnost. Figma může být dobré rozhraní pro designéry. Tokens Studio může pomoci s prací nad tokeny a napojením na Git. Style Dictionary umí tokeny převádět do různých výstupů; jeho dokumentace uvádí podporu DTCG formátu od verze 4, ale zároveň upozorňuje, že plná podpora nejnovějšího formátu 2025.10 se doplňuje ve verzi 5. Storybook zase není zdroj pravdy, ale místo, kde se ukáže vliv změn na reálných komponentách.

Lepší je jednodušší model: tokeny mají žít ve verzovaném zdroji, který není uzamčený v jednom návrhovém nástroji. Designéři v něm hodnoty připraví nebo zkontrolují, vývoj z nich vygeneruje výstupy a dokumentace z nich převezme význam, stav i příklady použití.

Před adopcí je proto dobré ptát se konkrétně. Umí nástroj zachovat typy a popisy? Co udělá se složenými hodnotami? Podporuje resolver, nebo jen základní formát? Umí označit zastaralý token? Zahodí při exportu něco, co tým potřebuje při buildu nebo v dokumentaci?

Dokumentace musí pocházet ze stejného zdroje

Design systém bez dokumentace se rychle rozpadne na soukromé výklady. Ručně psaná dokumentace tokenů navíc často zastará dřív než samotný kód. Pokud dokumentace říká, že token je doporučený, ale v datech je označený jako zastaralý, vývojář se podle ní přestane řídit. Pokud ukazuje jinou hodnotu než aplikace, začne obcházet i tokeny.

Lepší postup je jednoduchý: dokumentace má číst ze stejného zdroje jako build. U tokenu má být vidět název, hodnota, typ, popis, stav, případná náhrada a ukázka použití. Část textu může pořád psát člověk, ale základní údaje by se neměly opisovat ručně.

Tady stabilní specifikace pomáhá hodně. Když mají tokeny společný zápis, může s nimi pracovat build, dokumentace i kontrolní nástroje. Pořád je potřeba přemýšlet, ale aspoň se nemusí udržovat tři různé pravdy.

Stabilní formát ukáže stav týmu

Design Tokens 2025.10 pomáhá hlavně týmům, které už tokeny spravují napříč nástroji. Dává jim společný jazyk a snižuje závislost na jednotlivých nástrojích. Zároveň ale nastavuje nepříjemné zrcadlo.

Týmy, které mají jasné vlastníky, revize a vydávání, z nové specifikace vytěží víc než čistší JSON. Budou moci tokeny spravovat podobně jako jinou sdílenou technickou vrstvu. Týmy bez těchto pravidel dostanou hlavně nový formát pro starý nepořádek.

Začátek nemusí být velký. Stačí malé jádro tokenů, jasné názvy, verzovaný zdroj, kontrola v CI, změnový záznam a dokumentace ze stejného zdroje. Komponentové tokeny, složité varianty a více značek má smysl přidávat až ve chvíli, kdy je tým umí udržet.

Specifikace za tým nerozhodne, kdo smí změnit primární barvu tlačítka ani co se stane, když se token odstraní. Dává ale dost pevný jazyk na to, aby tyhle otázky už nešly schovat za export z nástroje. A to je možná její největší přínos.