To se ví, že ani ti nejlepší ergonomové nejsou tak dobří, aby nemuseli dělat uživatelská testování, výzkumy a podobné činnosti. Zrovna tento týden mi jeden kolega programátor, co už má u nás ve firmě vysezený důlek, vysvětloval, že má tolik zkušeností, že už umí chování a potřeby uživatelů lehce odhadnout; a my ergonomové, kteří si o tom čteme z knížek (rozuměj my, co se v ergonomii dále vzděláváme) jsme mimo. Bohužel jeho produkt z časových důvodů ještě neřešíme, takže má falešný pocit, že oni jsou v pohodě a že jejich guesswork funguje. To je vskutku velký omyl. Nefunguje.

Ani vy si to o svých aplikacích nemyslete. Pokud jste o tom přesvědčeni, začněte ihned provádět alespoň intenzívní uživatelské testování. Však vás to přejde ;- )

Mezi lidmi, i mezi těmi v IT, panuje mylná představa, že pro provedení uživatelského testování potřebujete speciální hardware a software, místnosti s poloprůhlednými skly, dobře vyškolené a zkušené psychology a podobně. Vůbec ne. Uživatelské testování můžete rozjet ve vaší firmě zítra ráno (no dobrá, do týdne) a nebude vás to stát nic, kromě času několika lidí. Do uživatelského testování je samozřejmě možno dát hodně peněz, ale pokud jste ho ještě nikdy neprováděli, byly by vyhozené. Dobré, neomezované pracoviště lze vytvořit do 50 000 korun (software – 1000 USD, normální vyhrazený počítač – 1500 USD?, kamera – 20 USD, mikrofon – 10 USD), ale jak si ukážeme v tomto článku, lze se bez této investice obejít.

Nyní popíši doporučený průběh vašeho prvního uživatelského testování. V dalších příspěvcích popíši ideální/optimální stav.Nejdříve je třeba vymyslet, co chcete testovat. Uživateli by mělo splnění úkolu trvat podle vás asi půl až tři čtvrtě hodiny. Ne víc, ono se to určitě protáhne na hodinu nebo i na dvě. Asi se vám bude zdát, že to bude jen malá část aplikace, to nevadí.

Napíšete zadání. Mělo by být krátké a stručné a mělo by hovořit uživatelovým jazykem. Dobrý příklad: Přišel jsi do práce a našel jsi v mailu požadavek na ocenění projektu, zpracuj nabídku. Špatný příklad: Vytvoř nový projekt v nabídce Ocenění, ulož ho… Zadání má být kompletní, měly by tam být napsány cesty k souborům, se kterými se bude pracovat, hesla a podobně.

Také je třeba specifikovat, koho chcete testovat. Pokud už jste pokročili v UCD, prostě vyberete roli nebo personu a jste hotovi. Tu nyní samozřejmě nemáte, proto se zamyslíte, komu je funkcionalita určena.

Mezi vašimi kolegy nebo zákazníky najdete 3–5 lidí, kteří budou ochotni se testování zúčastnit a kteří více méně odpovídají vašim představám o uživatelích testované funkcionality. Lepší jsou kolegové, jsou lépe k dispozici a výsledky s nimi budou taky dobré. Zákazníky se nezdržujte.

Naplánujete termín testování. Na jednu testovanou osobu počítejte hodinu a půl, takže pět lidí zabere asi den.

Sezvěte všechny zúčastněné. Testovanou osobu, moderátora, odborníka na použitelnost, produktového analytika, hlavního programátora, programátora funkcionality… Všechny, co mohou ovlivnit podobu aplikace. Ideálně jsou v místnosti, kde se testuje, dva, maximálně tři lidé. Zájemců bývá víc, proto je dobré obrazovku testovacího (normálního) počítače přenášet jinam. První testy ale proveďte se všemi lidmi, je to kolektivní zážitek.

Postupně proveďte test se všemi uživateli, každý z účastníků by si měl psát poznámky, co by se dalo v aplikaci zlepšit. Podrobnosti o průběhu samotného testu vydají na samostatný článek.

Po skončení testů, nejlépe na druhý den, by se měli všichni pozorovatelé sejít na společné schůzce a projít si své poznámky. Mnohé se bude shodovat s poznámkami ostatních, uživatelé budou mít podobné problémy a chování. Vedoucí schůzky by měl zajistit, aby se všechny náměty zaznamenaly do firemního systému tak, aby se jimi někdo zabýval a do některé příští verze se změny v softwaru provedly.

A to je vše. Je to dlouhý článek, ale když si ho projdete, zjistíte, že je to celé hodně jednoduché. Vlastně je to jen trocha organizace.

Sledování pohybu očí

Sledování očí má smysl a je to velice dobrá technika. Ale na něco jiného, než na vylepšování aplikací. Hodí se na webové stránky a na letáky. U webu máte několik sekund na to potenciálního zákazníka zaujmout. V letáku je to podobné. Kdyby například tento server měl za cíl vychytat si SEO a profitovat z náhodných návštěvníků, kteří si budou kupovat elektroniku tady a ne v jednom z milionu úplně stejných obchodů, testování pohybu očí by pomohlo ulovit nějaké to procento lidí navíc. Ale že je tento server postavený na pravidelných návštěvnících, je důležitější zjišťovat a řešit jiné věci. Že lidem chybí nějaká vlastnost, že by něco bylo lepší dělat lépe nebo jaká témata čtenáře (uživatele) zajímají.V aplikacích je to stejné, lidé s nimi pracují dlouhodobě a naučili se v tom chodit. Takže jejich kroky jsou rychlé, mechanické a (někdy) zbytečně dlouhé. Třeba se cesty učili před několika lety a nikdo jim neřekl o nových zkratkách a sami je neobjevili. Sledováním očí bychom zjistili, že je vše v pořádku – chodí rychle a plynule.

Speciální týmy pozorovatelů

Někdy je ve filmech vidět, jak je test promyšlen a naplánován do detailů, kontroluje se každá odchylka od připraveného scénáře, kreslí se grafy, vyhodnocuje se pomocí superpočítače a týmu psychologů. Testů jsou desítky. Jistě by to tak bylo zajímavé dělat. Vy to tak nedělejte. Toto celé by stálo spousty peněz. Udělejte to co nejjednodušeji a nejlevněji. Získáte “jen” 80 procent podnětů a bude vás to stát tisícinu peněz a času. Udělejte 3-5 testů a pozvěte ke sledování (sdílení obrazovek) ty, kdo s testovanou oblastí mají u vás co do činění.

Poloprůhlené stěny

Někde (ve filmech) jsou k vidění poloprůhledné stěny. Je doba počítačová, kamery si dáte, kam budete chtít a pracovní plochu je stejně dobré přenést do jiného počítače. Jestli nevíte co s penězi, vybudujte si dvoumístnost jen na testování, jinak to jsou zbytečně vyhozené peníze.

Nahrávání a vyhodnocování videa

Když jsme s uživatelskými testováními začínali, koupili jsme speciální software (Morae) pro nahrávání a vyhodnocování videa. Snímá se obrazovka, video z kamery, zvuk, myš, kliky, klávesy… spousta věcí. Při vyhodnocování lze dělat grafy, statistiky, stříhat video…

Problém je, že když testujete na třech lidech po hodině, jen přehrání záznamu zabere další tři hodiny a to je dost času. Proto se snažíme všechny podněty zaznamenat už v průběhu testu a záznam už nevyhodnocujeme. Test nahráváme jen pro případ sporů (což se skoro neděje), pokud se chceme podívat na nějakou konkrétní situaci (zaznamenáme si čas) nebo pro kolegy, kteří nejsou v době testu přítomni. Ale záznamy jako takové nijak neprocházíme.

Trik triků

Největší trik, který nikdy nezklame, je tento. Udělejte uživatelské testování co nejlevnější a co nejjednodušší. Tedy skoro zdarma. A dělejte je furt, za tu cenu si to můžete dovolit.

Uživatelské testování softwaru je možné dělat všemožnými způsoby, ale vždy půjde o jeden princip. Uživateli připravíme co nejvěrněji prostředí, na které je zvyklý a necháme ho dělat práci, kterou běžně dělá nebo by měl dělat. Při tom ho pozorujeme a snažíme se ho co nejmíň vyrušovat. Získané podněty vyhodnocujeme až poté. Cílem je, získat podněty, ne jejich řešení.

Nejlepší by bylo testovat na pracovišti uživatele, to je ale zřídka možné. Minimálně je to nákladnější.

Role

Na uživatelském testování se (u nás) podílí několik důležitých rolí, bývají spojeny.

• Zadavatel vymyslí, co, jak a s kým by se mělo testovat.
• Koordinátorka zajistí testované osoby, vytvoří rozvrh a pozve všechny účastníky.
• Mediátor vede testování a zajišťuje, aby proběhlo optimálně podle zásad vedení testování.
• Hlavní pozorovatel rozumí do detailu zkoumané problematice a komunikuje s testovanou osobou.
• Pozorovatelé test pozorují, většinou vzdáleně, a stejně jako ostatní si dělají poznámky. Po skončení testu se podílejí na jeho vyhodnocení.
• Tester je vždy jen jeden. Plní zadané úkoly a nechá se pozorovat.
• Psychology u nás nemáme.

Poučení pozorovatelů

Účastníci by se měli sejít před samotným testem. Pokud je to pro někoho poprvé, mediátor (povede test, zná techniky a bude hlídat, aby se dodržovaly) jim dá poučení o tom, že cílem testování je získat podněty a ne řešení, že je třeba uživateli vytvořit co nejreálnější prostředí, jako by byl sám (neradit, nenavádět, nepomáhat a to ani souhlasným nebo nesouhlasným pomrukáváním). Pokud pozorovatele něco zaujme, může se zeptat, pokud ho nebude moc rušit. Lépe je se zeptat až na konci, kdy proběhne krátké intrview.

Je třeba předem pozorovatelům zakázat bavit se vzájemně během testu. Je to totiž lákavé nejen najít problém, ale rovnou se podělit o řešení. Proto se to často při testování stává, ovšem moderátor má takové diskuze tlumit už v zárodku. Důvod je ten, že pokud někdo diskutuje, nepozoruje test a navíc ruší ostatní.

Dále je dobré zmínit, že test by měl trvat hodinu a že pokud přesáhne 90 minut, bude ukončen třeba v polovině. Uživatel je po té době unavený a to, co se nestihne otestovat, by se mohlo zahrnout později do samostatného  testu. Je dobré, myslet na dojem, který si testovaná osoba odnese. Jednak o tom bude mluvit s kolegy, ale také se dá očekávat, že ji ještě někdy o účast na testování požádáme. Všem přítomným také vysvětlíme, co mají dělat. Co nejméně rušit svou přítomností a psát si poznámky, kdykoliv je napadne nějaké vylepšení, které by uživateli usnadnilo práci. Někdo si papír a tužku nevezme (to jsou ti optimisté, co si myslí, že si ty dva nápady zapamatují), buďme připraveni. Dále je třeba říct, že s testerem budou mluvit dva lidé: mediátor a hlavní pozorovatel (to je člověk, který většinou připravoval zadání a problematice rozumí).

Před testem je tak třeba připravit počítač, tedy nainstalovat potřebný software, někam umístit soubory, které bude uživatel při práci potřebovat a podobně. Je dobré myslet na to, že před druhým a dalšími testy, bude třeba odstranit to, co tam tester vytvořil nebo modifikoval.

Poučení testera

Konečně přijde tester. Pokud nemá s uživatelským testováním zkušenosti, bude mírně vystresovaný, i když to asi nepřizná. Je třeba mu poděkovat za to, že přišel pomoci zlepšit použitelnost softwaru, který používá nebo možná bude. Pak je nutné ho ujistit, že netestujeme jeho, ale software – že pokud mu něco nepůjde, je to problém softwaru a ne jeho. Za každé jeho selhání budou peskováni vývojáři a problémy odstraní. Dále je dobré zmínit, že se snažíme simulovat jeho pracovní prostředí a ať pracuje, jak je zvyklý. (Hodně lidí tady poznamenává, že nejsou typičtí uživatelé. Nechme je při tom.) My se budeme tvářit, že tady nejsme a nebudeme mu pomáhat. Úkoly má splnit samostatně a po svém. Může používat vše, co má běžně k dospozici, tedy internet, dokumentaci, poznámky, jiný software… A pokud se někde zasekne, může zavolat na podporu. Dále je nutné testera vybídnout, aby komentoval, co dělá, na čím přemýšlí, co ho napadlo a podobně.

Test

Po poučení dáme testerovi vytištěné zadání jeho úkolů. Poznamenáme, že je jednoduché (mělo by být) a že by ho měl zvládnout. Necháme ho zadání si v klidu přečíst, případně mu řekneme další informace. Když začne pracovat na počítači, ujistíme se, že zadání rozumí. Většinou ho řekne vlastními slovy. A většinou začne něco beze slova klikat. I když vidíme, co dělá, je třeba ho rozmluvit, pokud nic neříká, ptát se, co dělá, nad čím přemýšlí… Měl by téměř bez ustání mluvit. Po chvíli si na to zvykne a svou práci komentuje.

Když jde špatnou cestou, necháme ho a pozorujeme, jak a kdy se opraví (nezkušené pozorovatele často svrbí jazyk a když to nevydrží, má je mediátor taktně nebo jakkoliv upozornit). Právě slepé uličky a to, jak se z nich uživatel dostane, je na celém testování to nejpřínosnější (uživatelé si je v reálu také projdou). Když mají pozorovatelé dotaz, měli by si ho nechat na závěrečnou diskuzi. Pokud je krátký nebo by nerušil, je možné se zeptat rovnou. Ale od toho uživatelské testování není. Tester by se měl hlavně soustředit na plnění úkolu.

Tester se občas zasekne a neví, jak dál. Většinou se zeptá na radu. Je třeba mu říct, že my tu běžně nejsme a naopak chceme zjistit, jak to samostatně vyřeší. Většinou na to přijde. Pokud skutečně ne, připomeňne mu možnosti, které má, tedy dokumentaci, internet… a zeptáme se ho, jak by to řešil sám – to pozorovatele samozřejmě zajímá. Když si přesto neví rady, připomeneme mu možnost si zavolat na podporu.

Osvědčilo se naaranžovat k tomuto účelu vedle počítače dětský plastový telefonek (z cukrárny, za sedm korun). Bez něj často není jasné, jestli je podpora stále na telefonu nebo už ne. Také to trochu odlehčí situaci – fakt se tím dovolá. Někdo z pozorovatelů zahraje podporu na druhé straně telefonu.

Tester většinou má po simulovaném zavolání na podporu tendenci jen čekat na radu, když už všichni vidí, co dělal. Je přínosné nechat ho, ať řádně zatelefonuje, zformuluje problém a dostane odpověď, jakou by asi dostal od podpory. Odpovědi z podpory by měly být takové, jako by se od podpory čekaly, stručné a nepřímé. Podpora často neví, kde je problém, jen nabídne, co by se mohlo zkusit.

Zde je důležité zdůraznit, že pokud software nefunguje podle očekávání (padá, funkcionalita se chová jinak, než jsme čekali), testera v tom nenecháme (pokud to nechceme testovat) a problém vyřešíme nebo popíšeme, jak by to mělo být správně. Software by měl být bez chyb, ale uživatelské testování se často dělá na posledních verzích, tedy na alfách a tak se stabilitou to může být na hraně. Nemělo by to ale být pravidlo – ostatně před testem bychom si měli úkol sami splnit, abychom se ujistili, že je vše v pořádku.

Rozhovor po testu

Když tester splnil všechny úkoly, poděkujeme mu za pomoc a měli bychom se ho zeptat na jeho dojmy a připomínky k tomu, jak dobře se mu úkoly plnily, co by si přál v aplikaci změnit… Zde je také prostor klást dotazy, které jednotlivé pozorovatele napadly během testování. Tady už jde o diskuzi, je možné testerovi poradit nějaké triky, které nezná (je to uživatel, bude rád, že přišel). Většinou i z této debaty vzejdou zajímavé podněty.

My se ještě ptáme, jakou známku by tester dal použitelnosti testovaných funkcionalit. Je to zajímavé slyšet, zvláště horší známky jsou argumentem pro to, aby se “něco změnilo”.

Při celém testování i při diskuzi je důležité mít stále na paměti, že tester tady není k tomu, aby hledal řešení problémů. Můžeme se ho zeptat, jaké řešení by očekával, ale pokud neví, nesmíme na něj naléhat. Hledat řešení je naše práce, ne práce uživatelů ani testerů. Je dobré mu to i říct.

Poděkování

Na závěr bychom měli testerovi poděkovat za přínos použitelnosti aplikace, kterou používá. A přínos to je. Také je dobré mu dát za námahu drobný dárek. Prvním účastníkům jsem třeba dával nanuk, a tak když přišli z testování do své pracovny (byli to kolegové), většinou se jich všichni ptali na dojmy a jejich odpověď byla, že to bylo super, že dostali nanuk.

To asi vyplývá z toho, že na taková nezaběhnutá testování lidé chodí s obavami (budou se na mě dívat, dokonce nahrávat a co když se ukáže, že něco neumím…) a na konci to z nich spadne a vlastně si uvědomí, že to nebylo hrozné, nikdo na ně nekřičel… a dokonce dostali dárek.

Po nanucích jsem dával různé pamlsky a když už testování pro většinu kolegů byla stará vesta, přestal jsem s tím. Ale pěkně poděkovat se musí vždy.

A to je celé. Je to dlouhý článek, ale uživatelské testování je jednoduché.