Vytvoření designového systému, když jste tým tří lidí

Když jste tým tří lidí, kteří současně řeší desítky klientských projektů, nekonzistence se stává vaším nejdražším problémem. Všimli jsme si stejného vzorce opakujícího se napříč našimi zakázkami v oblasti vývoje webů v GRADAX: tlačítko stylizované jedním způsobem na domovské stránce, jiným na stránce s cenami a třetím uvnitř dashboardu. Každá odchylka nás stála čas v QA, zaváděla vizuální chyby a narušovala uhlazený pocit, který naši klienti očekávali. Něco se muselo změnit.

Rozhodnutí investovat do designového systému nebylo vedeno ambicemi ani honbou za trendy. Bylo vedeno bolestí. Trávili jsme přibližně 30 % každého nového projektu znovuvytvářením komponent, které již v nějaké formě existovaly jinde v našem kódu. Designový systém by nám umožnil kodifikovat naše rozhodnutí jednou a znovu je použít všude, čímž by se repetitivní práce proměnila v konkurenční výhodu.

Ale literatura o designových systémech je ovládána příběhy společností s dedikovanými platformními týmy o dvaceti a více inženýrech. Potřebovali jsme pragmatický přístup, který by tříčlenný tým mohl vytvořit, udržovat a skutečně používat, aniž by se vývoj funkcí zastavil. Následuje rámec, ke kterému jsme dospěli po měsících iterací.

Každý tutoriál o designových systémech vám říká, abyste začali tokeny, a to z dobrého důvodu. Designové tokeny jsou atomické hodnoty, barvy, rozestupy, typografické škály, poloměry zaoblení, ze kterých je postaveno vše ostatní. Jsou základem jakékoli soudržné značky a zajišťují vizuální konzistenci napříč všemi dotykovými body. Ty naše jsme definovali jako CSS vlastní vlastnosti v jediném souboru, mapované na sémantické názvy jako --color-primary, --color-muted-foreground a --radius-lg. To znamenalo, že jakákoli komponenta odkazující na tyto tokeny se automaticky přizpůsobí, když změníme základní hodnoty.

Klíčovým poznatkem pro malý tým je udržet sadu tokenů nekompromisně malou. Začali jsme s méně než čtyřiceti tokeny pokrývajícími barvu, rozestupy, typografii a stíny. Velké organizace mohou potřebovat stovky, ale zjistili jsme, že kompaktní sada vynucuje konzistenci místo umožnění tisíce jemných variací. Když vývojář sáhne po hodnotě rozestupu a má pouze osm možností, přirozeně zvolí tu správnou.

Také jsme brzy zavedli konvenci pojmenování, sémantickou před popisnou. Místo --blue-600 nebo --spacing-16 jsme použili --color-primary a --space-md. To oddělilo záměr od implementace a učinilo budoucí redesigny triviálními. Když klient chtěl přejít z modré na fialovou, změnili jsme šest řádků v souboru tokenů a celý systém se aktualizoval.

S tokeny na místě jsme se obrátili na komponenty. Přijali jsme shadcn/ui jako náš základ, což nám dalo krásně vytvořené, přístupné primitiva postavená na Radix UI. Místo stavění všeho od nuly jsme tato primitiva rozšířili o naši tokenovou vrstvu a varianty specifické pro projekt. Například Button zdědil přístupnost a zpracování klávesnice shadcn, přičemž používal naši tokenovou barevnou paletu a rozestupy.

Naše komponentová architektura dodržuje přísnou hierarchii. V spodní vrstvě se nacházejí UI primitiva, tlačítka, vstupní pole, odznaky, tooltipy, která nemají žádnou obchodní logiku a přijímají stylování přes props a slučování className pomocí utility cn(). Nad nimi se nacházejí složené komponenty, vyhledávací lišty, nástrojové lišty datových tabulek, statistické karty, které kombinují více primitiv do znovupoužitelných vzorů. V horní vrstvě se nacházejí sekce na úrovni stránky, které jsou specifické pro jeden pohled a jsou colocated vedle stránky, která je používá.

Tento třívrstvý model zabraňuje dvěma nejčastějším selháním design systémů: komponentám, které jsou příliš abstraktní na to, aby byly užitečné, a komponentám, které jsou příliš specifické na to, aby byly znovupoužitelné. Když vývojář potřebuje vytvořit novou funkci, sestaví ji ze střední vrstvy. Když střední vrstva nemá to, co potřebuje, složí ji z primitiv a pokud se ukáže jako znovupoužitelná, povýší ji.

Dokumentace je místo, kde většina design systémů malých týmů umírá. Tým vytvoří krásné komponenty, ale nikdy nezapíše, jak je používat, takže noví přispěvatelé (nebo původní autoři o tři měsíce později) znovu vynalézají vzory, které už existují. Vyřešili jsme to tak, že dokumentace je vedlejším produktem vývoje, ne samostatným úkolem.

Každý soubor komponenty obsahuje blok JSDoc popisující její účel, rozhraní props a příklad použití. Také udržujeme živou instanci Storybooku, kde je každá komponenta vykreslena izolovaně se svými variantami. Kritické pravidlo je, že žádný pull request není sloučen bez odpovídajícího story. Zní to přísně, ale zabere to méně než pět minut na komponentu a ušetří hodiny budoucího zmatku.

Také vedeme lehký log rozhodnutí, jednoduchý markdown soubor, který zaznamenává, proč jsme učinili konkrétní volby. Proč jsme zvolili 0,5rem jako základní radius? Proč naše primární barva používá oklch místo hex? Tyto poznámky jsou neocenitelné při revizi rozhodnutí o šest měsíců později a pomáhají zaškolit freelancery nebo kontraktory, kteří se připojí dočasně.

Funkční testy vám řeknou, zda tlačítko spustí svůj onClick handler. Testy vizuální regrese vám řeknou, zda stále vypadá správně. Pro design systém je to druhé stejně důležité jako to první. Integrovali jsme porovnávání snímků Playwright do našeho CI pipeline, takže každý pull request generuje vizuální diff ovlivněných komponent.

Nastavení bylo jednodušší, než jsme očekávali. Každé story ve Storybooku slouží zároveň jako vizuální testovací případ. Náš CI job spouští headless prohlížeč, zachycuje snímky každého story a porovnává je s commitnutými baseline. Pokud se vzhled komponenty změní, i o jediný pixel, PR je označen k revizi. To odhalilo desítky jemných regresí, které by se jinak dostaly do produkce bez povšimnutí, například změna barvy okraje, protože někdo aktualizoval token, aniž by si uvědomil dopad na další části.

Vizuální testy také spouštíme v light i dark režimu. Protože naše tokeny definují samostatné hodnoty pro každý režim, změna, která vypadá dobře v light režimu, může úplně rozbít dark režim. Automatizované snímky v obou režimech odstranily celou kategorii chyb, které se dříve dostávaly do produkce.

Po šesti měsících používání napříč desítkou klientských projektů náš design systém vyrostl ze čtyřiceti tokenů a dvanácti komponent na přibližně osmdesát tokenů a čtyřicet pět komponent. Otázkou už nebylo, zda škálovat, ale jak škálovat, aniž bychom ztratili jednoduchost, která dělala systém hodnotným na prvním místě.

Zavedli jsme kontrolní seznam pro příspěvky, který musí každá nová komponenta projít, než se připojí do knihovny: musí používat pouze existující tokeny, musí být přístupná ihned po vybalení, musí obsahovat alespoň jedno story ve Storybooku a musí fungovat v light i dark režimu. Komponenty, které nesplní jakékoli kritérium, zůstávají v kódu specifickém pro projekt, dokud nejsou zpevněny. Toto hrazení udržuje sdílenou knihovnu důvěryhodnou.

Také jsme začali systém verzovat pomocí sémantických releasů. Breaking changes tokenu nebo prop komponenty se projeví jako major verze, takže projekty připnuté ke starší verzi se neočekávaně nerozbijí. Zpočátku to bylo pro tým tří lidí přehnané, ale vyplatilo se, když jsme začali systém sdílet s freelance spolupracovníky a dedikovanými vývojovými týmy, které potřebovaly záruky stability.

Ta nejdůležitější lekce je, že design systém nemusí být obrovský, aby byl cenný. Náš systém je malý podle podnikových standardů, ale ušetří nám odhadem deset hodin na projekt díky menší duplicitě, méně vizuálním chybám a rychlejšímu zařazení do týmu. Pro tříčlenný tým účtující za projekt se tyto hodiny přímo promítají do ziskovosti.

Druhá lekce je optimalizovat pro přijetí, ne pro úplnost. Design systém, který váš tým nepoužívá, je horší než žádný design systém, protože vytváří iluzi konzistence, zatímco kódová základna se pod tím rozchází. Každé rozhodnutí, které jsme učinili, od volby shadcn/ui jako základu po povinné story ve Storybooku, směřovalo k tomu, aby byl systém cestou nejmenšího odporu, nikoliv další zátěží.

Nakonec berte svůj design systém jako produkt s vlastní roadmapou, i když jedinými uživateli je váš vlastní tým. Upřednostněte komponenty a tokeny, které odstraní nejvíce duplicity. Sledujte, které komponenty se používají nejčastěji, a investujte do jejich kvality. Design systém není nikdy hotový, ale se správnými prioritami dokáže i malý tým udržet takový, který předčí mnohem větší systémy. Pokud zvažujete vytvoření design systému pro svůj produkt a chcete poradit, kde začít, kontaktujte náš tým, procesem jsme si prošli a pomůžeme vám vyhnout se nejčastějším pastem.