Design systém: proč každé tlačítko ve firmě nemusí vznikat znovu
V jedné aplikaci se objednávka ukládá modrým tlačítkem, v druhé zeleným a v třetí ikonou bez popisku. Vývojáři opakují podobnou práci a uživatelé se učí nové chování. Design systém sjednocuje podobu i pravidla prvků, které týmy skutečně používají.
Firma provozuje zákaznický portál, interní správu objednávek a web. Každý projekt vytvořil formuláře po svém. Změna značky pak vyžaduje ruční zásahy na třech místech, ale ještě obtížnější je sjednotit chybové hlášení nebo ovládání klávesnicí.
Design systém je dohoda převedená do použitelných podkladů: vizuální pravidla, opakovaně použitelné komponenty, jejich chování a dokumentace. Hodnotu získá teprve tím, že jej lidé používají a někdo se stará o změny. Samotný soubor s obrázky tlačítek tento úkol nesplní.
01Design systém, UI kit a pravidla značky mají různé role
Pravidla značky popisují například logo, barvy, typografii a tón komunikace. UI kit nabízí prvky pro návrh rozhraní. Design systém navíc řeší, jak se prvky používají, chovají a udržují, ideálně také prostřednictvím společné knihovny v kódu. Tyto části se doplňují.
| Součást | Co obsahuje | Co sama neřeší |
|---|---|---|
| Pravidla značky | Logo, barevnost, typografii a způsob komunikace. | Chování formuláře, ovládání klávesnicí a provozní změny komponent. |
| Knihovna pro návrháře | Varianty a stavy prvků pro návrh obrazovek. | Zda nasazený kód odpovídá návrhu a správně funguje. |
| Knihovna komponent v kódu | Použitelné prvky s definovaným rozhraním a chováním. | Správnost obsahu a celého pracovního postupu v konkrétní aplikaci. |
| Dokumentace a správa | Pravidla použití, příklady, verze, vlastníky a přijímání změn. | Přínos bez skutečného používání a ověřování s uživateli. |
GOV.UK Design System odděluje styly, komponenty a vzory pracovních postupů. Je užitečným příkladem toho, že systém nezůstává u barev: obsahuje například opakované řešení formulářů, navigace a zadávání údajů. Je navržen pro britské veřejné služby, takže jeho konkrétní podobu nepřebírejte bez posouzení potřeb firmy.
Rozdíl mezi vzhledem a používáním rozhraní doplňuje vysvětlení UI a UX. Stejně vypadající obrazovky mohou mít stále nejasné kroky a nesrozumitelné texty.
02Přínos hledejte v opakované práci a chybách
Design systém dává větší smysl tam, kde více lidí navrhuje a vyvíjí podobná rozhraní, produkty mají delší život nebo se často mění. Společná komponenta může odstranit opakování stejné práce. Zároveň umožní opravit chování na jednom místě a řízeně dostat opravu do používaných aplikací.
U malého jednorázového webu může stačit krátká sada pravidel a několik základních komponent. Rozsáhlá knihovna připravovaná před první potřebnou stránkou může stát víc práce, než zatím vrací. Vyberte rozsah podle opakování a plánovaného rozvoje.
- Týmy vytvářejí několik podobných formulářových polí a jejich chyby opravují odděleně.
- Vzhled návrhu se liší od nasazené aplikace a není jasné, která verze platí.
- Základní změna barvy nebo rozestupu vyžaduje mnoho nesouvisejících zásahů.
- Uživatelé potkávají podobnou akci pod různými názvy a s jiným chováním.
- Noví kolegové nevědí, co už existuje, a znovu navrhují stejný prvek.
Neodhadujte přínos univerzálním procentem. Změřte vlastní opakované úkony: návrh nového formuláře, úpravu chybového stavu nebo opravu napříč produkty. Započtěte také vytvoření knihovny, migraci a její správu.
03Začněte auditem jedné skutečné pracovní cesty
Vyberte častý postup, například založení objednávky nebo změnu zákaznických údajů. Posbírejte obrazovky a používané prvky z návrhů i živého produktu. U každé varianty zapište důvod odlišnosti. Některé rozdíly jsou potřebné; jiné vznikly jen tím, že různí lidé nevěděli o společném řešení.
Neporovnávejte jen běžný stav. Zachyťte prázdnou hodnotu, načítání, chybu, úspěch, nedostupnou akci a pohyb klávesnicí. U tabulky dlouhé názvy, prázdný seznam a více stránek. U formuláře chybné zadání i návrat k opravě.
Pro českou aplikaci zkoušejte diakritiku, delší popisky, částky v Kč, datum a potřebné firemní údaje. Pole pro adresu může potřebovat ruční zadání, i když má našeptávač. Příliš úzká komponenta s anglickým ukázkovým textem problémy nezachytí.
Z auditu vyberte malou sadu s opakovaným použitím. První verze může pokrýt tlačítko, textové pole, výběr, chybovou zprávu a jednoduché rozložení formuláře. Je to doporučený začátek, nikoli povinný seznam pro každou aplikaci. Každý prvek ověřte v reálném postupu.
04Propojte význam hodnot s návrhem a kódem
Sdílené hodnoty pro barvy, písmo a rozestupy se označují jako design tokeny. Název má ideálně vyjadřovat použití, například barvu chybové zprávy nebo hlavní akce. Týmy pak nemění desítky samostatných hodnot a méně zaměňují vzhled za význam.
Specifikace formátu Design Tokens Community Group popisuje strojově čitelný zápis tokenů a jejich typů. Může pomoci s výměnou hodnot mezi nástroji. Sama však nesynchronizuje vaši knihovnu a nezajišťuje správné použití: potřebujete vlastní postup přenosu a kontrolu výsledku.
Určete, kde jsou rozhodující hodnoty a jak se dostanou do návrhů i aplikace. Změnu ověřte na potřebných stavech, motivech a zařízeních. Nová barevnost může zhoršit čitelnost textu, i když působí lépe na samotném prezentačním obrázku.
Komponenta v návrhu a komponenta v kódu mají sdílet názvy a varianty. Vývojář musí vědět, zda zvolená varianta opravdu existuje, a návrhář musí znát její omezení. Zbytečné ruční přepisování těchto informací může postupně vytvořit dvě různé knihovny.
05Přístupnost ověřujte u prvku i celé obrazovky
W3C shrnuje požadavky WCAG například na ovládání klávesnicí, viditelné zaměření, popisky, chyby a kontrast. Převádějte relevantní požadavky do návrhu a testů komponent. Pouhá kontrola barev nepokryje ovládání, smysluplné pořadí ani oznámení změny stavu.
Tlačítko není jen obdélník s textem. Potřebuje správnou roli, dostupný název a předvídatelné chování. WAI ukazuje pravidla pro tlačítka a jejich ovládání. U vlastního vzhledu proto zachovejte potřebnou funkci a nezkoušejte každou interakci vymýšlet znovu.
U formuláře musí člověk poznat, co má vyplnit a jak chybu napravit. Textové vysvětlení nemá nahrazovat pouze červený okraj. Během odesílání ukažte stav a zabraňte nežádoucímu opakování, ale zachovejte srozumitelnou cestu při chybě.
Společná přístupná komponenta pomáhá, přesto neslibuje přístupnost celého produktu. Špatný obsah, pořadí, vložení do jiné komponenty nebo nevhodné použití mohou vytvořit problém. GOV.UK popisuje přístupnost design systému jako průběžnou práci, nikoli jednorázovou vlastnost grafických podkladů.
K automatickým kontrolám přidejte ruční ovládání klávesnicí, potřebné asistivní technologie a testy se skutečnými uživateli. Technický standard také nezaměňujte s automatickým právním potvrzením všech povinností vašeho webu.
06Dokumentace má říct, kdy prvek použít a kdy ne
U každé komponenty napište účel, varianty, stavy, potřebné texty a příklady použití. Přidejte omezení a nevhodné situace. Nový kolega potřebuje rozhodnout, zda použít existující řešení, nebo navrhnout změnu. Dlouhý seznam vlastností bez příkladů mu nemusí pomoci.
Tlačítko „Uložit“ má mít popsaný význam i vztah k dalším akcím. Formulářový vzor má říct, jak se chovají povinná pole, validace a potvrzení výsledku. Podobné rozhodnutí se pak nepřesouvá na každého vývojáře jednotlivě.
Kritéria GOV.UK pro přijetí nové komponenty pracují s užitečností, odlišením od existujících prvků a ověřením použitelnosti. Pro firemní knihovnu z toho lze odvodit jednoduchou otázku: je potřeba opakovaná a máme doklad, že současné řešení nestačí? Jednorázovou zvláštnost nemusíte okamžitě přidávat do společného základu.
Výjimky dovolte, ale evidujte jejich důvod a vlastníka. Pokud aplikace potřebuje jiné chování kvůli konkrétnímu úkolu, zdůvodněná varianta může být správně. Tiché kopírování komponenty do jiné složky zhoršuje budoucí opravy.
Texty pište pro skutečného uživatele, ne pro knihovnu. „Chyba validace“ může být název stavu pro vývojáře, ale člověk potřebuje vědět, který údaj má opravit a co se s jeho zadáním stalo.
07Správa změn rozhodne, zda se knihovna používá
Určete vlastníka, způsob návrhu změny a odpovědnost za schválení. Návrhář a vývojář musejí spolupracovat; produktový tým doplní skutečnou potřebu a uživatelé její ověření. Není nutné zavést rozsáhlou komisi, ale potřebujete jasnou odpověď na otázku, kdo rozhodne při rozdílu.
Vydávejte dohledatelné verze a pište, co se změnilo. U změny chování nebo rozhraní komponenty přidejte migrační postup. Oprava v knihovně neznamená, že ji všechny aplikace už převzaly. Evidujte používané verze a způsob aktualizace.
- Ověřte novou variantu v návrhu i kódu a na potřebných stavech.
- Zaznamenejte změnu, její důvod a případný dopad na používané produkty.
- U zastaralého prvku uveďte náhradu a postup přechodu.
- Kontrolujte, zda týmy nevytvářejí další podobné kopie kvůli nejasné dokumentaci.
- Vlastníka i přístupy ke knihovně zahrňte do předání projektu.
Nasazujte postupně v jedné skutečné cestě. Migrovat všechna historická rozhraní před ověřením první verze může být drahé a zbytečné. Zároveň plánujte, jak se zbývající produkty přiblíží společným pravidlům, aby se pilot nestal třetí souběžnou knihovnou.
08Časté otázky k design systémům
Stačí knihovna ve Figmě?
Pomůže s návrhy, ale sama nezajistí odpovídající kód ani fungující chování. Propojte názvy, varianty, stavy a dokumentaci s implementací. Podstatný je používaný postup, nikoli jeden konkrétní nástroj.
Potřebuje design systém i malá firma?
Rozsah volte podle opakování a rozvoje. U menšího webu může stačit krátká sada pravidel a základní prvky. Více produktů nebo týmů obvykle zvyšuje potřebu společné knihovny a správy.
Zajistí design systém přístupnost aplikace?
Ověřené komponenty pomáhají, ale celý produkt potřebuje kontrolu obsahu, pořadí a konkrétního použití. Automatické testy doplňte ručními a uživatelskými kontrolami.
Zabrání jednotná knihovna odlišení produktů?
Může sdílet význam a chování základních prvků a přitom podporovat odůvodněné varianty. Rozdíly evidujte podle skutečné potřeby, aby nevznikaly nahodilé kopie.
Kdo má knihovnu spravovat?
Určete vlastníka a společný postup návrháře, vývojáře a produktu. Každá změna potřebuje ověření, dokumentaci a cestu do používaných aplikací. Rozsáhlost řízení přizpůsobte týmu.
Musíme před startem vytvořit všechny komponenty?
Začněte opakovanými prvky jedné pracovní cesty a ověřte je. Další přidávejte podle potřeby. Velká knihovna bez uživatelů může spotřebovat čas dřív, než ukáže přínos.
Jak měřit návratnost design systému?
Porovnejte čas potřebný na opakované úkony, počet kopií a náklady změn či oprav. Započtěte tvorbu, migraci a správu. Neslibujte univerzální procentní úsporu bez vlastního měření.