Testování uživatelského zážitku aneb jak na UX design

Čvc 9, 2020

Říká se, náš zákazník, náš pán. Bez něj bychom sice mohli vyvíjet nové produkty, ale hromadily by se nám ve virtuálním skladišti jako nikdy nevydané divadelní hry a pravděpodobně by netrvalo dlouho, než bychom museli zavřít krám. Cílem našich vývojových aktivit tedy musí být software, který někdo chce, potřebuje, prostě je ochoten investovat do něj své peníze. Jak ale zjistit, co lidé chtějí? Co se jim líbí? Jak přemýšlejí? První variantou je čtení myšlenek. Najmout si telepata, který se vybrané osobě projde po temných zákoutích mysli a vše potřebné odtud vyčte. Možná jsme doposud prostě nenarazili na toho pravého, ale rozhodli jsme se, že na to půjdeme více vědecky. Zvítězila varianta druhá – testování uživatelského zážitku, neboli UX.

Velice důležitou postavou celého příběhu vývoje produktu je UI/UX designér. Za těmito zkratkami se skrývá mág, který přetavuje suchý programátorský kód do nablýskaného designu. Mohlo by se zdát, že jeho úlohou je pouze přelakovat původní kulisy a obalamutit diváka. Nic však nemůže být dále od pravdy! Představte si herce, který poctivě půl roku zkouší novou hru, aby nakonec předstoupil před diváky v děravých teplákách. Tak by to přece nešlo. Místo toho navlékne perfektně padnoucí kostým, nalíčí se a předvede dechberoucí vystoupení, které může fungovat jen jako celek. Stejně tak designér uživatelského rozhraní našich aplikací nechává vyniknout funkcionality tím, že graficky rozvrhne tlačítka a umístí je tam, kde budou uživatelům pohodlně na očích.

Jak by to ale dopadlo, kdyby byl designér zavřený doma a maloval si třeba úvodní dashboard aplikace bez kontaktu s publikem? Tvořil by dílo, na které nemá žádné odezvy, a jen by věřil, že si na premiéře odnese vytoužený aplaus. Trefil by se do vkusu publika, nebo by se mohlo stát, že by byl nepochopen? My v KVADOSu naštěstí stojíme nohama pevně na zemi, a i když máme rádi příběhy se šťastným koncem, opíráme své umění o jedničky a nuly, testy a důkazy. Proto všechny návrhy podrobujeme přísným očím kritiků, abychom ve velkém finále do světa vypouštěli jen funkční a moderní produkty.

 

TESTOVÁNÍ PRO KAŽDÉHO?

Testovat z hlediska uživatelské přívětivosti lze v podstatě jakýkoliv produkt, který vyžaduje sofistikované ovládání, od televizního ovladače přes webové stránky až k aplikacím a softwaru různého zaměření. Dá se říct, že vývoj softwaru se bez něj neobejde, proto se testování uživatelských zážitků stalo i naším denním chlebem.

Pokud máte svůj výtvor před očima několik týdnů či měsíců, získali jste už pravděpodobně provozní slepotu. Víte o něm už příliš mnoho a na to, abyste zjistili, zda opravdu funguje správně, potřebujete vnější pohled. Externí testování.
Jak říká odborník v oboru Steve Krug, s testováním se to má jako s návštěvou přátel z jiného města. Když je budete provázet po vašem okolí, začnete si všímat věcí, které jste dříve neviděli, protože jste si na ně prostě zvykli. A také zjistíte, že mnoho věcí, které jsou jasné vám, nemusí být jasné všem.

Proč jsme to neudělali dříve? Tato otázka nás napadla hned při prvním testování. Jak se říká, i špatný test s pouhým jedním uživatelem je lepší než žádný test. Stačí vidět, jak se uživatel při ovládání chová, a otevřou se vám oči. V dnešní době nikdo nechce číst zdlouhavé návody nebo vyhledávat rady v nápovědě. Aplikace musí být intuitivní a pohodlná. Vrhli jsme se tedy na přípravy.

 

PŘÍPRAVA JE ZÁKLAD

Na startu bylo důležité uvědomit si, že testování uživatelského zážitku je velice užitečným nástrojem pro vývoj našeho produktu. Byli jsme však stále na samotném začátku cesty. Nejprve bylo potřeba dát dohromady funkční scénář, kterého se budeme po celou dobu testování držet. Zahrnoval důležité informace jako termíny, výběr osob pro testování, rozpracované zadání s úkoly pro testera a kritéria pro vyhodnocení.

 

KDY ZAČÍT TESTOVAT

Spousta firem se do testování pouští, až mají hotový produkt. Do té doby vědí, že vývoj ještě není u konce, je tam spousta nedodělávek, takže si myslí, že je potřeba počkat, aby si závěrem ověřili, že je software v pořádku. Ale stejně jako na divadle platí, že zkoušky dělají mistra. Mnohem efektivnější je testovat od samotného počátku projektu. Dokončíte návrh první funkcionality, rozmístíte tlačítka na úvodním dashboardu, rozhodnete se pro barevnou kombinaci… a můžete zahájit první vlnu testů. Ano, zpočátku se nám zdálo, že to bude znamenat více práce, než se s procesem testování sžijeme. Ve výsledku jsme ale dost času ušetřili, protože případné chyby a matoucí prvky z aplikace odstraňujeme hned ze startu a nestavíme na nich další a další.
Začít je přitom možné i přímo ve firmě. Navrhujeme wireframe aplikace pro zpracování účetnictví? Pojďme si natrénovat své vystoupení před domácím publikem. Zeptali jsme se tedy naší účetní, co by očekávala pod vybraným tlačítkem. U nás v KVADOSu se například při vývoji agend myTEAM® pro oběh objednávek a faktur zapojili do testování naše fakturantky a s nimi i marketingové a obchodní oddělení, které je často právě fakturami zásobuje. Testovali jsme tak celý průběh už od počátečních návrhů, což nám pomohlo vychytat i detaily a nastavit vše procesně správně.

 

JAK VYBRAT TY SPRÁVNÉ OSOBY

Jakmile jsme vyčerpali personální možnosti uvnitř firmy, bylo potřeba se zamyslet nad tím, kdo by měl náš produkt otestovat zvenčí. S výběrem kandidátů často pomáhají specializované agentury, na které je možné se se zadáním obrátit. Pro takové zadání je potřeba rozpracovat důkladně popis typického zákazníka, takzvanou personu. Sepsali jsme si o něm všechny detaily, které známe – jeho věk, pohlaví, zájmy, pracovní pozici, problémy, které může řešit a podobně. Pomohlo nám to vžít se do něj a lépe si představit jeho potřeby. Agentura už podle zadání celý casting zorganizovala a dodala nám ty nejvhodnější adepty.
Další variantou bylo vytipovat si některé z klientů, se kterými máme přátelské vztahy, a pokusit se dostat zpětnou vazbu na nově vyvíjené funkcionality přímo od nich. Tuto možnost využíváme v KVADOSu rádi, protože tak získáváme příležitost popovídat si s klienty o jejich potřebách a zapracovat připomínky, které mají přímo z praxe.
Důležitou otázkou samozřejmě bylo, kolik testerů je pro realizaci potřeba. Odborné příručky i praxe se shodují na počtu kolem 3–6 osob. Tato skupina už je schopna odhalit až 75 % zásadních problémů použitelnosti produktu.

 

ZADÁNÍ PRO TESTERA

Aby tester zvládl zpracovat všechny zadané úkoly, potřebuje se vžít do své role. Proto jsme ho na začátek museli uvést do děje. Jednotlivé úkoly by potom měly být jasně dané a předané také písemně. Jakékoliv další vysvětlování je kontraproduktivní, pokud chceme zjistit, jak by se uživatel choval, kdyby naši aplikaci používal o samotě.

 

MÁME DOTESTOVÁNO

Po každém kole testování je dobré podívat se co nejdříve na výsledky, aby byl průběh testování ještě v živé paměti. Výsledky je třeba roztřídit. Jedná se o chyby? Potom přiřadíme prioritu opravy podle jejich závažnosti a seskupujeme je do logických celků. Další kategorií jsou náměty na zlepšení, které mohou vzejít přímo od testera, nebo je vypozorujeme z jeho chování během testu. Někde se ztrácel, trvalo mu dlouho dojít k cíli? Obecně vzato se doporučuje před dalším kolem testů opravit závažné chyby, ale také ty menší, které jsou hodně na očích. Důležité pro nás bylo, zůstat otevření změnám a netrvat za každou cenu na svém. Pokud měl v dané oblasti problém i jeden tester, je vždy na zvážení, zda ji nezkusit zrevidovat. Museli jsme se připravit na přísnou kritiku stejně jako na hladký průběh. Říkali jsme si, že pochválit se můžeme nakonec sami v týmu, když se nám podaří nalezené chyby opravit.

 

A CO NA TO UŽIVATELÉ?

Zjistili jsme testováním na vlastní kůži a přečetli jsme si také o zkušenostech ostatních. Obě cesty jsou užitečné a rozšířily nám obzory. O čem je řeč? Existuje pár věcí, které uživatele aplikace spolehlivě naštvou. Proč tedy zbytečně pokoušet jeho trpělivost?

 

Příliš mnoho osobních údajů

Chceme po uživateli, aby si stáhl demoverzi našeho produktu zcela zdarma. Nabízíme mu veškeré své know-how na zlatém podnose, ale poptávky nechodí? Nechceme po něm náhodou více informací, než nezbytně potřebujete? Lidé neradi pouštějí z ruky osobní údaje z obavy z jejich zneužití.

Složité ovládání

Používání aplikace by mělo být co nejvíce intuitivní. Uživatel u své práce dozajista přemýšlí, neměl by však být nucen přemýšlet o jednoduchých úkonech. Chci založit nový úkol a předat ho kolegovi? Nebo chci do systému vložit fakturu a předat ji k zaplacení? Aplikace by měla uživateli vyjít vstříc a nenutit ho dělat věci složitě. Na tyto nedokonalosti nás upozornilo testování.

Klacky pod nohy

Ještě ukážeme uživateli pár obrázků, necháme ho projít dlouhým videem, přesměrujeme ho na jiný odkaz? Známe to sami na sobě – doba je uspěchaná a nikdo nechce ztrácet čas, stejně tak uživatel našeho produktu se chce co nejdříve dostat k cíli.

Šaty dělají aplikaci

Jakmile jsme vychytali všechny mouchy na ovládání systému, přišel čas podívat se i na design. První dojem uděláte jenom jednou, proto jsme si při vývoji nové generace systému myTEAM® dali záležet na jeho designu. Dobrá uživatelská zkušenost (UX) vychází především z toho, jak snadno se lidé dostanou k potřebným údajům. Proto musí být uživatelské rozhraní (UI) co nejvíce přehledné. Nanic bude tlačítko s převratnou funkcí, když si ho nikdo v záplavě další grafiky nevšimne.

 

myTEAM POD LUPOU

Po řadě interních testů jsme se rozhodli, že necháme novou verzi naší aplikace myTEAM® otestovat externími uživateli. Vybrali jsme si ověřenou agenturu, připravili zadání a prošli si krok za krokem všemi fázemi. Na začátku jsme si stanovili jasné cíle výzkumu. Chtěli jsme zjistit, zda je práce s myTEAM® snadná a intuitivní, a identifikovat místa, na kterých by se mohli uživatelé případně zaseknout. Zajímalo nás, zda a kdy využívají jako pomoc nápovědu, případně v jaké formě. Byli jsme zvědaví také na porovnání stylu práce v myTEAM® se stávající praxí uživatele. A samozřejmě jsme chtěli vědět, jestli by uživatelé o našem systému uvažovali a zaujal je i pro jejich firmu. Tentokrát jsme se zaměřili na oblast úkolování a porady.

Testy jsme prováděli s šesti respondenty, kteří zapadali do cílové skupiny našich potenciálních klientů. Šlo o ředitele divizí a manažery oddělení, kteří zadávají svým podřízeným úkoly a svolávají porady. Vybrali jsme je z různých sektorů, s různým počtem podřízených, podle práce na rozlišných zařízeních a velikostech monitorů a podobně. S testery jsme vedli hloubkové rozhovory a sledovali je při zpracování zadaných úkolů v délce 80 minut. Jeden z úkolů vypadal například takto: „Zadejte úkol své asistentce, aby vám ještě dnes do 18. hodiny vytiskla podklady na zítřejší výběrová řízení na pozici programátora s tím, že chcete, aby Vám asistentka potvrdila přijetí úkolu, a vy si ho následně chcete zkontrolovat.“ Průběh řešení jsme zaznamenávali a sledovali reakce respondenta na očekávané kroky.

A co nám toto kolo testů přineslo? Identifikovali jsme místa, kde uživatele zatěžovalo více klikání a procházení informací, které v danou chvíli považovali za méně důležité. Na základě jejich připomínek jsme také zredukovali počet polí pro vyplnění i množství voleb v daných krocích. Zjistili jsme, které prvky by bylo vhodné zvýraznit, a které naopak potlačit. Nasbírali jsme také hodně užitečných podnětů na rozšíření funkcionalit.

Měli jsme z odhalení opony našeho vlajkového produktu obavy? Měli. Ale představení dopadlo lépe, než jsme čekali a, my už teď víme, že musíme začít připravovat reprízu. Jen tak dokážeme naše produkty posouvat stále kupředu.

 

 
Více se dozvíte přímo od našich obchodníků. 
WordPress Lightbox Plugin