20 pravidel UX, která dodržet při návrhu prototypu

01Určete rozhodnutí, které má prototyp podpořit

Před kreslením napište jednu otázku: Zvládne zákazník změnit termín rezervace bez telefonu na podporu? Takové zadání vám pomůže rozhodnout, které obrazovky potřebujete. Výsledek testu musí vést k dalšímu kroku, například upravit výběr termínu nebo pokračovat do vývoje. Obecné „ověřit design“ bývá příliš neurčité, protože neurčuje, jaké chování chcete pozorovat.

02Popište celý hlavní úkol

Zaznamenejte, odkud člověk přichází, co už ví a podle čeho pozná dokončení. U změny rezervace cesta nezačíná automaticky v přihlášeném přehledu. Může začínat odkazem z e-mailu a končit novým potvrzením. Prototyp musí obsahovat části potřebné k ověření této cesty, jinak testujete jen výřez, ve kterém se skutečný problém nemusí objevit.

03Vycházejte z konkrétní skupiny a situace

„Všichni zákazníci“ není dobrý popis pro test. Rozlišujte člověka, který službu používá poprvé, pravidelného uživatele a pracovníka s jinými oprávněními. Zapište zařízení, prostředí a překážky. Technik v rukavicích řeší jinou situaci než účetní u monitoru. Nevymýšlejte si jejich preference; nejisté předpoklady označte a ověřte rozhovorem nebo pozorováním.

04Přizpůsobte podrobnost tomu, co ověřujete

Pro srovnání dvou cest může stačit jednoduchý náčrt. Při ověřování srozumitelnosti formuláře už potřebujete skutečné texty a chybové stavy. GOV.UK v popisu fáze alpha doporučuje cílit prototypování na nejrizikovější předpoklady. Seznamte tým s tím, co je simulované. Vizuálně hotový prototyp sám nepotvrzuje technickou proveditelnost ani připravenost k provozu.

05Používejte realistický obsah

Vložte dlouhé názvy, chybějící obrázek, nulový výsledek hledání i velký počet záznamů. Pro práci s lokalizací vyzkoušejte delší překlad. Zástupné texty často skryjí, že tlačítko neříká, co udělá, nebo že tabulka přestane být čitelná. Používejte bezpečná ukázková data; skutečné klientské údaje nejsou pro běžný test navigace nutné.

06Dejte každé obrazovce jasnou hlavní akci

Člověk má poznat, čím může úkol posunout dál. Hlavní tlačítko pojmenujte podle výsledku, například „Vybrat termín“ nebo „Potvrdit změnu“. Vizuální důraz porovnejte s vedlejšími možnostmi. Pokud všechna tlačítka soutěží stejnou silou, prototyp neříká, co je podstatné. Současně zachovejte viditelnou cestu zpět a možnost úkol opustit.

07Udržujte stejné pojmy a chování

Nevystřídejte pro jeden záznam názvy „požadavek“, „objednávka“ a „případ“, pokud neoznačují různé věci. Stejná akce má mít stejné pojmenování napříč obrazovkami. Vytvořte krátký slovník a sadu opakovaných prvků. U výjimky si napište důvod. Konzistence se týká také potvrzení, filtrování, ukládání a zavírání dialogů, nejen barvy tlačítek.

08Navrhněte orientaci i návrat

Při každém kroku má být zřejmé, kde člověk je a jak se dostane zpět. Ověřte návrat z detailu do filtrovaného seznamu, zavření dialogu i přerušení více kroků. Rozhodněte, co se při návratu zachová. Pokud prototyp vždy přeskakuje na čistou úvodní obrazovku, může skrývat ztrátu kontextu, kterou později odnese zákazník.

09Formuláře navrhujte včetně popisků a nápovědy

Ke každému poli napište účel, povinnost a omezení. Popisek má zůstat viditelný při vyplňování; příklad uvnitř políčka ho nenahrazuje. Průvodce W3C pro formuláře vysvětluje také význam propojení popisků s ovládacími prvky. Do návrhu proto přidejte poznámku pro implementaci. Statický obrázek sám přístupné propojení neprokazuje.

10Ukažte chybu i způsob nápravy

Připravte alespoň jeden chybný vstup a jeden problém služby. Rozlišujte, co může opravit uživatel a co musí řešit provozovatel. U chyby ponechte zadané údaje a popište další krok. Nechte účastníka testu z chyby samostatně pokračovat. Pokud mu musí autor vysvětlit, co hlášení znamená, máte konkrétní důvod text nebo průchod upravit.

11Zahrňte prázdný, načítaný a nedostupný stav

Seznam plný ideálních záznamů neukazuje první návštěvu ani selhání. Navrhněte, co člověk uvidí bez dat, během čekání a při nedostupné službě. U prázdného výsledku vysvětlete, zda má změnit filtr, přidat první položku nebo počkat. Ke každému stavu napište spouštěcí podmínku, aby si vývojář nemusel domýšlet rozdíl mezi „žádná data“ a „data se nenačetla“.

12Vysvětlete důsledky a potvrďte výsledek

Před závazným krokem ukažte, co se změní, a po dokončení potvrďte skutečný výsledek. U odstranění záznamu rozhodněte, zda půjde akci vrátit. Nepoužívejte stejný neurčitý dialog pro smazání poznámky a zrušení celé objednávky. V prototypu ověřte, zda člověk rozumí následku a pozná, jestli je jeho úkol opravdu dokončený.

13Počítejte s klávesnicí a viditelným fokusem

Ukažte pořadí ovládání, vzhled zaměřeného prvku a návrat fokusu po zavření dialogu. WCAG 2.2 k nezakrytému fokusu požaduje, aby zaměřený prvek nebyl zcela skrytý obsahem vytvořeným autorem. Prověřte proto pevné lišty. Technické chování ověřte v implementaci nebo vhodném funkčním prototypu; samotný klikací obrázek nestačí.

14Navrhněte dostatečné cíle pro kliknutí

Zkontrolujte zejména malé ikony, zaškrtávací políčka a akce v tabulkách. WCAG 2.2 stanoví pro minimální velikost cíle základ 24 × 24 CSS pixelů s vymezenými výjimkami, včetně dostatečných rozestupů. To není doporučení zmenšit všechna tlačítka na minimum. Pro důležité dotykové akce navrhněte pohodlnější prostor a ověřte ho na telefonu.

15Nabídněte alternativu k přetahování

Pokud se položka přesouvá tažením, navrhněte také ovládání bez něj, například nabídku „Přesunout do“ nebo tlačítka změny pořadí. Kritérium WCAG 2.2 pro přetahování popisuje alternativu ovladatelnou jedním ukazatelem bez tažení, pokud není tažení nezbytné. Nezaměňujte ji pouze za klávesovou zkratku. Ověřte také srozumitelnost výsledného pořadí.

16Zkoušejte úzkou obrazovku i delší text

Návrh pro počítač mechanicky nezmenšujte. Rozhodněte, které informace člověk potřebuje nejdřív a jak se na telefonu dostane k ostatním. Vyzkoušejte dlouhé názvy, zvětšení textu a otevřenou klávesnici. U tabulky ověřte, zda lze stále poznat, ke kterému záznamu akce patří. Skrytím důležitého sloupce se problém přesouvá k uživateli.

17Rozlišujte role a viditelnost údajů

Připravte obrazovky pro role, které se v hlavním úkolu skutečně liší. Pracovník může záznam upravovat, zákazník jen číst. V návrhu popište, jak se vysvětlí nedostupná akce, a omezte zbytečné zobrazení osobních údajů. Připomeňte při předání, že skryté tlačítko není kontrola oprávnění na serveru. Prototyp zachycuje zamýšlené chování, nenahrazuje jeho technické ověření.

18Test zadávejte cílem, nikoli postupem

Řekněte „potřebujete změnit zítřejší rezervaci“, ne „klikněte na nabídku vpravo a vyberte druhou položku“. GOV.UK doporučuje úlohy bez návodných odpovědí. Účastník má znát situaci a cíl, ne správnou cestu. Vyberte lidi odpovídající zamýšlené skupině a při potížích se nejdřív dívejte, co zkoušejí, místo okamžité nápovědy.

19Zapisujte pozorování odděleně od vysvětlení

„Tři účastníci přehlédli změnu termínu“ je pozorování v daném testu. „Tlačítko je příliš šedé“ je možná příčina, kterou je třeba ověřit. U nálezu uložte úkol, místo, dopad a navrženou úpravu. Malý kvalitativní test neproměňujte v procentní předpověď celého trhu. Nejdřív řešte překážky dokončení a závažné omyly, potom drobné kosmetické preference.

20Předávejte rozhodnutí, stavy a otevřené otázky

K prototypu připojte hlavní průchody, pravidla polí, prázdné a chybové stavy, chování na mobilu a poznámky k přístupnosti. Označte, co už test podpořil a co zůstává předpokladem. S vývojářem projděte nejasnosti dřív, než začne implementovat. Po úpravách zopakujte dotčený úkol a staré rozhodnutí aktualizujte.

Potřebujete propojit návrh s testem a vývojem? Připravte hlavní úkol, cílovou skupinu a současný prototyp. Na stránce Jak to probíhá najdete rámec spolupráce; konkrétní podmínky předání pak opřete o to, co je nutné ověřit ve vašem projektu.