Na podzim jsem tu psal o konferenci Mind the Product v Londýně a teď na jaře dali lidé od MtP dohromady i sadu workshopů. Jelikož jsem koncem loňského roku hltal stránky Google Ventures, kde o design sprintech (DS) vydali sérii blog postů, informace, že na stejné téma je i workshop mě do města doubledeckerů přitáhla znova.
Jednodenní workshop byl vlastně simulací celého procesu, který typicky trvá celý pracovní týden. Vedl ho C. Todd Lombardo, spoluautor kuchařky jménem Design Sprint, a byl to teda fičák. Delší text je pokusem o syntézu workshopu a doporučení z Googlu, který už mimochodem taky o DS vydal knihu The Sprint. Mno, je toho dost.
Adam minule popsal, jak levně a rychle testovat nápady. DS se s tím, podle mě, skvěle doplňuje. Máte přímo nápad na produkt, řešení problému nebo i jen vidíte někde nějaký uživatelský či společenský problém, který (si myslíte) stojí za to vyřešit? DS je rapidní týmová metoda, jak během týdne zásadně zvýšit šanci, že identifikujete problém, který lidi opravdu palí, navrhnete skvělé řešení a ve finále ověříte, že ho lidé umějí a chtějí použít, a jsou za něj ochotní zaplatit. A ještě k tomu nakopnete týmovou spolupráci.
Life is too short to build something nobody wants. (Ash Maurya)
Jak už to tak s nápady chodí, ve většině případů vám DS spíš ušetří čas a zdroje vyhozené za bezhlavé realizování geniálního nápadu, který se během DS ukáže být koninou. Příklad epického failu, který by prý DS rychle odhalil, uvedl Todd službu Airtime od Seana Parkera.
Základem design sprintů je timeboxing. Discovery potřebuje dostatečný čas ale ne víc, pak totiž začnete jít v některých aspektech do větší hloubky než je nutné a zamilujete se do nápadu. Vygenerovat, zpracovat a ověřit nápady by mělo jít v daném čase, jinak je někde něco špatně. Jelikož se celý proces odehraje během pracovního týdne, i aktivity v jednotlivých dnech by měly mít jasnou délku, aby celý proces odsýpal. Mrkněte na příklad načasování.
Obecně je radno dělat DS v dostatečně pestré skupině, aby v ní byla tzv. svatá trojice skillů, tj. produkt, technologie, UX ale ideálně i klíčový stakeholder nebo další užitečný skill jako data analyst či markeťák. Ideální velikost skupiny se pohybuje kolem 4-8 lidí, větší už může být těžké uřídit. To má za úkol facilitátor, který se do samotného sprintu nezapojuje. Dle Todda ne všichni participanti (např. stakeholdeři) musí být přítomni po celou dobu, určitě ale první a poslední den, tj. kdy se vše vykopne a vyhodnotí.
Good practice je předem si odsouhlasit pravidla. Na workshopu to šlo tak, že Todd jich několik nastřelil na flipchart a pak se ptal skupiny na další (padlo třeba „žádný facebook a email”), které na něj připsal. Výsledkem byla pravidla stále na očích, na která se dalo během workshopu odkazovat. Mimochodem Todd workshop nakopnul i efektivními ice breakery – “high-five everybody in the room in 60 seconds”, kde se každý hned rozeběhl, ale poté i sofistikovanější “make everybody happy”, což následoval moment ticha a pak série nápadů. Todd tím zároveň demonstroval, že u DS je nutné si prožít tři fáze: WTF? – Think – Test.
Google radí udělat si stabilní „war room”, kde máte k dispozici spoustu stěn na psaní a polepování a který je zároveň dostatečně mimo vaše denodenní prostředí, aby vás něco či někdo z DS nevytrhával. Co do něj vzít? Post-ity, fixy, nástěnky, flipy, “dot stickers”, A4 papíry, časovač a hlavně jídlo 🙂 Kdyžtak tady je jejich shopping list.
První den je vaším cílem hlavně se zaměřit na tu správnou příležitost či problém a dobře ho v rámci týmu pochopit. V Google doporučují zvolit si nějaký velký, zajímavý, který vypadá ambiciozně, ale dosažitelně. Pokud už nějaké nápady máte, nasdílejte si v týmu, co už o nich víte, a slaďte hladinu porozumění. Typicky produkťák přijde s příležitostí (vč. analýzy trhu) a v týmu udělá „pitch“.
Na workshopu pro odpíchnutí máme každý nakreslit jednu oblíbenou appku a jedno svoje hobby. Pak se náhodně vybere z každé jedno a výsledný mix je naše oblast příležitosti. Pro můj tým to je “Pocket for theatre lovers”. Na první pohled fakt blbost (WTF?), začne po chvilce brainstormu (Think) dostávat reálné obrysy. Jako další po nás Todd chce sepsat naše „hopes and fears”, které k příležitosti pociťujeme. Každý za sebe přichází s tím samým – strach, že to, co vnímáme jako příležitost, není reálná potřeba lidí. Cítíme potřebu to velmi rychle ověřit (Test).
Pro vnitřní sebereflexi máme dále sepsat fakta (co víme), domněnky (co si myslíme, že víme) a otázky (co bychom rádi věděli). Po rozřazení domněnek (na ty je hlavní pozornost) do kvadrantů dle jejich důležitosti a našeho pocitu jistoty se zaměřujeme na typy uživatelů v této oblasti. Kdo jsou a co dnes dělají, když jejich problém (si myslíme, že víme) ještě není adekvátně vyřešen. Zde malá odbočka – na zmapování určitě doporučuju přečíst knihu User Story Mapping. Zmapujte jednotlivé fáze a identifikujte v cestě hlavní bolístky uživatelů a konkrétní příležitosti, co zlepšit. Zaměřujeme se na „milovníky divadla” a „markeťáky divadel”. Na druhou skupinu při workshopu nezbyde čas, ale domníváme se, že když jim budeme generovat traffic, tak nám rádi zaplatí (v reálu určitě alfa a omega).
Následuje formální definování nejpalčivějšího problému: Nastřelujeme, že „divadelní nadšenci nemají jedno místo, kde by mohli objevit skvělá nová představení, když mají zrovna čas”. Záhy přichází typický prvek DS – přeformulujte problém! Iterování je v DS klíčové, jednotlivá „cvičení” se jedou víckrat. Cílem je jiný úhel pohledu a snaha nějak se poučit a nápady vyladit.
Obuvnická firma vyšle do Indie dva obchodníky, kteří mají zhodnotit místní obchodní přiležitosti firmy.Jeden se vrátí a tvrdí: „Není tam žádná příležitost, všichni tam chodí bosí!” Druhý se vrátí a tvrdí: „Je tam obrovská příležitost, všichni tam chodí bosí!”.
Díky přeformulování problému si uvědomíme, že klíčový je i různorodý vkus. A ejhle! Najednou máme problém, který nám dává smysl. Teď už ho „jen” vyřešit.
Pozn. Google ještě na konec prvního dne radí – dejte do kupy kritéria pro výběr participantů na testování na DEN 5.
Druhou fází DS je generování co největšího množství řešení. Individuálně máme za úkol problém vyjádřit pomocí Job stories a tím víc kontextualizovat problém a cíle uživatele. Pak přichází maso jménem six-up: Každý máme během 5 minut nakreslit 6 různých řešení. Proč kreslit a proč tolik řešení tak rychle? Vizualizace nutí ke srozumitelnosti a rychlost je skvělá pro odbourání mentálních bariér (vnitřní kritiky). S každou iterací se zjasňuje přemýšlení a ladí řešení. Pro mě osobně se spíš poskládalo 6 fíčur jednoho celkového řešení. Následuje poskládání řešení do storyboardu, který má 3 kroky – začátek, střed a konec. Na závěr druhého dne Google nabádá domluvit pohovory na DEN 5.
Cílem třetího dne je destilace nejlepšího řešení. Storyboardy z předchozí fáze máme nejprve ve skupinkách 2×3 přetavit ve dva lepší. Následuje přiřazení kroků storyboardů k domněnkám. Tzn. které domněnky jsou natolik klíčové (tj. důležité a zároveň nejisté) pro naše storyboardy, že musí být otestovány. Když nemáte čas otestovat vše, každý v týmu podle sebe mezi domněnky rozdělí virtuálních $100. U nás dolarově vítězí, že divadelní nadšenci ocení doporučování a použijí digitální produkt (máme pochybnosti, jak moc jsou „tech-savvy”). Na tabuli tak vedle domněnek přibydou i sloupce „test by” a „valid if”. A pak hurá na „team sketching” – ve 2×3 lidech kreslíme řešení a do sloupců pak zapíšeme, jak domněnky otestujeme (koupí si skrz nás lístky, dají nám email apod.) a jak poznáme, že (ne)platí.
Nakonec se celý tým sladí do jednoho „vítěžného” návrhu řešení (něco jako divadelní Discover weekly á la Spotify). Pokud není jasný favorit, může se zde postupovat např. tichým hlasováním pomocí „dot stickers”. Na závěr dne ještě Google radí potvrdit participanty na testování (nějací odpadnou, máte tak čas najít další). Jo a oslavte skvělou práci!
Nástává čas prototypování. Jeho zásadní význam Todd popsal na tzv. Spaghetti marshmallow challenge. Ve hře jsou prý mnohem lepší děti, protože pořád dávají marshmallow na vrchol, čímž testují celkovou robustnost věže. Přeloženo: čím dřív získáte reálný feedback, tím líp.
Proto je důležité mít vždy vizuální prototyp. Stačí “low-fidelity”, tj. nic sofistikovaného (v jednoduchosti je krása), v Google doporučují používat i třeba powerpoint. Hlavní je aby uživatel pochopil a zažil, jak to celé bude fungovat a vypadat. Tím dostanete autentickou zpětnou vazbu.
Poslední den by měl být „uncomfortably exciting”. Konečně ukážeme vynález světu! Nejdřív to chce ale vědět na co se ptát. Google radí začít od konce – při testování chcete získat konkrétní seznam věcí, jak prototyp vylepšit, na to zaměřte scénář a otázky. Todd ještě přípomínal, že máme 2 uši a jednu pusu – užívat v tomto poměru. Testování (na člověku z jiné skupiny workshopu) ukázalo, že náš prototyp byl vlivem šibeničního času skutečně hodně nabastlen, ale hned první dojmy našeho participanta toto odhalily. Ukázání mu více variant nás nasměrovalo dál. Mimochodem v Google radí, neopravujte prototyp hned po prvním testu, druhý totiž může být ok. U testování mějte ideálně celý tým a když máte otestováno, sedněte se všemi nad tím, co fungovalo, co ne a co to celé znamená pro další vývoj.
Po DS obvykle následuje buď další iterace, tj. zlepšení a testování prototypu s cílem vytvoření řešení, které stojí za to poslat do výroby (např. klasického SCRUM sprintu). Může ale také dojít k zahození celého problému a vykopnutí nového DS. Možná se zklamáním ale také s úlevou, že jsme se nepustili do něčeho, co vlastně nikdo nechce. Na závěr Todd doporučil kombinovat DS s Business Model nebo Value Proposition Canvas.
Mě osobně DS hodně inspiroval jako rychlá a levná metoda generující spoustu nápadů, které četnými iteracemi vybrousí do jasného řešení a přitom skvěle stmelí tým. Do DS je už ale dobré znát metody otestování a prototypování. S tím však facilitiátor může pomoct. S čím si ale lámu hlavu je, jak si na něj najít čas, když mně i týmu paralelně běží denní operativa? Todd to prý řeší režimem 10-16, tj. před 10. a po 16. hodině je čas na operativu, mezitím DS. Možná vás ale napadne – jak to celé prosadit do firmy? Todd doporučil prezentovat výstupy z DS managementu, tzn. odhad „kolik peněz a času jsme ušetřili tím, že jsme zabili tento nápad” a tím ukázat přínos DS pro široké využití ve firmě. Zkuste to vždy vyčíslit, budou vás víc poslouchat. A na první DS je zkušený facilitátor silně doporučen.
Máte zkušenost s design sprinty? Jak to (ne)šlo? Nebo chcete s DS začít? Co si od nich slibujete, čeho se obáváte? Napište v komentářích.
Cover je z Pexels, slidy ze Speakerdecku, přehled fází DS ze Zenexmachina a marshmallow z Bakadesuyo.
Petr Lamač