20 pravidiel UX, ktoré dodržať pri návrhu prototypu

01Určite rozhodnutie, ktoré má prototyp podporiť

Pred kreslením napíšte jednu otázku: Dokáže zákazník zmeniť termín rezervácie bez telefonátu na podporu? Také zadanie pomôže určiť potrebné obrazovky. Výsledok testu má viesť k ďalšiemu kroku, napríklad upraviť výber termínu alebo pokračovať vo vývoji. Všeobecné „overiť dizajn“ je príliš neurčité, pretože nehovorí, aké správanie chcete pozorovať.

02Opíšte celú hlavnú úlohu

Zaznamenajte, odkiaľ človek prichádza, čo už vie a podľa čoho spozná dokončenie. Pri zmene rezervácie cesta nezačína automaticky v prihlásenom prehľade. Môže sa začať odkazom z e-mailu a skončiť novým potvrdením. Prototyp musí obsahovať časti potrebné na overenie tejto cesty. Inak testujete iba výsek, v ktorom sa skutočný problém nemusí ukázať.

03Vychádzajte z konkrétnej skupiny a situácie

„Všetci zákazníci“ nie je vhodný opis pre test. Rozlišujte človeka používajúceho službu prvýkrát, pravidelného používateľa a pracovníka s inými oprávneniami. Zapíšte zariadenie, prostredie a prekážky. Technik v rukaviciach rieši inú situáciu než účtovník pri monitore. Ich preferencie si nevymýšľajte; neisté predpoklady označte a overte rozhovorom alebo pozorovaním.

04Podrobnosť prispôsobte tomu, čo overujete

Na porovnanie dvoch ciest môže stačiť jednoduchý náčrt. Pri overovaní zrozumiteľnosti formulára už potrebujete skutočné texty a chybové stavy. GOV.UK v opise fázy alpha odporúča zamerať prototypovanie na najrizikovejšie predpoklady. Tímu vysvetlite, čo je simulované. Vizuálne hotový prototyp nepotvrdzuje technickú uskutočniteľnosť ani pripravenosť na prevádzku.

05Používajte realistický obsah

Vložte dlhé názvy, chýbajúci obrázok, nulový výsledok vyhľadávania aj veľký počet záznamov. Pri lokalizácii vyskúšajte dlhší preklad. Zástupné texty často skryjú, že tlačidlo nehovorí, čo spraví, alebo že tabuľka prestáva byť čitateľná. Používajte bezpečné ukážkové údaje. Skutočné údaje klientov pri bežnom teste navigácie nepotrebujete.

06Každej obrazovke určite jasnú hlavnú akciu

Človek má rozpoznať, čím posunie úlohu ďalej. Hlavné tlačidlo pomenujte podľa výsledku, napríklad „Vybrať termín“ alebo „Potvrdiť zmenu“. Jeho vizuálny dôraz porovnajte s vedľajšími možnosťami. Ak všetky tlačidlá súperia rovnakou silou, prototyp neukazuje, čo je podstatné. Zároveň nechajte viditeľnú cestu späť a možnosť úlohu opustiť.

07Zachovajte rovnaké pojmy a správanie

Jeden záznam nenazývajte postupne „požiadavka“, „objednávka“ a „prípad“, ak nejde o odlišné veci. Rovnaká akcia má mať rovnaký názov na všetkých obrazovkách. Pripravte krátky slovník a sadu opakovaných prvkov. Pri výnimke si poznačte dôvod. Konzistentné majú byť aj potvrdenia, filtrovanie, ukladanie a zatváranie dialógov, nielen farba tlačidiel.

08Navrhnite orientáciu aj návrat

Pri každom kroku má byť zrejmé, kde človek je a ako sa vráti späť. Overte návrat z detailu do filtrovaného zoznamu, zatvorenie dialógu aj prerušenie viacerých krokov. Rozhodnite, čo sa pri návrate zachová. Ak prototyp vždy preskočí na prázdnu úvodnú obrazovku, môže skrývať stratu kontextu, ktorú neskôr pocíti zákazník.

09Formuláre navrhujte aj s popismi a pomôckami

Ku každému poľu napíšte účel, povinnosť a obmedzenia. Popis má zostať viditeľný počas vypĺňania; príklad v políčku ho nenahrádza. Návod W3C pre formuláre vysvetľuje aj význam prepojenia popisov s ovládacími prvkami. Do návrhu pridajte poznámku pre implementáciu. Statický obrázok sám nepreukazuje prístupné prepojenie.

10Ukážte chybu aj spôsob nápravy

Pripravte aspoň jeden nesprávny vstup a jeden problém služby. Rozlišujte, čo dokáže opraviť používateľ a čo musí riešiť prevádzkovateľ. Pri chybe zachovajte údaje a opíšte ďalší krok. Nechajte účastníka testu samostatne pokračovať. Ak mu autor musí vysvetliť význam správy, máte konkrétny dôvod upraviť text alebo priechod.

11Zahrňte prázdny, načítavaný a nedostupný stav

Zoznam ideálnych záznamov neukazuje prvú návštevu ani zlyhanie. Navrhnite, čo človek uvidí bez údajov, počas čakania a pri nedostupnej službe. Pri prázdnom výsledku vysvetlite, či má upraviť filter, pridať prvú položku alebo počkať. Pri každom stave uveďte podmienku jeho vzniku. Vývojár si potom nemusí domýšľať rozdiel medzi „žiadne údaje“ a „údaje sa nenačítali“.

12Vysvetlite dôsledky a potvrďte výsledok

Pred záväzným krokom ukážte, čo sa zmení, a po dokončení potvrďte výsledok. Pri odstránení záznamu rozhodnite, či možno akciu vrátiť. Nepoužívajte rovnaký neurčitý dialóg na vymazanie poznámky a zrušenie celej objednávky. V prototype overte, či človek chápe následok a rozpozná, že jeho úloha je skutočne dokončená.

13Počítajte s klávesnicou a viditeľným fokusom

Ukážte poradie ovládania, vzhľad zameraného prvku a návrat fokusu po zatvorení dialógu. WCAG 2.2 pri nezakrytom fokuse požaduje, aby zameraný prvok nebol úplne skrytý obsahom vytvoreným autorom. Skontrolujte preto pevné lišty. Technické správanie overte v implementácii alebo vhodnom funkčnom prototype. Samotný klikateľný obrázok nestačí.

14Navrhnite dostatočne veľké ciele na kliknutie

Skontrolujte najmä malé ikony, zaškrtávacie políčka a akcie v tabuľkách. WCAG 2.2 stanovuje pre minimálnu veľkosť cieľa základ 24 × 24 CSS pixelov s vymedzenými výnimkami vrátane dostatočných rozostupov. Nie je to odporúčanie zmenšiť všetky tlačidlá na minimum. Dôležitým dotykovým akciám doprajte pohodlnejší priestor a overte ho na telefóne.

15Ponúknite alternatívu k ťahaniu

Ak sa položka presúva ťahaním, navrhnite aj inú možnosť, napríklad ponuku „Presunúť do“ alebo tlačidlá zmeny poradia. Kritérium WCAG 2.2 pre ťahanie opisuje alternatívu ovládateľnú jedným ukazovateľom bez ťahania, ak ťahanie nie je nevyhnutné. Nezamieňajte ju iba za klávesovú skratku. Overte aj zrozumiteľnosť výsledného poradia.

16Skúšajte úzku obrazovku aj dlhší text

Návrh pre počítač mechanicky nezmenšujte. Rozhodnite, ktoré informácie človek potrebuje ako prvé a ako sa na telefóne dostane k ostatným. Vyskúšajte dlhé názvy, zväčšenie textu a otvorenú klávesnicu. Pri tabuľke overte, či stále vidno, ku ktorému záznamu patrí akcia. Skrytím dôležitého stĺpca prenesiete problém na používateľa.

17Rozlišujte roly a viditeľnosť údajov

Pripravte obrazovky pre roly, ktoré sa v hlavnej úlohe naozaj líšia. Pracovník môže záznam upravovať, zákazník iba čítať. Opíšte vysvetlenie nedostupnej akcie a obmedzte zbytočné zobrazovanie osobných údajov. Pri odovzdaní pripomeňte, že skryté tlačidlo nie je kontrolou oprávnenia na serveri. Prototyp zachytáva zamýšľané správanie, ale nenahrádza jeho technické overenie.

18Test zadávajte cieľom, nie postupom

Povedzte „potrebujete zmeniť zajtrajšiu rezerváciu“, nie „kliknite na ponuku vpravo a vyberte druhú položku“. GOV.UK odporúča úlohy bez navádzajúcich odpovedí. Účastník má poznať situáciu a cieľ, nie správnu cestu. Vyberte ľudí zodpovedajúcich zamýšľanej skupine a pri ťažkostiach najprv pozorujte, čo skúšajú. Nepomáhajte okamžite.

19Pozorovanie zapisujte oddelene od vysvetlenia

„Traja účastníci prehliadli zmenu termínu“ je pozorovanie v konkrétnom teste. „Tlačidlo je príliš sivé“ je možná príčina, ktorú treba overiť. Pri zistení uložte úlohu, miesto, dopad a navrhovanú úpravu. Malý kvalitatívny test nemeňte na percentuálnu predpoveď celého trhu. Najprv riešte prekážky dokončenia a závažné omyly, potom kozmetické preferencie.

20Odovzdávajte rozhodnutia, stavy a otvorené otázky

K prototypu pridajte hlavné priechody, pravidlá polí, prázdne a chybové stavy, správanie na mobile a poznámky k prístupnosti. Označte, čo test podporil a čo zostáva predpokladom. S vývojárom prejdite nejasnosti pred implementáciou. Po úpravách zopakujte dotknutú úlohu a pôvodné rozhodnutie aktualizujte.

Potrebujete prepojiť návrh s testom a vývojom? Pripravte hlavnú úlohu, cieľovú skupinu a súčasný prototyp. Na stránke Ako to prebieha nájdete rámec spolupráce. Konkrétne podmienky odovzdania potom opierajte o to, čo je potrebné overiť vo vašom projekte.