Mnoho aplikací, jedno UI: první kroky ke sjednocení UX

Úvod

Hodně firem provozuje několik aplikací a každá má vlastní frontend. Nedávno jsem tenhle problém řešil na vlastní kůži. Příznaky byly vidět na první pohled: každá aplikace vypadala a chovala se jinak.

Někdy jde o drobnosti: jiný odstín firemní barvy, jinak zaoblené tlačítko. Často ale ne. Jedna aplikace má navigaci v horní liště, další v postranním panelu. Jeden formulář validuje už při psaní, jiný až po odeslání. Stejná datová tabulka řadí, filtruje a stránkuje pokaždé jinak. Kdo přepíná mezi dvěma takovými aplikacemi, může mít pocit, že přešel do jiné firmy.

Cíl zní jednoduše: jeden konzistentní design ve všech aplikacích. Ambicióznější varianta jde ještě dál a spojí je všechny do jediné aplikace s jednotným UX.

Takový projekt se rád odkládá. Týká se všech týmů, hned na začátku nepřinese žádnou novou funkci a těžko se odhaduje. AI nástroje pomůžou s opakovanou implementační prací, ale rozhodnutí o designu a architektuře za vás neudělají.

Když se to povede, získáte:

• vizuální konzistenci napříč produkty
• UI a UX vzory, které se navrhnou jednou a nevymýšlí je znovu každý tým
• snazší spolupráci mezi designem, vývojem a produktem
• společné standardy přístupnosti, podle kterých se řídí všechny týmy
• změny UI, které se udělají na jednom místě a projeví se všude

Rozsah článku

Článek se věnuje jen jedné části: vizuální vrstvě. Tedy barvám, typografii, rozestupům a CSS, které je do aplikací propisuje. Když máte vedle sebe Angular, Vue a React, je to nejpraktičtější místo, kde začít. Společné design tokeny se do každé aplikace dostanou přes její vlastní stylování, i když jejich zavedení v každém projektu nějakou práci dá.

Sdílené knihovny komponent, struktura projektů a micro-frontendy přijdou na řadu později a zaslouží si vlastní články. Nečekejte ani hotový recept. Jde o možné první kroky a to, jak daleko se s nimi dostanete, záleží na tom, s jakými projekty začínáte.

Výchozí stav

Detaily se u vás budou lišit, ale obvykle to vypadá podobně:

• žádný sdílený tech stack: na frontendu najdete Angular, Vue, React s Vite a React s Next.js, často v různých verzích
• žádná sdílená knihovna komponent, takže si každý projekt staví vlastní tlačítka, formuláře a tabulky
• design je ve Figmě, každý projekt má vlastní soubor a ten je zdrojem pravdy

Diagram ukazuje, z jakých vrstev se taková architektura obvykle skládá a kdo má kterou na starosti.

Designový tým navrhuje UI každého projektu zvlášť a spravuje ho ve Figmě. Produktové týmy nad ním stavějí funkce, každý s vlastní implementací UI, a s každým upřesněním se musí vracet za designéry. Jeden design na projekt, jedna implementace na tým a nic společného.

A to se prodraží. Každá oprava se dělá šestkrát a každý nový vzor se šestkrát vymýšlí.

Ne každý projekt začíná na stejném místě

Projekty se složitostí hodně liší a právě ta rozhoduje, jak rychle v nich jde novou vizuální vrstvu zavést:

• nízká: jeden soubor s tématem a pár obrazovek, nové tokeny jdou nasadit skoro hned
• střední: styly rozházené po komponentách, ale s rozumnou strukturou, na které se dá stavět
• vysoká: legacy kód, několik smíchaných přístupů ke stylování a žádné téma

Jednodušší projekty se hodí na pilot. Ty složité obvykle potřebují nejdřív pořádně uklidit, než se do nich dá redesign nasadit.

Krok 1: společný design systém

Začněte s designovým týmem a společným design systémem ve Figmě. Na tomhle základu budou stavět všechny ostatní týmy a podle něj se bude kontrolovat každý další krok.

Než začnete navrhovat cokoli nového, najděte vzory, které už mají všechny aplikace společné. U vizuální vrstvy jde hlavně o základní stavební prvky, ze kterých se stanou design tokeny:

• typografie: rodiny písma, velikosti, řezy, výšky řádků
• barvy: firemní, neutrální a sémantické stavy jako úspěch nebo chyba
• škála rozestupů
• zaoblení rohů a šířky okrajů
• stíny a elevace
• breakpointy
• pohyb: délky a průběhy animací

Pak si zmapujte hlavní komponenty, i když je zatím sdílet nebudete:

• hlavičky a patičky
• navigaci, horní lišty i postranní panely
• tlačítka a odkazy
• formulářová pole a validační hlášky
• datové tabulky s řazením, filtrováním a stránkováním
• modální okna, toasty a další zpětnou vazbu
• prázdné stavy, načítání a chybové stavy

Krok 2: redesign s AI

AI umí hledání variant hodně zrychlit, ale architektonická rozhodnutí pořád chtějí pečlivost. Vygenerované návrhy berte jako koncepty a ověřte je proti design systému, současnému produktu a omezením v kódu.

Jakmile máte design systém ve Figmě hotový, zkuste hledat varianty s pomocí AI. Nástroje jako Claude Design podporují rychlé iterace:

• přeneste skutečné obrazovky z Figmy do Claude Design jako vizuální předlohu
• navrhněte je znovu pomocí design systému
• výsledek předejte AI agentům, kteří píšou kód

Čas strávený prvními experimenty se vyplatí. Díky propojení Claude Design a Claude Code se rychle dostanete do kódu a uvidíte, co by změna ve vašem projektu doopravdy udělala.

Ukázkový prompt pro redesign

Počítejte s tím, že první pokusy budete muset hodně ručně usměrňovat. Umí to být frustrující. Typické problémy:

• ztracený kontext v půlce session
• designové vzory, které neodpovídají design systému
• nechtěné změny layoutu
• vymyšlené prvky, o které nikdo nežádal

Každá taková oprava má ale svou hodnotu: ukazuje, co musí obsahovat další verze instrukcí.

Udělejte z toho sdílený skill

Jakmile postup funguje, nenechávejte ho ležet v historii chatu. Udělejte z něj skill: balíček instrukcí, který si agent načte pokaždé, když na takový úkol narazí. Stejná pravidla pak dostanou vaši kolegové i všechny ostatní týmy ve firmě.

Krok 3: přeneste redesign do kódu

Kdo to zažil, ví, jak těžké je dostat nový design do skutečného, existujícího kódu. Málokdy to jde podle plánu. Pořád se objevuje něco nečekaného, a o to víc, když chcete sjednotit několik aplikací najednou.

Držte se jen vrstvy CSS. Než sáhnete do kódu, ověřte, že máte:

• dohodnuté rozhraní mezi Figmou a kódem, obvykle design tokeny, které jsou na obou stranách stejné
• v každém projektu téma, které přebírá hodnoty ze společných tokenů
• dobře strukturovaný frontendový kód
• čitelnou architekturu komponent
• čisté stylování s dobrými konvencemi pojmenování

Každý nedostatek z tohoto seznamu se vám vrátí v každé předělané obrazovce, takže ho vyřešte jako první. U složitého projektu může takový úklid zabrat většinu práce.

Naplánujte první experimenty

Začněte v malém a rozsah rozšiřujte krok za krokem:

1. předělejte stávající téma
2. předělejte společné komponenty
3. předělejte konkrétní stránky
4. předělejte komponenty a layouty, které existují jen na těchto stránkách

Ze zkušenosti: na tenhle krok se obvykle hodí víc Claude Code než Claude Design. Pracuje přímo ve vašem kódu, takže vidí skutečná omezení.

Nejtěžší jsou první změny. Jakmile splní požadavky, další jdou rychleji a celý proces se skoro zautomatizuje. Aby obě strany zůstaly v souladu, spusťte v Claude Code /design-sync. Přenese váš design systém do Claude Design, takže redesign vychází z vašich skutečných komponent, a hotovou práci umí poslat zpátky na plátno Claude Design.

Krok 4: revize a synchronizace

V tuto chvíli máte:

• existující obrazovky z Figmy převedené na koncepty redesignu v Claude Design
• koncepty předané do Claude Code
• změny v kódu, které splňují požadavky redesignu

Pak přijde na řadu revize a tady to začíná drhnout. Největší slabinou je chybějící synchronizace mezi vývojáři, designéry a Figmou.

Redesign je teď v Claude Design, ale zdrojem pravdy zůstává Figma. Claude Design podle dokumentace neumí exportovat nativní soubor Figma Design. MCP server od Figmy sice umí zapisovat na plátno, ale přístup k němu závisí na tarifu a typu licence. Zbývá tedy praktická otázka: jak budou designéři změny ve Figmě kontrolovat a schvalovat?

Když se schválený design do Figmy nevrátí, přestane soubor odpovídat tomu, co je v produktu skutečně nasazené.

Co bych udělal jinak

Zpětně bych zvolil kratší postup implementace:

1. vynechal bych krok s Claude Design
2. začal bych ve Figmě a ponechal ji jako jediný zdroj pravdy
3. vytvořil bych deterministické předání z Figmy do Claude Code
4. změny v kódu bych implementoval s Claude Code

Deterministické znamená, že ze stejného souboru ve Figmě vzniknou vždycky stejné tokeny. Například proměnné z Figmy se při buildu exportují a převedou na CSS custom properties, místo aby záleželo na tom, jak je agent zrovna pochopí. Design se pak schvaluje tam, kde vzniká, a kód se vždycky řídí Figmou.

Shrnutí

Bez pečlivého plánování to nepůjde, a to ani u experimentů. Každý tým musí vycházet ze své architektury a ze složitosti svých projektů.

Tentokrát šlo o vizuální vrstvu. Dalším vrstvám se budu věnovat v příštích článcích:

• struktura projektů
• integrace micro-frontendů, kde dávají smysl
• sdílené knihovny komponent

Když se to všechno poskládá dohromady, může UI část firmy získat nové vrstvy a novou strukturu:

Designový tým spravuje Figmu a určuje vizuální vrstvu. Týmy UI frameworků z ní dělají sdílené knihovny komponent, pro každý framework jednu, se stabilním API. Produktové týmy nad těmito knihovnami stavějí své aplikace, případně jako micro-frontendy, a nové požadavky na produktový design posílají zpátky designérům. Vizuální změny tak putují od designu k implementaci, nové potřeby zase opačným směrem a každá vrstva má jasného vlastníka.