Spotify má přes 2 500 komponent ve svém design systému Encore. Shopify spravuje Polaris, IBM používá Carbon, a Atlassian provozuje vlastní systém od roku 2013. Tyto firmy neinvestovaly do design systémů z módy. Investovaly proto, že bez nich nedokázaly škálovat produktový vývoj, aniž by se jim rozsypala vizuální konzistence.
Co je design systém a co není
Design systém je soubor pravidel, vizuálních tokenů a opakovaně použitelných komponent, které určují, jak digitální produkt vypadá a chová se. Tokeny (design tokens) definují barvy, typografii, rozestupy a stíny na jednom místě. Komponenty jsou hotové stavební bloky: tlačítka, formulářové prvky, karty, navigace, modální okna.
Častý omyl: zaměňovat design systém s UI kitem ve Figmě. UI kit obsahuje vizuální komponenty, ale chybí mu dokumentace, pravidla použití, principy rozhodování a propojení s kódem. Brad Frost, autor metodologie Atomic Design, to popsal přesně: design systém je „soubor propojených vzorů a sdílených praktik, koherentně organizovaných, aby sloužily účelům digitálního produktu". UI kit je jen vizuální vrstva.
Proč firmy bez systému ztrácejí čas
Když dva vývojáři v jednom týmu implementují tlačítko s jiným zaoblením rohů, stojí to dvojnásobek času. Když deset vývojářů ve třech týmech řeší totéž, násobí se to. Nathan Curtis, zakladatel EightShapes a konzultant pro design systémy, odhaduje, že firmy bez systému stráví až 40 % vývojového času přetvářením existujících komponent místo stavby nových funkcí.
Problém ale není jen čas. Zákazník, který otevře webovou aplikaci a mobilní verzi téhož produktu, očekává jednotný vizuální jazyk. Pokud se barva primárního tlačítka liší o dva odstíny, hlavička má jiný font a mezery mezi prvky nesedí, značka ztrácí důvěryhodnost. Týmy v Airbnb tento problém řešily v roce 2016, kdy spustily svůj design systém DLS (Design Language System). Karri Saarinen, tehdejší vedoucí designu v Airbnb, popsal důvod jednoduše: před zavedením systému měla každá platforma vlastní vizuální interpretaci téhož produktu.
Z čeho se design systém skládá
Každý systém má vlastní rozsah, ale čtyři vrstvy se opakují u většiny z nich:
Principy. Písemně formulovaná pravidla, která pomáhají týmu rozhodovat v nejasných situacích. Material Design od Googlu má jako princip „bold, graphic, intentional". Principy nejsou dekorace; slouží jako filtr pro rozhodování o nových komponentách.
Tokeny. Pojmenované hodnoty pro barvy, typografii, rozestupy, zaoblení, stíny a breakpointy. Tokeny jsou abstrakce: místo `#1A3A2E` používáte `color-surface-primary`. Když se barva změní, opravíte jednu hodnotu a projeví se to napříč celým produktem.
Komponenty. Od atomických prvků (tlačítko, input, badge) přes molekuly (vyhledávací pole = input + ikona + tlačítko) po organismy (hlavička stránky). Každá komponenta má definované varianty, stavy (hover, focus, disabled, loading) a pravidla pro responsive chování. Figma v roce 2025 představila native slots: prázdný prostor uvnitř komponenty, kam tým může vkládat vlastní vrstvy bez nutnosti detachmentu. Komponenty se tak chovají jako modulární „base" bloky, které pojmou specifické úpravy, aniž by ztratily vazbu na zdrojovou knihovnu.
Dokumentace. Popis, kdy a jak každou komponentu použít, co dělat a co ne. Bez dokumentace se systém stává sbírkou prvků, kterou každý používá po svém.
Figma a W3C Design Tokens v 2026
V říjnu 2025 vydala W3C Design Tokens Community Group stabilní verzi specifikace pro sdílení tokenů mezi nástroji a platformami. Figma na to reagovala nativní podporou importu a exportu tokenů alignovaného s touto specifikací. Podle Adama Sedwicka ze Zeroheight plánuje Figma plný nativní W3C support do listopadu 2026.
Pro produkční design systémy se osvědčil třívrstvý model tokenů: primitives (surové hodnoty jako `#1A3A2E`), semantic (kontextové názvy jako `color-surface-primary`) a component (specifické pro UI prvky jako `button-bg`). Aliasování probíhá řetězově: `$system-color-red-400` → `$system-color-error-foreground` → `$system-message-text-error`. Třívrstvý model umožňuje změnit brand paletu na jednom místě, aniž by se rozsypaly stovky komponent.
Figma v roce 2025 rozšířila počet dostupných modes pro variables na 10 (Professional) a 20 (Organization plan). Spolu s extended collections, které dovolují poskytnout unikátní variable sety pro každý brand při zachování stejných modes a názvů, to otevírá cestu k multi-brand systémům v jednom Figma souboru.
Jak design systém vzniká krok za krokem
1. Audit stávajícího stavu
Prvním krokem je inventura. Designér projde všechny existující obrazovky, screenshoty, Figma soubory a produkční kód. Výsledkem je seznam všech variant každého prvku: kolik verzí tlačítek existuje, kolik barevných odstínů tým používá, kolik typografických stylů se vyskytuje v produkci. Jeri Doris z designového týmu Googlu označuje tento krok za nejčastěji podceněný, protože odhalí duplicity, o kterých tým neví.
2. Definice tokenů
Na základě auditu designér vybere kanonické hodnoty. Místo čtrnácti odstínů šedé zůstanou čtyři. Místo osmi velikostí fontu šest. Tokeny se organizují do tří vrstev: primitivní (surové hodnoty), sémantické (pojmenované podle funkce: `text-primary`, `surface-muted`) a komponentové (vázané na konkrétní prvek: `button-bg`, `card-border`).
3. Stavba komponent
Designér staví komponenty ve Figmě s využitím auto-layoutu, variant a properties. Každá komponenta zároveň vzniká v kódu, nejčastěji jako React, Vue nebo Web Components. Propojení mezi Figmou a kódem je bod, kde mnoho systémů selhává: pokud Figma komponenta neodpovídá kódové implementaci, tým se vrátí k ad hoc řešením.
4. Dokumentace a onboarding
Dokumentace zahrnuje příklady použití, do's and don'ts, přístupnost (accessibility guidelines) a návody pro vývojáře. Týmy jako Gitlab publikují svůj systém Pajamas jako veřejný web, kde si každý člen organizace najde aktuální specifikaci. Bez aktivního onboardingu nových členů týmu systém adoptuje jen jeho tvůrce.
5. Iterace a governance
Design systém není jednorázový projekt. Vyžaduje správce (jednoho člověka nebo malý tým), proces pro přidávání nových komponent, deprecation workflow pro zastarávající prvky a pravidelné revize. Supernova, nástroj pro správu design systémů, ve svém průzkumu z roku 2024 uvádí, že 67 % firem s funkčním systémem má dedikovaného správce.
Figma v roce 2025 přidala funkci Check Designs, automatický audit, který kontroluje, zda hodnoty v designu používají systémové variables. Designér spustí kontrolu a okamžitě vidí, kde tým obešel tokeny a natvrdo zapsal barvu nebo rozestup. Druhým nástrojem pro governance je living documentation: místo ručně psané wiki se dokumentace generuje přímo z komponent (přes Zeroheight, Storybook nebo MDX). Když se komponenta změní, dokumentace se aktualizuje automaticky. Adam Sedwick ze Zeroheight doporučuje doplnit governance o pravidelné průzkumy spokojenosti konzumujících týmů, protože design systém, který neřeší reálné potřeby uživatelů, ztrácí adopci.
Rozhodnutí, která ovlivní výsledek
Scope: celý ekosystém, nebo jeden produkt? Menší firmy obvykle začínají systémem pro jeden produkt a rozšiřují ho postupně. Budovat systém pro pět produktů najednou bez předchozí zkušenosti vede k analýze paralýze a pomalému dodávání.
Technologie tokenů. Formát W3C Design Tokens dosáhl v říjnu 2025 stabilní specifikace. Nástroje jako Style Dictionary od Amazonu nebo Tokens Studio pro Figmu umožňují generovat tokeny do CSS, iOS, Androidu i dalších platforem z jednoho zdroje. Figma přidala nativní import a export tokenů alignovaný s W3C spec, takže většina týmů už nepotřebuje externí plugin jako bridge.
Kdo systém vlastní? Tři modely fungují v praxi: centralizovaný tým (dedikovaný systémový tým, ostatní jsou konzumenti), federativní model (každý produktový tým přispívá, systémový tým koordinuje) a hybrid. Ben Callahan z Sparkbox doporučuje federativní model pro většinu středně velkých organizací, protože zvyšuje adopci.
Figma, nebo kód? Oboje. Systém, který existuje jen ve Figmě, nepomůže vývojářům. Systém, který existuje jen v kódu, nepomůže designérům. Úspěšné systémy jako Primer od GitHubu udržují obě vrstvy v synchronizaci.
Propojení designu s kódem. Figma v roce 2025 uvedla Code Connect UI, které propojuje Figma komponenty přímo s GitHub repozitářem. Vývojář si v inspektoru místo generického CSS zobrazí skutečný kód komponenty z produkčního codebase. K tomu přibyla Figma Make, funkce generující React kód a CSS přímo z designů. Propojení snižuje třecí plochy při handoffu: designér upraví komponentu ve Figmě a vývojář vidí odpovídající kódový snippet bez manuálního překladu.
Na co si dát pozor
Největší riziko není technické, ale organizační. Systém, který nikdo nepoužívá, je zbytečný. Adopce závisí na třech faktorech: systém musí řešit reálné problémy týmu (ne teoretické), musí být snadnější ho použít než obejít a musí mít viditelnou podporu vedení.
Druhé riziko je perfekcionismus. Designéři mají tendenci budovat „dokonalý" systém před prvním nasazením. Lepší strategie je dodat prvních 10 až 15 komponent, nasadit je do produkce a iterovat na základě zpětné vazby. Dan Mall, spoluzakladatel designového studia SuperFriendly a autor knihy Design That Scales, razí přístup „hot potato": designér a vývojář pracují na komponentě paralelně a předávají si ji v krátkých cyklech, místo aby designér předal „hotový" návrh a vývojář ho implementoval v izolaci.
Třetí riziko je zanedbaná přístupnost. Každá komponenta v systému by měla splňovat WCAG 2.2 na úrovni AA od začátku. Opravovat kontrastní poměry a klávesovou navigaci ve stovce komponent zpětně je řádově dražší než to udělat správně napoprvé.
Kdy se design systém vyplatí
Ne vždy. Pro jednorázový marketingový web s pěti stránkami a jedním vývojářem je design systém zbytečný overhead. Investice se začíná vracet ve chvíli, kdy produkt roste: přibývají obrazovky, přibývají členové týmu, přibývají platformy.
Podle průzkumu, který v roce 2023 provedl tým Figmy mezi 500 produktovými týmy, firmy s fungujícím design systémem dodávaly nové funkce o 34 % rychleji než firmy bez něj. Největší úsporu hlásily týmy s 10 a více členy.
Orientační vodítko: pokud váš tým stráví víc než dvě hodiny týdně řešením vizuálních nekonzistencí nebo přetvářením existujících komponent, investice do systému se pravděpodobně vrátí do šesti měsíců.
Jak začít
Nepotřebujete hned tisícistránkovou dokumentaci. Začněte auditem: projděte produkční web nebo aplikaci, udělejte screenshoty každé unikátní varianty tlačítek, polí, barev a typografických stylů. Sestavte inventuru do tabulky. Identifikujte, kde máte největší duplicity.
Pak definujte tokeny pro barvy, typografii a rozestupy. Pojmenujte je sémanticky. Vytvořte prvních 10 komponent, které se ve vašem produktu vyskytují nejčastěji. Nasaďte je. A od té chvíle budujte systém přírůstkově, podle toho, co tým potřebuje.
