Každý ví, že prototypy je třeba před zahájením vývoje otestovat, aby se zjistily a opravily problémy s použitelností. Mnoho z nich se snaží zavést do svých společností testovací proces. O tom, jak se to děje, je však málo znalostí open source. Rozhodli jsme se to napravit – a v tomto článku se budeme podělit o praktické zkušenosti, které jsme získali při testování prototypů naší vlastní služby UXCrowd a služeb našich klientů
Proč testovat prototypy?
Nejběžnější a očekávanou odpovědí na tuto otázku není v budoucnu plýtvání penězi za opravy rozhraní. Provádění změn rozvržení je jednodušší, rychlejší a levnější než přepisování kódu.
Dalším méně zřejmým úkolem je zkontrolovat, jak uživatelé chápou určitou funkci a zda ji vůbec potřebují. Obvykle je tento problém řešen pomocí rozhovorů – rozhovor však nesimuluje situaci interakce s produktem, takže jeho výsledky jsou spekulativní. Pokud respondenta ponoříte do kontextu, dáte mu skutečný úkol, pak místo spekulativního uvažování obdržíte zpětnou vazbu, na základě které můžete činit informovaná rozhodnutí.
My v UXCrowd často provádíme testy tohoto účel. Byly doby, kdy jsme po testování odmítli implementovat novou funkci, protože se ukázalo, že uživatelé nerozuměli samotné myšlence, kterou jsme chtěli implementovat.
I když nebudete provádět uživatelské testování, může být užitečné vytvořit prototyp s úplným kliknutím, který odhalí konkrétní scénář. Interaktivní prototyp vizualizuje to, co je popsáno slovy ve specifikaci, což často pomáhá odhalit důležité body, které ve specifikaci chyběly. Může se například ukázat, že specifikace zapomněla popsat určité stavy systému nebo jeho reakce na akce uživatelů – a díky interaktivnímu prototypu jsou tyto body zřejmé.
Který nástroj pro přípravu interaktivního prototypu je lepší ?
Stejně jako většina našich klientů používáme dva nástroje: Invision a Figma, z nichž každý má své vlastní výhody a nevýhody.
Figma je pravděpodobně nejčastěji používaným nástrojem. Je oblíbený pro jeho snadné použití, bohatou funkčnost a schopnost spolupracovat. Interaktivní prototypy vytvořené ve Figmě se ale mohou načítat pomalu (30-50 sekund), zejména na starších smartphonech. To je pro respondenty velmi nepříjemné a pokud provádíte nemoderované testování, nemusí respondent jednoduše čekat na nahrání a odejít.
< p>Aby prototypy vytvořené v aplikaci Figma fungovaly rychleji, musíte na jedné stránce Figma mít rozvržení obrazovky pouze pro jednu funkci. Když vyvíjíte složitý systém s mnoha funkcemi, je lákavé uspořádat všechna rozvržení na jednu stránku tak, aby byla před vašimi očima. To je chyba. Takové prototypy jsou příliš těžké a pomalé na načtení a také nepohodlné pro týmový tým. Čím méně obrazovek na jedné stránce Figma, tím lépe.
Chcete-li zvolit nástroj pro vytváření prototypů, musíte pochopit, co budete testovat, proč a jaký druh testu to bude, moderovat nebo ne. Pokud je systém velký a složitý, může být Invision vhodnější, protože funguje rychleji. Ale při testování mobilních prototypů vytvořených v aplikaci Invision mohou nastat problémy s tahy.
Jak připravit prototyp pro testování použitelnosti?
Běžnou chybou při přípravě na testování prototypu je nejprve připravit interaktivní prototyp a poté napsat testovací skript. Po napsání skriptů se ukázalo, že prototyp postrádá obrazovky, potřebné stavy a události nejsou zapsány. Ve výsledku musíte prototyp upravit a vyžaduje to čas.
Správná posloupnost akcí je následující:
- Připravte minimální požadovaný počet statických rozvržení který ilustruje vaši novou funkci.
- Určete cíle testování – záleží na tom, jaké úkoly dáte uživateli a jak interaktivní a podrobný by měl být prototyp.
- Napište testovací skript: formulovat úkoly, které bude uživatel provádět, určit kritéria za jejich úspěch.
- Seznam kroků, kterými uživatel projde při provádění úkolu. Možná má problém několik řešení – toto je třeba vzít v úvahu při vytváření rozložení: chcete otestovat všechna nebo pouze jedno? Ve stejné fázi se musíte rozhodnout, co budete dělat, pokud se uživatel odchýlí od skriptu a klikne „na špatném místě“ – nakreslit obrazovky? Vytvořit útržek?
- Připravit rozložení se všemi kroky a stavy, které jste definovali v předchozím kroku.
- Přidejte do rozvržení realistické texty. Návrháři rozhraní zpravidla kladou důraz na „rybí“ text, který nedává rozložení příliš smysl. Abychom pochopili, jak bude text vypadat v rozhraní, je to dost – ale pro testování to nebude fungovat, protože rozhraní by mělo vypadat realisticky.
- Přidejte znaky klikatelnosti k těm prvkům, které nejsou k dispozici podle skriptu – je nutné, aby vypadali interaktivně. Pokud se tak nestane, uživatel okamžitě uvidí, na které prvky musí kliknout, aby mohl skript předat – a testování tak nemá smysl.
- Zkontrolujte, zda se prototyp zobrazuje adekvátně v různých prohlížečích. Pokud se ukáže, že některý prohlížeč má problémy se zobrazením, instrukce pro respondenta bude muset uvést doporučení k použití prohlížeče, který nemá žádné problémy.
- Proveďte pilotní testování. Je nutné najít ne problémy s použitelností, ale nedostatky v testovacím skriptu a nedostatky v prototypu z hlediska tohoto scénáře. Musíte zkontrolovat, zda jste vzali vše v úvahu: jsou napsány všechny potřebné texty, jsou promyšleny akce systému, jsou poskytnuty odchylky od skriptu atd. Na základě pilotních výsledků musíte dokončit rozvržení nebo skripty – a teprve poté můžete začít testovat.
Jak formulovat úkoly při testování prototypů?
Funkčnost i toho nejpodrobnějšího prototypu je stále omezená, a díky tomu je situace s testováním poněkud libovolná. Proto je velmi důležité ponořit respondenta do kontextu, v němž vznikl úkol, který má být proveden, a tento úkol správně formulovat.
Musíte formulovat úkoly stejným způsobem, jako kdybyste testovali „skutečný“ systém. Častou chybou, se kterou jsme se setkali, je ukázat respondentovi rozložení a požádat ho, aby ohodnotil, nebo ukázat dvě rozložení a zeptat se, který z nich má nejraději. Tímto způsobem nebudete vědět, jestli vaše rozložení obsahuje nějaké problémy s použitelností nebo jak je uživatelsky přívětivé. Musíte požádat respondenta, aby vyřešil stejný úkol, který by v tomto rozhraní vykonával v reálném životě: zaregistrujte se, najděte produkt a vložte jej do košíku, vyplňte profil, najděte informace o podmínkách služby atd.
Pokud testujete funkčnost, která je součástí většího procesu, ukažte respondentovi předchozí kroky. Takže pochopí, jak se dostal na obrazovku, kterou musí otestovat. Měli jsme například klienta, který aktualizoval své služby pro nákup letenek. Potřeboval otestovat nové rozhraní pro fázi výběru a zrušení sedadla v letadle. Pokud bychom respondenta okamžitě nasměrovali na stránku s výběrem místa, situace by se stala zcela libovolnou. Proto jsme k testování této funkce přidali předchozí krok k prototypu: obrazovku, kterou uživatel uvidí po výběru letu a zadání dat. Na této obrazovce respondent stiskl tlačítko „další“ a pokračoval výběrem místa – obnovili jsme tak kontext problému.
Jak se testování prototypů zásadně liší od testování „živého“ systému ?
Z hlediska formulace úkolů neexistují prakticky žádné rozdíly. Je pravda, že před zahájením testování musíte respondentovi sdělit, že testujete prototyp, takže nemusí fungovat všechny funkce, nelze kliknout na všechna tlačítka a odkazy, není vždy možné zadaná data upravit atd.
Opravdu zásadní rozdíly – to je počet respondentů a stanovení metrik použitelnosti.
Při testování prototypů je důležité rychle najít kritické problémy a rychle je opravit. Proto je metodologie RITE (Rapid Iterative Testing and Evaluation) pro tento typ výzkumu velmi vhodná: testujete na 2–3 respondentech, opravujete nalezené problémy, provádíte další iteraci atd., Dokud několik uživatelů za sebou nebude může projít scénářem bez větších obtíží.
„Živý“ systém je obvykle testován za účelem získání komplexních informací o problémech s použitelností: kolik uživatelů se s nimi setká, kolik času stráví prováděním úkolů a jak jsou uživatelé spokojeni se svými interakcemi se systémem. V jedné studii se účastní nejméně 5–8 lidí, přičemž nejprve projdou všemi testovacími sezeními a teprve poté se vyvodí závěry o problémech s použitelností a nezbytných zlepšeních. Metodika RITE se při testování živého systému obvykle nepoužívá.
Na rozdíl od běžného testování použitelnosti při testování prototypů obvykle nezaznamenáváme žádné jiné metriky než úspěšnost úkolu, protože to nedává moc smysl. Jediným případem, kdy potřebujete opravit metriky, je porovnání dvou verzí prototypu a zajímá vás, která z nich je lepší. Jedná se ale o trochu jiný typ výzkumu, který vyžaduje více respondentů a odlišný přístup k plánování.
Lze provést nemoderované testování prototypů?
Je technicky možné provádět nemoderované testování prototypů – a naše služba UXCrowd vám to umožňuje. Tato metoda však není vhodná pro každý produkt.
Nemoderované testy fungují dobře u jednoduchých produktů, kde je počet obrazovek a možných možností minimální – například u vstupních stránek. Při testování vstupní stránky může být respondentovi dáno, aby si tuto stránku přečetl a poté položil otázky, které mu umožní pochopit, jak informacím porozuměl, jaký má vztah k tomuto produktu nebo službě atd.
Bez účasti moderátora také procházejí testy prvního kliknutí. Jsou také skvělé pro testování prototypů, nevyžadují tak složitou přípravu jako klasické testování použitelnosti, ale jejich rozsah použití je velmi omezený. S testem prvního kliknutí nebudete moci prozkoumat celý scénář v prototypu – stačí otestovat hypotézy o tom, co respondent udělá jako první, aby dokončil konkrétní úkol.
Pokud potřebujete otestovat prototyp komplexní služby s velkým počtem funkcí, obrazovek, skriptů, je lepší provést moderovaný průzkum. Může se pokazit příliš mnoho věcí: některé tlačítko nebude stisknuto nebo se stránka nebude posouvat, prototyp se bude načítat pomalu nebo respondent klikne na špatné místo a vstoupí do slepé uličky, která se nebude moci dostat ven. Moderátor pomůže respondentovi vyrovnat se s těmito problémy a stále dostávat potřebné informace. Při nemoderovaném testování v případě takových problémů získáte buď nekvalitní data, nebo je nezískáte vůbec.
Místo závěru: jak implementovat testování prototypů ve vývojovém procesu
Často odmítají testovat prototypy, protože na to není čas: rozložení je již připraveno, specifikace je k dispozici, vývojáři jsou připraveni zahájit implementaci a v aktuálním sprintu (pokud pracujete podle metodiky Agile) se testování určitě nehodí.
Toto je vlastně organizační problém, který musí produktový manažer vyřešit. Jeho úkolem je paralelizovat procesy testování a vývoje: zatímco vývojáři implementují určitou funkci, produktoví analytici a specialisté UX vytvářejí makety, provádějí testování a vytvářejí specifikaci pro další. Na začátku dalšího sprintu pak vývojáři obdrží testované rozložení, ve kterém nebudou zaručeny žádné kritické problémy s použitelností, budou zpracovány hlavní scénáře, stavy a reakce systému – což znamená, že váš systém s každým aktualizace bude pohodlnější a kvalitnější.
Dotazy napište do komentářů, Facebooku nebo UXCrowdu
