Článek
Proč je to tak velký problém?
Při tvorbě nové funkcionality či celého produktu je nesmírně důležité, abyste věděli, že to, co budete vytvářet, je postaveno na skutečných potřebách vašich uživatelů.
Začněme příběhem. Martin je manažer, který je zodpovědný za rozvoj platformy na prodej lístků do divadla. Martin přijde na schůzku a řekne: „Já často hledám různé starší věci, jako jsou provedené platby či starší články v magazínech apod. Já bych tedy jako uživatel ocenil, kdyby se v naší platformě dalo hledat v historii již odehraných představení. Jak to navrhneme do naší aplikace?“
A nyní otázka pro vás: měl by se hned tým vrhnout na vytvoření nové funkcionality? Nebo bylo v tomto případě něco špatně?
Co když náš manažer Martin sice hledá různé informace v historii, ale dělá to i v tomto případě? Co když náš manažer ani nekupuje lístky přes tuto platformu a jen promítá jeho obecné chování do této aplikace? A i kdyby byl z cílové skupiny, dá se chování jednoho jedince, který je navíc hodně ponořený do problematiky, aplikovat na chování celé cílové skupiny?
A to je právě to, co se nedá říci. Nechci tím tvrdit, že by manažer Martin nemohl mít pravdu. Ale je potřeba ověřit, zda tomu tak opravdu je. Není totiž zcela vhodné považovat naše vlastní předpoklady za obecně platné. To, že já bych jako uživatel něco konkrétního uvítal, neznamená, že to přesně odpovídá chování ostatních vašich uživatelů.
Během vývoje můžete uvažovat nad chováním uživatelů, pochopitelností informací, které sdělujete, businesovým potenciálem nebo funkčností a technickou náročností. Všechny tyto úvahy je ale potřeba chápat jako předpoklady, ne jasně danou pravdu, a podle toho s nimi také pracovat.
Příběh s manažerem Martinem není popisem existujícího projektu, ale popisuje reálné situace.
Předpoklad, příležitost a řešení – jaký je v nich rozdíl?
Předpoklad
Je situace, kdy očekáváte, že něco nějak funguje. Například, že se nějak chovají vaši uživatelé. O předpokladech je vhodné mluvit vždy, když si nejste příliš jistí, že jde opravdu o ověřený fakt. Můžete tedy očekávat/předpokládat, že vaši uživatelé na webu potřebují filtrovat publikované články z blogu dle data. Díky tomu, že toto na schůzce nezazní jako ověřený fakt, ale pouze jako předpoklad, je zde prostor se bavit důležitosti této funkcionality či pravdivosti tohoto předpokladu.
Příklad předpokladu: Uživatelé potřebují vyhledávat již odehraná představení dle data.
Příležitost
O příležitosti mluvíme tehdy, pokud jde již o opravdu ověřenou potřebu našich uživatelů. Víme tedy, že nemluvíme o našem vlastním předpokladu, protože jsme si tuto informaci ověřili přímo u uživatelů při uživatelském výzkumu nebo jde o dříve ověřený předpoklad jiným způsobem.
Příklad příležitosti (uživatel nám sdělil): „Chtěl bych najít představení na kterém jsme byl, abych se podíval kolik stál lístek.“
Řešení
Pokud jde o konkrétní funkcionalitu v aplikaci či webu, mluvíme o řešení. V případě, že na schůzce navrhujeme řešení, ideálně bychom měli vědět, že toto řešení vychází z opravdové příležitosti, která dává pro projekt smysl. Je dobré se neupínat na jediné řešení, které nás napadne, protože mohou existovat jiná řešení pro danou příležitost, která se nakonec mohou ukázat z pohledu podnikání jako lepší. Ať už jde o přínos přímo pro uživatele, pro vaši firmu nebo jsou výhodná s ohledem na jednoduchost vytvoření. Více o tomto tématu se můžete dozvědět zde.
Příklad řešení: Vytvoříme historii představení s filtrem dle data od – do.
Jak pracovat s předpoklady
První sezení týmu se uskutečňuje ještě před samotnou tvorbou. A tady je prostor pro předpoklady k danému tématu. Veškeré předpoklady si zapisujeme na jednotlivé lístečky, abychom s nimi dále mohli pracovat. Nejčastější formou vytváření co největšího množství předpokladů je např. brainstorming.
Lístečky vytvářejte tak, že:
- na každý lísteček dáte jen jeden předpoklad,
- předpoklad by měl být vždy pochopitelným tvrzením, nikdy by neměl být psaný jako otázka,
- snažte se vyhnout heslovitým zadáním jako „potřebují filtr“, ale spíše „uživatelé potřebují najít již odehraná představení dle data“,
- nesnažte se vytvářet debatu nad tím, zda to je správný či špatný předpoklad, sepisujte vše, co tým momentálně napadne.
Předpoklady nejsou pouze to, co uživatelé dělají. Můžeme je dělit do několika skupin dle toho, co předpokládáme a co chceme ověřit.
Základní typy předpokladů
- Disability – přinese to firmě užitek
- Viability – plní to potřebu uživatelů
- Feasibility – umíme to vytvořit
- Usability – umí to uživatelé použít (slouží zejména v případě, kdy chceme již ověřovat použitelnost wireframu či prototypu)
Je přínosné při zapisování předpokladů použít různou barvu lepíků, abyste rovnou věděli, o jaký typ předpokladu se jedná.
Mapa předpokladů
Mapa předpokladů (ang. Assumption mapping) je metoda, jak s předpoklady pracovat a následně je prioritizovat. Tuto metodu můžete použít na úrovni celého produktu, vašich cílů, příležitostí či různých řešení.
Jednotlivé lístečky berete a vkládáte je do grafu.
Na ose X je zobrazeno, jak moc jste si jistí, že je předpoklad pravdivý. Jinak řečeno – máte pro tento předpoklad důkazy, že je pravdivý.
Na ose Y je pak důležitost daného předpokladu. Je zcela v pořádku, že každý lísteček, který berete do ruky, je pro vás důležitý, ale proto je dobré se naučit jejich důležitost porovnávat mezi sebou a podle toho je na ose přesouvat. Díky tomu jste schopni dobře jednotlivé předpoklady prioritizovat. Druhou metodou pro určování důležitosti je řazení na základě vyhodnocení, jak moc vás tento předpoklad ohrožuje, či kolik vám vydělá.
Co jaký kvadrant znamená
Plan (vlevo nahoře)
Jde o důležité věci, které už máme ověřené. Tyto předpoklady se dají rovnou zpracovávat. Měli byste je porovnávat s vaší roadmapou a backlogem. Dá se také říci, že v tomto kvadrantu již nejsou předpoklady, ale pravdivá zjištění (projektové příležitosti).
Evaluace (vpravo nahoře)
Důležité a neznámé. Jde o kvadrant, do kterého bychom měli investovat nejvíce úsilí. Jde o předpoklady, které potřebujeme ověřit. Ověření se provádí za pomocí Value Proposition testing. Jde například o A/B testování, Fake door test či hloubkové rozhovory zaměření na řešení (ang. Solution Interviews).
Defer (vlevo dole)
Tam najdete předpoklady nedůležité a známé. Těm je nejlepší se nevěnovat.
Generate (vpravo dole)
Poslední kvadrant obsahuje předpoklady nedůležité a neznámé. Mohly by ale ukázat něco důležitého. Pokud na to máte čas, a již jste vyřešili kvadrant Evaluace, můžete z nich za pomocí uživatelského výzkumu (nejčastěji hloubkovým rozhovorem, které je zaměřený na pochopení problému, ang. Problem Interviews) vygenerovat nová a zajímavá zjištění.
Předpoklady pro nový produkt
Předpoklady jsou i skvělý nástroj pro validaci informací, které použijete pro ověření vašeho produktu. Pokud používáte Value Proposition Canvas či Business Model Canvas často se zde bavíme o předpokladech či hypotézách. Proto je vhodné na tyto metody navázat právě mapováním předpokladů, abyste si zvalidovali, s jakými typy informací pracujete. Zda je potřebujete více zkoumat či validovat, anebo naopak máte dostatek informací, že jsou to opravdu spíše příležitosti.
Zatímco Value Proposition Canvas slouží pro ověření přínosu pro uživatele, Business Model Canvas nabízí předpoklady pro uživatele, proveditelnost nebo firemní přínos.
Závěr
Bavit se o předpokladech, příležitostech i řešeních je velmi přínosné. A je jedno, jestli tvoříte jen novou funkcionalitu nebo celý nový produkt. Dozvíte se tak, zda máte dostatek informací k tomu, abyste se dokázali rozhodnout, jak správně tvořit.
Předpoklady jsou vhodný nástroj pro všechny důležité fáze. Ať už se bavíte o ověření nápadu na nový produkt, potřebujete dosáhnout nových cílů, hledáte novou příležitost na již existujícím projektu nebo si chcete ověřit funkčnost nějakého vašeho řešení.
Zdroje a zajímavé čtení k tématu
https://www.mural.co/blog/intro-assumptions-mapping
https://www.mural.co/blog/how-to-look-before-you-leap-a-guide-to-mapping-assumptions-for-product-development-teams
https://medium.com/@i.shubhangich/assumption-mapping-5584a7491d9c
https://www.producttalk.org/2011/11/what-product-assumptions-are-you-making/
https://www.strategyzer.com/blog/how-assumptions-mapping-can-focus-your-teams-on-running-experiments-that-matter
https://productfolio.com/assumption-mapping/
https://www.projecttopics.org/tips-on-making-assumptions-in-a-research-paper.html
https://www.toptal.com/designers/ux/experimental-product-design
