Článek
Většinou je první nápad jen málokdy ten nejlepší, proto je ideální vymyslet pro každou příležitost 15 až 20 nápadů na její řešení. Můžeme na ně přicházet pomocí brainstormingu, super nabité ideace či dalších metod, které slouží k tvorbě nápadů. U některých nápadů není nutné mít originální řešení, ale ve strategických problémech jsou to právě originální nápady, které nás odlišují od konkurentů. Je dobré si proto neklást žádná omezení a klidně brát v úvahu i různé šílené a na první pohled nereálné nápady – ty totiž mohou vést k těm reálným.
Hodnocení nápadů je dalším krokem. Nejprve je nutné vyřadit ty nápady, které konkrétní příležitost neřeší. To je přirozená součást brainstormingu a je nutno je vyřadit až v tomto kroku. Následuje hlasování například pomocí teček, kde volí každý člen týmu nápady, které mu přijdou dobré. Každý člen má například tři bodíky, které může libovolně použít. Cílem je dostat se na tři nápady. Jediným kritériem při volbě je to, aby daný nápad dobře řešil konkrétní příležitost. Není dobré hlasovat pro nejzářivější či nejoriginálnější nápady, které k vyřešení příležitosti žádným způsobem nepřispějí. Členové týmu mohou všechny tři své body dát na jeden nápad, ale i rozložit si je mezi několik nápadů. Toto můžete opakovat tolikrát, dokud se nevyberou jen tři nápady.
Při ideačním procesu je dobré se vyhnout několika chybám. Jednou z nich je začlenění stakeholderů jen z jednoho oddělení, například designérů, a opomínání pracovníků zákaznické podpory, vedení produktu či vývojáře. Druhou velkou chybou je generování příliš mnoho variací jednoho nápadu. Naším cílem je generování co nejvíce různorodých nápadů. Třetí chybou je výběr nápadů, které nenapomáhají konkrétní příležitosti. Takové nápady je nutné vyřadit ještě před hlasováním.
Identifikace skrytých předpokladů
Většina nápadů je stále poměrně vágní, a proto je nutné před jejich vyhodnocováním projít jejich detaily. To je vhodné například pomocí tvz. story mapping, kde se mapuje každý krok, kterým musí uživatel projít, aby získal z produktu či služby hodnotu.
- Prvním krokem je představit si již hotové řešení. Nesoustředíme se nyní na budování řešení, ale na to, že je již hotové a zákazník jím prochází.
- Následuje identifikace klíčových stran. Kdo s kým musí interagovat na to, aby byl produkt funkční? Například u sociálních sítí jsou to minimálně dva lidé, kteří si píší či dělají jiné činnosti. Na jiném místě to může být prodejce či kupující. Případně i člověk a software (příkladem je konverzace s chatbotem).
- Dalším krokem je mapování konkrétních kroků, kterými musí obě strany projít, aby získaly z řešení hodnotu. Tady je důležité být co nejvíce specifický.
- Seřazení kroků v čase je posledním krokem. Je důležité, aby kroky šly za sebou tak, jak se i ve skutečnosti dějí. Volitelné kroky se rovněž umisťují tam, kde se dějí. Vždy se zde mapuje úspěšná cesta, ne ty neúspěšné. Zároveň je potřeba zobrazit všechny úspěšné cesty. Příklad story mappingu (nalevo jsou zobrazeny klíčové strany, v mapě následně kroky, které se musí udat):
K samotným řešením je vhodné napsat předpoklady, které o nich máme. Přicházíme na ně díky jednotlivým krokům ve story mappingu, kdy si ke každému kroku sepíšeme předpoklady o tom, jak se bude daný uživatel v konkrétní situaci chovat. Tyto předpoklady vycházejí z našich minulých zkušeností, výzkumů a znalostí o trhu či zákaznících. Následně je hodnotíme podle těchto kategorií:
- Žádoucnost – chce někdo toto řešení? Získají z něj zákazníci hodnotu?
- Životaschopnost – měli bychom to vybudovat? Je řešení vhodné pro náš byznys? Řešení by mělo vytvářet více výnosu než to, co jsme vynaložili na jeho vybudování, obsluhu a uchovávání.
- Proveditelnost – můžeme to vybudovat? Zde bereme v úvahu technickou proveditelnost či jiné oblasti (právnická, bezpečnostní, kulturní, společenská…).
- Použitelnost – je to použitelné? Umí zákazníci najít to, co potřebují? Budou chápat, jak mají řešení použít?
- Etičnost – vznikne kvůli řešení nějaká škoda? Je například uchovávání dat tímto způsobem v pořádku?
Vždy je nutné zamyslet se i nad etickými předpoklady, na ty totiž mnoho týmů zapomíná. Můžeme se například zaměřit na otázky typu: jaká data plánujeme sbírat? Jak budou zákazníci rozumět sběru dat? Budeme poskytovat data třetím stranám? Může náš produkt způsobovat závislost? Vynecháváme nějaké skupiny lidí? Jak náš produkt mohou zneužít internetoví trollové? Může toto řešení ohrozit naši reputaci? Je vhodné si vyspecifikovat různé otázky a následně si na ně odpovědět.
Dalším způsobem, jak můžeme generovat předpoklady, je tzv. pre-mortem. Ty se vždy dělají na začátku projektu a nutí nás tvořit předpoklady o tom, co se může na projektu pokazit. Vhodná otázka, kterou takový proces začínáme, je: „Zkus si představit, že uplynulo 6 měsíců, produkt jsme spustili a jde (ne může jít!) o totální propadák. Co se pokazilo?“ Díky této otázce začneme tvořit předpoklady.
Třetím možným způsobem tvorby předpokladů je opět použít Opportunity Solutions Tree, ale postupovat od konce. Začínáme tedy tak, že si vezmeme řešení a snažíme se odpovědět na to, jak řeší konkrétní příležitost cíl, který jsme si zvolili. Je vhodné vymyslet několik předpokladů pro každý uzel v cestě.
Prioritizace předpokladů
Následuje prioritizace předpokladů. K tomu můžeme použít mapu, kde je třídíme podle jejich důležitosti (vzhledem k úspěchu daného řešení) a podle toho, jaké máme důkazy pro jejich potvrzení či vyvrácení. Takto mapujeme všechny předpoklady vzhledem k sobě navzájem – lze jejich polohu upravovat. Následně se zaměřujeme na předpoklady, které skončily v pravém horním kvadrantu – jsou důležité, ale neznámé.
Tento postup – od story mappingu, přes generování předpokladů až po mapu předpokladů – děláme pro každé ze tří řešení, která jsme si v předchozím procesu spolu s týmem zvolili. Potom už následuje testování samotných předpokladů.
Testování předpokladů, ne nápadů
Vždy je nutné testovat předpoklady ze všech tří příležitostí najednou. Díky tomu předejdeme tomu, abychom věnovali příliš mnoho času nápadu, který se nám líbí nejvíce a hledali pro něj potvrzující důkazy místo toho, abychom byli objektivní vůči všem třem vybraným nápadům.
Soustředíme se na předpoklady, pro které máme nedostatečné důkazy. Naším cílem je posunout tyto předpoklady z pravého (neznámého) kvadrantu do levého (známého).
Při testování předpokladů je důležité snažit se nasimulovat situaci, díky které si s uživatelem předpoklad ověříme. Je důležité si definovat a následně se při testu soustředit na moment, kterým předpoklad ověříme. Díky tomu se budeme moci rychle přesouvat od jednoho testu k druhému (například když chceme zjistit, jakým způsobem se rozhoduje, na co bude dívat na Netflixu, tak mu poskytnout Home Page Netflixu spolu s různými možnostmi a pozorovat, jak se bude uživatel chovat). Začneme tedy definováním momentu, který chceme otestovat, a následně se snažíme vymyslet simulovanou situaci, kterou na závěr vyzkoušíme s uživatelem.
Ještě před samotným testem je ale nutné se domluvit na tom, co znamená to, že předpoklad je správný – přesně si to definovat. Například „z 10 lidí si 4 vyberou sportovní kanál“ (je nutné si stanovit počet testů, které uděláme a počet lidí, kteří vykonají určitou činnost). To nám pomůže shodnout se jako tým na tom, co je úspěšný test a zároveň předejdeme confirmation bias, kdy si budeme zpětně odůvodňovat, co je ještě úspěšný test a co už ne. Neexistuje žádný správný počet, cílem je získat co největší množství informací s co nejmenším počtem uživatelů.
Neúspěšným testům můžeme předcházet tak, že budeme klást větší důraz už na rekrutaci uživatelů – stanovíme, jaké na ně máme požadavky, a budeme se snažit získat široké spektrum (například napříč pohlavími, generacemi či lokacemi). Vždy by nám mělo být jasné, proč byl některý z testů neúspěšný – není-li, měli bychom důvod neúspěšnosti testu zjistit. Je také vhodné otestovat náš předpoklad pomocí různých výzkumných metod (například prototyp při testu použitelnosti, ale i rozhovor prostřednictvím otázek na minulé zkušenosti respondentů). Tento proces se nazývá triangulace.
Takto postupně otestujeme všechny předpoklady, nacházející se v pravém horním kvadrantu (ty, které jsou neznámé, ale důležité). Nestačí si otestovat jeden předpoklad, a tím skončit – musíme si projít všemi.
Nejčastější chyby při testování předpokladů:
- extrémně komplexní simulace – cílem je provést rychlé testování, ne strávit týdny nad jedním předpokladem,
- používání procent místo specifických čísel při stanovení úspěšnosti testu,
- nedostatečné definování evaluačních kritérií – kromě počtu respondentů a počtu úspěšných uživatelů si můžeme definovat v testu i další kroky (například kolik uživatelů si zobrazí web, kolik z nich klikne na CTA tlačítko, kolik úspěšně vybere produkt…),
- testování se špatnou skupinou uživatelů,
- designování pro nejhorší scénář – v prvním kole například pro skupinu uživatelů, která je cílovou skupinou a pravděpodobně i nejsnáze testem projde. I zde se už totiž může stát, že skupina testem neprojde a ke složitější cílovce se ani nedostaneme.
Tímto procesem přijdeme na to, které řešení je pro danou příležitost nejvhodnější a to můžeme posunout dále do vývojového procesu. Díky tomu, že si dáme záležet na výběru správného řešení, předejdeme tomu, že budeme zbytečně dlouho a draze vyvíjet produkt či funkcionalitu, která v konečném důsledku nenaplní očekávání našich uživatelů. Naopak, bude odpovědí na jejich problémy, touhy a potřeby.
Zdroje:
Teresa Torres – Continuous Discovery Habits
