Az űrlapok az online ügyintézés legfontosabb elemei. Az űrlaptervezés alapelveinek és jó gyakorlatainak követésével biztosíthatjuk, hogy a felhasználók könnyen és hatékonyan navigálhassanak az űrlapokon, és sikeresen adhassák meg a szükséges adatokat.
Az űrlapokra úgy is gondolhatunk, mint egy beszélgetésre a felület és a felhasználó között. A felület kérdez, a felhasználó válaszol.
Könnyebb lesz a kommunikáció – azaz az űrlap kitöltése –, ha a felhasználó logikáját követjük a rendszer vagy az adatbázis logikája helyett. Például az elérhetőségek megadását érdemes a felhasználó nevével kezdeni, majd a telefonszámmal vagy az e-mail címmel folytatni.
Ha nem ismerjük a felhasználó logikáját, felhasználói interjúkkal és használhatósági tesztekkel határozhatjuk meg a helyes sorrendet.
Sokszor a felhasználó csak a kitöltés közben vagy végén jön rá, hogy mégsem tudja kitölteni az űrlapot. Előfordulhat, hogy jóval több adatot kell megadnia, mint amire számított, esetleg nincs nála egy okmány vagy nem megfelelőek a körülmények.
Megóvhatjuk a felhasználót a frusztrációtól, ha már a kitöltés megkezdése előtt egyértelművé tesszük, mire számíthat.
Érdemes előre tisztázni, hogy milyen feltételeknek kell megfelelnie – például nagykorúság –, milyen okmányokra lesz szüksége, kell-e például fényképet készítenie vagy videochatelnie a folyamat során. Így felkészülhet, illetve későbbre halaszthatja a kitöltést.
A kitöltés várható időtartamának feltüntetése viszont frusztrálhatja azokat, akiknek több időre van szükségük. Az időtartam helyett inkább azt jelezzük, hogy hány lépésből fog állni a folyamat.
A választási lehetőségek és a válaszok függvényében érdemes olyan kitöltési útvonalra vezetni felhasználókat, amely kevesebb kérdést tartalmaz vagy valamilyen módon testreszabott.
Érdemes meghatározni a leggyakoribb felhasználói utakat, és a lehető legkorábbi ponton – akár egy direkt kérdéssel – a megfelelő útra terelni a felhasználókat.
A hibák kezelése helyett a hibák megelőzésére kell törekedni. Jól megválasztott beviteli mezőkkel, alapértékekkel, egyértelmű címkékkel és kontextuális segítségekkel – helper textekkel, toggletipekkel – sok esetben elkerülhető a hibázás.
Érdemes rugalmasan kezelni a hibákat, és megengedni a felhasználóknak, hogy olyan formátumban adják meg az adatokat, ahogy nekik természetes. Például telefonszámoknál az egybeírást, a szóközös és a kötőjeles elválasztást is elfogadhatjuk.
Jó gyakorlat – különösen hosszabb űrlapoknál –, ha a felhasználók a beküldés előtt átnézhetik és szerkeszthetik a megadott adatokat.
Ezzel csökkenthetjük a hibák számát, és a felhasználó is megbizonyosodhat arról, hogy biztosan mindent jól töltött ki.
Az űrlap beküldése után érdemes azonnal visszajelzést adni a felhasználónak, és elmagyarázni, hogy mire számíthat a továbbiakban. Például milyen feladata van még, illetve mikor és milyen csatornán kap majd választ.
Visszajelzést a felületen és visszaigazoló e-mailben is adhatunk. Ha a visszajelzés tisztázza a gyakran felmerülő kérdéseket, csökkenthetjük az ügyfélszolgálat terhelését is.
A visszaigazoló e-mail az űrlap kitöltése során megadott adatokat is tartalmazhatja. A következő lépésekről – például időpontfoglalásnál a közelgő időpontról – is érdemes emlékeztetőt küldeni.
Az űrlap tervezése során érdemes kutatásokat végezni valós felhasználókkal.
Az analitikai adatok segíthetnek felderíteni a problémákat, de sokszor nem adnak elég információt a probléma mélyebb megértéséhez, ezért érdemes őket kvalitatív módszerekkel – például használhatósági tesztekkel – kombinálni.
Az űrlapoknál általában az egyoszlopos elrendezést preferáljuk. Az egyoszlopos elrendezés követi a természetes szemmozgást, és a felhasználónak egyszerre csak egy dologra kell koncentrálnia.
Többoszlopos elrendezésnél sokszor nem egyértelmű, hogy milyen sorrendben kell kitölteni a beviteli mezőket, illetve előfordulhat, hogy a képernyőnagyító szoftvert használók nem vesznek észre minden mezőt.
A beviteli mezők csoportosítása megkönnyíti az űrlap áttekintését és a navigálást. Ha logikus a csoportosítás, a felhasználónak ritkábban kell kontextust váltania.
A beviteli mezőket a felhasználó számára logikus sorrendben kell megjeleníteni. Segíti a kitöltést, ha a felhasználói felület a valós, fizikai tárgyakat idézi.
A túl hosszú űrlapok számos használhatósági problémát okozhatnak.
-
A felhasználók elfáradhatnak a kitöltésben.
-
Túl sok dolgot kell észben tartaniuk.
-
Úgy érezhetik, hogy az űrlap kitöltésébe fektetett energia nem arányos a szolgáltatás hasznosságával.
Érdemes átgondolni, hogy valóban szükség van-e egy-egy adatra, illetve meg tudjuk-e könnyíteni a kitöltést például előre kitöltött mezőkkel vagy megfelelő alapértékekkel.
Ezen kívül többlépcsős űrlapokkal, progresszív megjelenítéssel és az adatok elmentésével is javíthatjuk a felhasználói élményt.
Többlépcsős űrlapokkal több oldalon jeleníthetjük meg a logikailag összetartozó beviteli mezőket. Bár ilyenkor több lépésből áll az űrlap, a kitöltés valójában hatékonyabb lesz.
Érdemes transzparensen kommunikálni, hogy hol tart a felhasználó. Használhatunk progress steppert, illetve az űrlap elején – hosszabb űrlapoknál az egyes lépések előtt is – összefoglalhatjuk a teendőket.
Progresszív megjelenítésnél – progressive disclosure – egyes tartalmak fokozatosan jelennek meg a felhasználók számára, például amikor kitöltenek egy beviteli mezőt.
Ezzel a megoldással a felhasználói felület áttekinthetőbbé válhat, és csökkenthetjük a felhasználók kognitív terhelését.
Fontos, hogy csak indokolt esetben használjuk. Túl gyakran használva nőhet az interakciós költség, és a dinamikusan megjelenő tartalmak dezorientálhatják az asszisztív technológiákat használó felhasználókat.
Hosszú űrlapoknál érdemes automatikusan menteni a felhasználók által megadott adatokat és a haladást, hogy megszakíthassák és később is folytathassák a kitöltést.
Jó gyakorlat egy összefoglaló képernyőn megmutatni, hogy hol tart a felhasználó – milyen lépésekkel végzett, mi van még hátra –, és közvetlenül is linkelni a lépéseket.
A beviteli mezők megjelenésénél törekedjünk az egyszerű, megszokott, a platform sztenderdjeit követő megoldások használatára. A felhasználónak ránézésre értenie kell, hogy milyen adatot vár el és hogyan működik egy-egy beviteli mező.
A szöveges beviteli mezők alapértelmezetten legyenek üresek. Placeholderekre csak ritkán van szükség.
Nem érdemes az összes beviteli mezőt azonos szélességűre állítani. Esztétikailag kiegyensúlyozottabbnak tűnhet a felület, de használhatósági problémákat okozhat.
-
A szükségesnél szélesebb beviteli mezők azt sugallják, hogy a felhasználónak a ténylegesnél hosszabb adatot kell megadnia.
-
A szükségesnél keskenyebb beviteli mezők a ténylegesnél rövidebb adatra utalnak, és frusztráló a használatuk.
Ügyeljünk rá, hogy a beviteli mező érintési területe megfelelően nagy – legalább 40x40px – legyen.
Mindig a megfelelő mezőtípust – input type-ot – használjunk, hogy mobileszközökön a megfelelő billentyűzet jelenjen meg.
A legördülő menük – Dropdownok – sok használhatósági és akadálymentesítési problémát okoznak, ezért érdemes kerülni őket. 10-nél kevesebb lehetőség esetén inkább Radio buttont vagy Checkboxot használjunk.
A Radio buttonnél és a Checkboxnál minden opció látható, ezért a kiválasztás interakciós költsége is alacsonyabb.
Érdemes kerülni az adatok több beviteli mezőre bontását. Az input maszkolása és az automatikus léptetés több mezőnél nehezen akadálymentesíthető.
Bizonyos esetekben – például nemzetközi dátumoknál – a validáció nem egyértelmű, ha csak egyetlen beviteli mezőt használunk. Ezeket érdemes szétbontatni.
Emlékezetes dátumoknál – például születési dátumnál – nem érdemes dátumválasztót használni.
A nem mindenki számára egyértelmű vagy nehezebben kitölthető mezőknél – például jelszó beállításánál – adjunk segítséget a helyes kitöltéshez. Ne bízzuk csak a hibaüzenetre a tájékoztatást!
A beviteli mezőkbe írható karakterek számát (maxlength) csak nagyon indokolt esetben limitáljuk.
Gépelés közben sokan nem nézik a képernyőt, ezért nem veszik észre, ha elérték a limitet. Az adatok bemásolásánál sem egyértelmű a működés, ezért inkább a validációnál kezeljük a karakterszámot.
A beviteli mezőket érdemes úgy paraméterezni, hogy támogassák a böngészők automatikus kiegészítését és a jelszókezelőket (autofill).
Azoknál a beviteli mezőknél, ahol nyelvtanilag helytelen adatokat várunk el – például e-mail címeknél vagy felhasználóneveknél – az autocapitalize="none", autocorrect="off" és a spellcheck="false" attribútumokat használjuk.
A kötelező mezőket a label mögötti piros csillaggal jelöljük. Ha minden mező kötelező, elhagyhatjuk a piros csillagot, elég kódban jelölni az asszisztív technológiák számára.
Az opcionális mezőket a label mögötti (Nem kötelező) szöveggel jelöljük.
Ezeket a tulajdonságokat a Label komponens tartalmazza.
A látható, egyértelmű Labelek a beviteli mezők és az űrlapok használhatóságának kulcsai.
Inkluzivitási szempontból a látható label a legjobb megoldás. A látó felhasználók látják, a nem látó felhasználók asszisztív technológiák segítségével hallhatják vagy tapinthatják, a motorikus nehézségekkel élőknek pedig nagyobb aktiválási felületet biztosít.
A labelt a beviteli mező fölé, balra igazítjuk. Ez a pozíció igényli a legkevesebb szemmozgást a felhasználótól, és támogatja az online tartalmaknál jellemző szkennelve olvasást.
Ezzel a pozícióval azoknak a felhasználóknak is segítünk, akik nagyítva használják a felületet, mert nagyobb eséllyel látják majd egyszerre a labelt és a beviteli mezőt.
Sem az úgynevezett floating labelek, sem a placeholderek, sem a csak ikonokkal jelzett mezők nem helyettesítik a labeleket, és számos használhatósági és akadálymentesítési problémát okoznak.
A label csak nagyon indokolt esetben, ha az elvárt adatra van valamilyen kontextuális utalás – például a keresőmezőben egy nagyító ikon – hagyható el. Ilyenkor gondoskodni kell az akadálymentesítésről, és szakértővel kell validálni az implementációt.
A beviteli mező labelének egyértelműen le kell írnia, hogy milyen adatot várunk a felhasználótól. Ha a label kiegészítésre szorul, Helper texttel vagy Toggletippel segíthetünk a felhasználónak.
A helper text és a toggletip is helyben, navigálás nélkül elérhető, kontextuális segítség, ezért felfedezhetőbb és gyorsabb megoldás, mint például a súgó.
-
A helper textet a mező kitöltéséhez szükséges információk – például formátum – megjelenítésére használjuk.
-
A toggletip csak interakció után olvasható, ezért csak indokolt esetben, kevésbé fontos kiegészítő információkhoz használjuk.
Fontos, hogy csak akkor használjunk helper textet vagy toggletipet, ha valóban szükség van rá! Érdemes felhasználói kutatásokkal vagy tesztekkel felmérni, hogy hol igényel segítséget a felhasználó.
A placeholderek használhatósági problémákat okozhatnak. Általában jobb megoldás helper textként feltüntetni a beviteli mező kitöltéséhez szükséges információkat.
A Search fieldnél viszont jó gyakorlat, ha placeholderrel segítünk a felhasználónak abban, hogy mire kereshet rá (pl. Keresés megyére, városra, stb.).
Használjunk olyan szélességet és magasságot, amely megfelelő területet biztosít érintéssel való aktiváláshoz is (legalább 40px).
A gombok szélessége alapértelmezetten igazodjon a bennük lévő tartalomhoz.
Mobilfelületeken viszont érdemes lehet teljes szélességű gombokat használni, és egymás alá rendezni őket.
A gombok illeszkedjenek a platformok sztenderdjeihez, és nézzenek ki gombnak.
A negatív következményekkel járó, visszavonhatatlan akciókat – például regisztráció törlése – érdemes színnel is megkülönböztetni, és úgynevezett destruktív gombokat használni.
A kevésbé fontos akciók gombjai legyenek vizuálisan is kevésbé hangsúlyosak.
Az űrlapokon a legfontosabb akciót – például a küldést – végző primary gombot mindig a beviteli mező széléhez, balra igazítjuk. Ez a pozíció illeszkedik a természetes szemmozgáshoz, és a képernyő nagyításával böngészőknek is optimális.
A további gombokat a primary gomb után helyezzük el. Ez követi a természetes olvasási sorrendet és a billentyűzet fókusz sorrendjét.
A vissza navigáló linkeket érdemes a bal felső sarokban elhelyezni. Így a billentyűzettel navigálók is gyorsan és kényelmesen érhetik el őket.
A gomboknál is fontos egyértelmű vizuális hierarchiát kialakítani, mivel ez segíthet a felhasználónak könnyen beazonosítani az elsődleges műveletet.
A legjobb, ha egy oldal vagy szekció csak egyetlen elsődleges – primary – gombot tartalmaz. A többi akciónál a kevésbé hangsúlyos – outlined vagy subtle – variánst érdemes használni a hierarchia megteremtéséhez.
A letiltott – disabled – gombok nem mindenki számára egyértelműek, és használhatósági és akadálymentesítési problémákat is okoznak, ezért nem javasolt a használatuk. Érdemes teljes hozzáférést biztosítani az összes művelethez, még akkor is, ha ez azt jelenti, hogy a felhasználó hibázik.
Ha mégis disabled gombot kell használni, akkor is érdemes úgy implementálni, hogy fókuszálható és aktiválható legyen, és az aktiváláskor jelezni, hogy miért nem hajtható végre az akció.
Bár a hibák kezelése helyett a hibák megelőzésére kell törekedni, előfordulhat, hogy valaki hibázik. A hibákat mindig egyértelműen jelezzük vissza, és ne hagyjuk bizonytalanságban a felhasználót.
-
A hibaüzenetet – Feedback message – a kontextushoz közel – jellemzően a beviteli mező alatt – jelenítsük meg.
-
Hosszabb űrlapoknál, ha több beviteli mezőt is hibásan töltött ki a felhasználó, érdemes összefoglalni a hibákat, és linkelni a helytelenül kitöltött űrlapelemre.
-
A hibaüzenetek szemantikus színe piros. A szemantikai jelentést az üzenet előtti ikonnal is érdemes megerősíteni a színvak felhasználók számára.
A hibaüzenetek szövegeire vonatkozó jó gyakorlatok a Hibaüzenetek útmutatóban találhatók.
Általában csak akkor érdemes elvégezni a validációt, ha a felhasználó végzett egy lépéssel vagy beküldi az űrlapot. A fókuszvesztésre történő validáció sokszor feleslegesen akasztja meg a felhasználókat, mert előfordulhat, hogy nem feltétlenül sorban töltik ki a beviteli mezőket vagy csak ismerkednek az űrlappal.
Jelszóerősség vizsgálatakor vagy karakterlimit számításánál viszont érdemes élő, gépelés közbeni validációt használni.
Az opcionális mezőket nem érdemes validálni.
Button A button olyan interaktív elem, amellyel műveleteket lehet végrehajtani. 
Checkbox A checkbox segítségével egy vagy több lehetőséget választhatnak ki a felhasználók. 
Dropdown A dropdownnal egy listából egy vagy több lehetőséget választhatnak ki a felhasználók. 
Feedback message A feedback message segítségével a beviteli mezők kitöltésével kapcsolatban adhatunk visszajelzést a felhasználónak. 
Label A label arról tájékoztatja a felhasználót, hogy milyen adatot kell megadnia egy beviteli mezőben. 
Number field A number field egész számok megadására szolgáló komponens. 
Password field A password fielddel jelszavakat adhatnak meg a felhasználók. 
Radio button A radio button segítségével több – egymást kizáró – lehetőség közül egyet választhatnak ki a felhasználók. 
Switch A switch segítségével két lehetséges állapot közül választhatnak a felhasználók. 
Text field A text fielddel rövid szöveges adatokat adhat meg a felhasználó. 
Textarea A textarea segítségével hosszabb, több soros szöveges adatokat adhat meg a felhasználó. 
Toggletip A toggletip kontextuális segítség, amellyel kiegészítő információkat adhatunk a felhasználóknak.