Konference UXZ: Jak efektivně testovat? 80 % nápadů musíte zavrhnout
V úterý 14. 6. 2016 proběhl v Praze první ročník konference UX z praxe, která nesla podtitul „konference od uxáků pro uxáky“. Na rozdíl od většiny jiných odborných akcí se na programu neobjevila téměř žádná světoznámá jména či lidé, co jsou sice odborníci na slovo vzatí, ale s jednou případovou studií už vystupovali na třech jiných konferencích. Jak na začátku konference prozradili sami organizátoři, při výběru prezentací do programu vůbec nerozhodovalo jméno speakera. Rozhodující bylo pouze téma a obsah jeho prezentace.
Díky tomu se podařilo sestavit program, který účastníkům přinesl možná méně nablýskaných případovek z veleúspěšných kampaní, ale o to více zkušeností z praxe a tipů, jak se vyhnout chybám, které už v minulosti udělal někdo jiný.
Jednu z těchto praktických přednášek pro účastníky konference připravil Martin Mráz ze společnosti LMC pod názvem „Jak designovat a vyvíjet jen věci, které mají smysl.“ Ocenili ji především ti, kteří se ve své práci potýkají s rozhodováním o tom, které projekty podpořit a dále rozvíjet a které naopak „zatrhnout“ hned na začátku.
Martin Mráz na konferenci UXZ. Autor fotky: BoB (lakave.info)
Martin Mráz pracuje na portálu Prace.cz, která se zaměřuje na zaměstnávání lidí s nižší úrovní vzdělání. Každý měsíc podle jeho slov doručí zaměstnavatelům kolem 150 tisíc odpovědí na jejich životopisy. Vzhledem ke stále klesající míře nezaměstnanosti v ČR ale toto číslo postupně klesá a firmy si stěžují, že mají málo kandidátů na jejich volné pozice. Hlavním úkolem vývojářů Prace.cz je tak motivovat uživatele, aby na inzeráty nejen klikali, ale také odpovídali. Potřebují proto hledat a rychle aplikovat nápady a postupy, které budou fungovat. Vzhledem k poměrně skeptickému přístupu cílové skupiny ale funguje jen máloco.
Model Discovery&Delivery
Při práci s nápady se mu nejvíce osvědčil model „Dual Track Agile“, který se skládá ze dvou linií – Discovery, tedy objevování, a Delivery, tedy doručení. „Podstatou tohoto modelu je, že vy produkujete velké množství nápadů, ale do procesu realizace se dostane pouze málo z nich. Velkou část svých nápadů totiž musíte obětovat, abyste pak mohli dát prostor těm, které mají lepší potenciál a mohou vám něco přinést,“ vysvětlil Mráz.
Zdroj: Prezentace Martina Mráze
Fáze Discovery se tak skládá z neustále se opakujícího cyklu: Příležitost – Hypotézy – Ověřování - Zamítnutí nebo posunutí do vývoje. Tuto práci ale podle něj nemůže dělat jeden člověk: „Na procesu se 95% času podílí UX designer, 80 % času product manager a 30 % času lead ingeneer. A na konci jejich práce jde 80 % nápadů do koše.“
Zdroj: Prezentace Martina Mráze
Prvním krokem je tedy definování příležitosti. „Příležitost je vlastně nějaký problém, který vaše cílová skupina řeší, a vy jim s tím můžete pomoci,“ vysvětlil Mráz. V případě Prace.cz je to tedy nedostatek kandidátů na volná pracovní místa. V druhém kroku je nutno stanovit hypotézu – tedy způsob, jak je možné tento problém vyřešit. V ukázkovém případě je hypotézou předpoklad, že „když zvýšíme počet odpovědí na inzeráty, vyřešíme firmám problém s nedostatkem kandidátů“.
Zdroj: Prezentace Martina Mráze
Podle Mráze je v tomto kroku nutné si uvědomit, že „hypotézy jsou vlastně nápady a žádný nápad není špatný“. Pokud vám samotným už nápady docházejí, nechte jiné, aby je vymysleli za vás. A nemusí to být jen kolegové. Mohou to být klidně uživatelé. Je totiž nutné dokonale znát cílovou skupinu, pro kterou dané řešení vymýšlíte. Není proto od věci dělat průzkumy, rozhovory a dotazníková šetření. V rámci firmy pak Mráz doporučuje používání projektových nástrojů jako je například Trello, do nichž je možné psát jednotlivé nápady a hypotézy, které pak mohou ostatní členové týmu dále upravovat a doplňovat. „Právě psaní je jedna z nejdůležitějších věcí. Pište si všechno a pořád. Jinak to zapomenete.“
V ověřovací fázi je pak nutné odpovědět na základní otázky:
- Jaký je odhadovaný potenciál?
- Za jak dlouho se to dá otestovat?
- Za jak dlouho se to dá vyvinout?
- Jak hypotézy ověřovat?
Existuje základní pravidlo: nezamilovat se do nápadu. Pokud se k němu totiž upnete, bude pro vás mnohem těžší se s ním rozloučit, i když nebude mít požadovaný potenciál. Na hypotézu si prostě nesmíte zvyknout. Pokud ji tedy neověříte aspoň částečně do 2 týdnů, zahoďte ji.
A jak hypotézy testovat? Existuje několik možností.
1) MVP Test
Zdroj: Prezentace Martina Mráze
Nabídnete lidem minimální produkt, který jim něco reálně přinese. „Nemusí to být nijak složité funkce. U nás to bylo třeba obyčejné tlačítko „Kontaktovat telefonicky”. Po kliknutí se zobrazilo telefonní číslo.”
Kdy použít: Když není náročné MVP test postavit a vy potřebujete co nejpřesnější výsledek. Tímto testem nikoho nenaštvete ani neurazíte. Naopak lidem dáte alespoň nějakou část toho, co chtějí.
Kdy ne: Kdyby byla příprava MVP testu příliš časově náročná.
2) Fake Door
Zdroj: Prezentace Martina Mráze
Díky této metodě můžete zjistit zájem vašich zákazníků o určitý produkt nebo službu, aniž by byly v tu chvíli skutečně dostupné. Například v případě Prace.cz šlo o tlačítko umožňující odpověď na inzerát jedním kliknutím. Po kliknutí na tlačítko se ale objeví upozornění, že funkce nebo produkt zatím neexistuje. Zároveň ale musíte dát uživatelům vhodnou textací vědět, že jakmile bude produkt dostupný, vy jim dáte vědět.
Kdy použít: Tato metoda je vhodná při testování nové služby nebo funkce, jejíž zavedení by bylo nákladné, ale vy vlastně ještě nevíte, jak přesně by měla vypadat a fungovat. Mnohdy to vlastně ani vědět nepotřebujete, protože zjistíte, že o danou službu není zájem.
Kdy ne: Když chcete testovat na více lidech – hrozí, že je naštvete. V tomto případě totiž uživatelé něco chtějí a vy jim to nedáte. Nepoužívejte tuto variantu ani ve chvíli, kdy už je jen krůček k MVP testu – díky MVP testu můžete dát lidem nějakou reálnou hodnotu.
3) 404 test
Zdroj: Prezentace Martina Mráze
Po kliknutí na tlačítko ukážete lidem stránku 404. Tento test má ale velkou nevýhodu - zjistíte sice, jestli lidé mají o danou věc zájem, ale na druhou stranu je pravděpodobně dost naštvete.
4) Wizard of OZ
Zdroj: Prezentace Martina Mráze
Zdánlivě vše funguje automaticky, ale na druhé straně sedí člověk, který danou věc řeší. „Mám rád příklad nejmenovaného e-shopu s obuví. Nafotili boty, vystavili je na webu, po několika dnech sebrali objednávky, došli do obchodu, nakoupili boty, zabalili a poslali. Díky tomu vlastně zjistili, že online nakupování bot má v jejich případě potenciál, aniž by je to stálo nějaké náklady na zásoby atd.“
Kdy použít: Tato metoda je vhodná, pokud máte nápad a věříte, že bude fungovat. Nevýhodou ale je, že ho lze testovat jen na malém množství uživatelů.
5) Další metody
Využít můžete samozřejmě také A/B test, uživatelské testování, concierge test, průzkum, datovou analýzu a další.
Na konci ověřovací fáze byste měli znát následující:
- Potenciál, co vám to přinese – ideálně vyjádřený v číslech
- Víte, že vám to neohrozí nic jiného
- Pohlídejte si, že rozumíte výsledku – nestačí znát jen výsledek, je nutné odhalit i jeho příčiny
Při testování doporučuje Mráz používat kombinaci více nástrojů a nespoléhat se jen na jeden oblíbený program. „Nám se osvědčila kombinace Visual Website Optimizeru s Google Analytics. Ale pozor – v jednu chvíli dělejte jen jeden test na stránce. Pokud běží dva testy na jedné stránce zároveň, může to zkreslovat výsledky."
Poslední fází procesu pak je zamítnutí, nebo posunutí nápadu do vývoje. Zde je nutné zvážit:
- Potenciál – zda se vyplatí investovat do vývoje
- Zda se nevyplatí vyvinout něco jiného – například dva jednodušší nápady, jejichž společný výsledek bude stejný jako u toho jednoho složitějšího
- Dosáhnu tím toho, co chci? Je dobré mít kontrolní metriku - například 10 % odpovědí navíc
Testování a ověřování hypotéz by se podle Mráze mělo stát běžnou součástí vývojového procesu ve firmě. „Hlavním přínosem pro nás bylo, že jsme se přestali hádat. Mnoho předem ztracených diskuzí teď můžeme utnout slovy: otestujeme a uvidíme. Díky zkoumání příčin u výsledků testů navíc víme nejen, co funguje, ale i proč to funguje,“ uzavřel přednášku Mráz.
