Přinášíme vám přehled několika chyb a doporučení, které jsme sesbírali při nedávných UX výzkumech. Použijte je například jako checklist, abyste si byli jistí, že vaši uživatelé nebudou chycení do stejné pasti.
Validace je evergreen. Připomeňme si několik základních pravidel.
#1 Zobrazování chyb
Pokud při vyplnění údajů nastane chyba, oznamte tuto informaci uživateli, ukažte, kde se chyba stala, a také konkrétně informujte, jak chybu opravit.
#2 Zobrazujte výstižné popisy chyb a pokuste se chybám předcházet
Když uživatel neví předem, jak má některé pole vyplnit, zákonitě udělá chybu. A s každou chybou některým – hlavně technicky méně zdatným – klesá sebevědomí a vůle dokončit vyplnění formuláře. Když předem uvedeme např. formát telefonního čísla, minimalizujeme množství uživatelů, kteří udělají chybu.
Speciálně v případech, jako je tento, však můžeme chybám předejít i jiným způsobem. Podívejte se na následovný bod.
#3 Netrvejte na přesném formátu dat
V určitých případech můžete drobné chyby „ignorovat“. Při testování stránek pojišťoven jsme zjistili, že některé nedovolily zadat SPZ (EČV) auta s mezerou. Takže striktně po zadání 7 znaků se formulář odeslal a následně zobrazil chybu, že zadaný údaj není správný. Přitom mezery v textovém řetězci dokáže programátor odignorovat jednou rychlou funkcí, ať už na front-endu, nebo back-endu.
Mnohem častější je však vyžadování telefonních čísel v mezinárodním formátu. Pokud provozujete web na Slovensku a většina vašich uživatelů je ze Slovenska, proč jim jednoduše nedovolit zadat číslo v lokální verzi? Po ověření, že formát je správný, si při ukládání do databáze slovenskou předvolbu jednoduše doplníte. A samozřejmě, povolíte zadat číslo i se zahraniční předvolbou.
A do třetice: rodná čísla. Věčná otázka být, či nebýt je v tomto případě: s lomítkem, nebo bez lomítka? Ale asi už tušíte, že ideálně oboje. Tento znak si lehce doplníte nebo odstraníte při ukládání dat. Nezapomeňte však uvést, že očekáváte jeden nebo druhý formát, protože respondenti v našich testech se nad tím pozastavili.
Při objednávání povinného smluvního pojištění na stránce axa.sk můžete být upozornění, že jste rodné číslo zadali „v nesprávném formátu“ – je však problém v chybějícím lomítku, nebo jste udělali překlep v čísle?
Pár vizuálních a obsahových tipů
#4 Označte povinná pole
Lidé očekávají, že není nutné vyplnit všechny údaje. Automaticky hledají označení povinných částí, např. hvězdičkou apod. (Ano, i když jsou všechna pole povinná.)
Pokud uživatelé tuto informaci nenajdou, snaží se si ji domyslet na základě jiných indicií. Respondentka v našem testu například řekla: „Toto políčko má tučný nadpis, zřejmě bude povinné.“ V daném formuláři byla všechna pole povinná a tučný řez písma byl standardním stylem pro označení polí (label).
#5 Pokud akce vyvolá reakci, dejte to najevo
Speciálně u formulářů, které slouží pro výpočet ceny, dejte jasně najevo, že změna nějaké volby upraví cenu produktu nebo služby. Ujistěte se, že:
- změna ceny je vizuálně poutavá,
- cena je umístěná ve viditelné části stránky (ideálně po celou dobu vyplňování formuláře),
- změna nastane ihned po tom, když uživatel klikne na prvek, který přepočet způsobí. Každá (mili)sekunda navíc totiž způsobí, že uživatel si akci a reakci mentálně nespojí.
#6 Ať vaše otázky nevyvolávají víc otázek
Při testování scénáře s uzavíráním cestovního pojištění jsme se setkali s formulářem jako na obrázku níže.
Jak byste odpověděli na otázku: „Tato osoba je také pojištěná?“ Kdo je vlastně ta pojištěná osoba? Je to ten člověk, který formulář vyplňuje? Nebo osoba, která vlastní nouzové číslo? Každá otázka vyvolává sérii dalších otázek, např. proč by můj nouzový kontakt měl být pojištěný nebo proč to pojišťovnu zajímá?
V tomto případě se zkombinovala nevhodná formulace otázky a porušení jednoho z principů Gestalt psychologie aplikované na uživatelské rozhraní. Tzv. Law of proximity říká, že objekty, které jsou blízko u sebe, spolu souvisí. Ve formuláři z příkladu však otázka na pojištěnou osobu nijak nesouvisela s nouzovým číslem, pouze si developer zjednodušil práci a tlačítka ano/ne umístil do sloupce vpravo a s nedostatečným odstupem od předcházejícího řádku. Toto je také důvod, proč se nedoporučuje používat vícesloupcové rozložení pro formuláře.
Všimněte si části formuláře „Nepovinné příplatky“ na stránce CK Satur. Je vám jasné, co je Smart business? Co je „Dopojištění storna k pojištění PLUS (ECP) X…“ a malé čtverečky napravo od této volby?
#7 Vícekrokové formuláře
Rozdělení formuláře do více kroků může mírně snížit tzv. kognitivní zátěž uživatele, protože se může soustředit na méně vyplněných polí, formulář nepůsobí jako moc dlouhý a je vizuálně příjemnější. Dejte si ale (kromě jiného) pozor na následovné:
- Jasně informujte uživatele, že proces je rozložený na kroky, kolik jich je a kde se právě nachází.
- Pokud kroky formuláře implementujete JavaScriptem, dovolte uživatelům se vracet na předcházející kroky tlačítkem Zpět v internetovém prohlížeči, nejen tlačítkem, které jste vložili do stránky (doufáme, že jste ho tam vložili). Back-button je stále jedna z nejpoužívanějších funkcí internetových prohlížečů.
- Pokud v určitém kroku odkazujete na vyplněnou informaci z předcházejících kroků, připomeňte uživateli, jakou hodnotu zvolil.
Příklad: Uživatel si objednává pojištění a v 1. kroku si zvolí datum začátku platnosti. Ve 3. kroku se ptáte, zda „ke zvolenému datu má pojištění i v jiné pojišťovně“ – doplňte toto datum přímo do otázky. Jinak se kognitivní zátěž zvyšuje.
Několik technických tipů hlavně pro developery
#8 Pokud máte vlastní „našeptávače“, ať se nebijí s prohlížečem
Hovoříme zde o autocomplete/suggestion funkcích, kde se například při psaní názvu ulice zobrazí seznam ulic v daném městě a uživatel nemusí dopsat celý název. Při nedávném testování jsme narazili na 2 problémy v jednom formuláři:
- Stránka vyžadovala výběr PSČ z nabízených možností. U tak krátkého údaje jako je PSČ se nikdo z respondentů „neobtěžoval“ klikáním na nabízené možnosti, ale prostě napsal 5 znaků sám.
- Když se počet nabízených možností stránky zúžil na 1 a zároveň se zobrazila nabídka uložených údajů v prohlížeči, tato překryla autocomplete stránky a nebylo možné vybrat danou hodnotu.
Tato testovaná stránka tedy udělala 2 chyby: vyžadovala výběr hodnoty z autocomplete, přičemž nepředpokládala, že by její uživatel nemusel vidět. A při validaci neakceptovala ručně vepsanou hodnotu, přestože přesně splňovala kritéria. Výsledkem bylo, že část respondentů testu v tomto kroku formulář opustila. Co jiného jim zbývalo, když vyplnili 5místné PSČ a vrátila se jim chyba, že PSČ musí mít 5 znaků?
#9 Povolte odeslání formuláře klávesou ENTER
Zdá se to jako hloupost, ale mnoho lidí je zvyklých méně klikat a víc používat klávesnici. Mimochodem, pro tyto lidi je také důležité, aby mohli používat tabulátor na přechod mezi jednotlivými poli formuláře. Ujistěte se, že v takovém případě je zachované správné pořadí jednotlivých prvků (např. nastavením prvku tabindex).
#10 Jak to pomůže uživateli, ignorujte diakritiku nebo její nepřítomnost
Při našem testu jsme viděli případy, kdy vyhledávání na stránce vrátilo jiné výsledky podle toho, zda respondent zadal hledané slovo i s měkčením a délkami. Hlavně na mobilních telefonech lidé píšou bez diakritiky. A potom je tu velká skupina lidí, kteří převážně pracují s anglickou klávesnicí. Prosím, neignorujte nás. 🙂
#11 Když si uživatel musí vybrat z dlouhého seznamu hodnot, dovolte mu v nich vyhledávat
U velmi dlouhých seznamů (například všechny státy světa nebo značka automobilu) si na mobilu člověk trošku „zascrolluje“, než se dostane k hodnotě na konci seznamu. Množství hotových knihoven, jako např. Select2 a jiné, nabízejí hotové řešení tohoto problému.
#12 Nepoužívejte prvek select (dropdown) na málo hodnot
Opačně k předcházejícímu bodu, když máte hodnot na výběr jen málo, např. 2–3, nezobrazujte je ve formě prvku select, ale spíše radio button. Uživatel okamžitě vidí dostupné hodnoty a rychleji tento údaj vyplní.
#13 Používejte správné formulářové prvky na specifická data
Při vyplňování čísel nebo e-mailů je ideální použít prvek <input type=”email”> resp. <input type=”number”> doplněné prvkem inputmode=”numeric” a pattern=”[0-9]*”, díky čemuž se hlavně na mobilních zařízeních zobrazí upravená klávesnice, zobrazující jen čísla nebo znak zavináč bez nutnosti otevřít speciální znaky.
Podobně existuje i nativní možnost vybírat datum bez nutnosti implementovat vlastní kalendář, podpora ve všech browserech je však dnes stále diskutabilní. U kalendářů pozor na jejich použitelnost, psal o tom i náš Martin Krupa v blogu Rok 2018 – rok kalendářů se špatným UX. My jsme si při posledním testování všimli, že lidé chtějí data zadávat i bez použití kalendáře a vy byste jim v tom neměli bránit.
