Zapojení designéra do vývoje produktu

Cyklus tvorby produkt

Jako designér jsem součástí produktového týmu, takže se o proces tvorby produktu hodně zajímám. Být efektivní – nejen já sám, ale i celý tým – je pro mě totiž opravdu velice důležité.

Shodnou náhod jsem si mohl na ¾ roku vyzkoušet i roli Product Ownera, díky které se můj pohled značně rozšířil a hodně jsem se díky této roli naučil.

Vedle samotného hledání řešení vidím v procesu tvorby produktu 5 klíčových fází, ve kterých mohu týmu výrazně pomoct. Konkrétně:

• Plánování,
• Zamýšlení nad nápady, tzv. Design showcase,
• Testování a experimentování,
• Odhady a přípravy,
• Vývoj.

Proto bych se nad nimi trochu zamyslel a popsal, jakým způsobem se do nich mohu zapojit a proč.

Discovery planning

Začít cokoliv dělat vyžaduje určitý plán a strategii. Vše totiž děláme kvůli tomu, abychom dosáhli konkrétního cíle (například v LMC využíváme tzv. OKR). Vše tedy stavíme na tom, abychom jej dosáhli.

Typicky vše začíná tak, že:

• Zkoumáme problematická místa a hledáme příležitosti ke zlepšení.
• V případě potřeby získáme potřebné informace pomocí dat nebo díky uživatelskému výzkumu.
• Sepíšeme si nápady na řešení, resp. odstranění daných problémů.

A tak dále. Vytvoříme si tak plán, se kterým budeme dále pracovat (dostanu se k tomu později).

Jako designéři bychom měli umět odhalit a vyřešit případné problémy. Nebo umět najít zajímavou příležitost, díky které můžeme hodnotu produktu zvýšit a lidem pomoct s tím, co potřebují.

Každý designér by tedy měl mít ve svém repertoárů potřebné metody, například:

• Rozhovory a testování,
• Analýza dat, včetně mírného Data Miningu a Data Exploration.
• Experimenty a testy.

A když se zapojí přímo do Discovery, může tedy pomoct informace získat mnohem rychleji, vnést dalšího pohled a pomoct prozkoumat více oblastí.

Designér by měl být zároveň skvělý facilitátor a „vymýšleč“ nápadů. Což se v rámci Discovery rozhodně hodí. Může totiž zrealizovat skupinovou seanci, například Brainstorming, díky které získáme hromadu nových nápadů. A ostatním s jejich vymýšlením pomoct.

V LMC jsem podobná sezení už mnohokrát realizoval. Například v rámci poslední schůzky jsme identifikovali 46 potencionálních rizik a problémů, které budeme dále zkoumat a řešit.

Design „showcase“ a explorace

Znal jsem jednoho designéra, který pracoval na zajímavém produktu společně s týmem několika vývojářů. Vždy pracoval na domluveném problému a nějaký čas trávil návrhem řešení.

Mnohokrát se stalo, že své téměř dokončené návrhy ukázal ostatním a ti mu je postupně „rozlámali“, protože měli jasný časový plán a spousta věcí nešla tak rychle a snadno udělat. Takže návrhy musel z velké části přepracovat. Což ho značně ubíjelo a vyčerpávalo, takže po nějaké době z firmy odešel.

Od daných vývojářů jsem slyšel, že za nimi chodil s téměř hotovým návrhem, do kterého je nikdy pořádně nezapojil nebo jim ho neukázal předem. A protože měli omezené možnosti, museli volit postupné a efektivnější řešení.

Podobným situacím se rozhodně snažím vyhnout. Proto jsem už v GoodData do „svých“ týmu zaváděl něco, čemu říkám „Design Showcase“. Což je velice jednoduchý přístup, jak můžeme získat nápady a názory ostatních. A hodně věcí si vyjasnit hned na začátku.

Princip je jednoduchý:

• Na základě Discovery, tedy toho co řešíme a co o daném problému víme, načrtnu během chvilky možná řešení.
• Ty ukáži Product Managerovi a někomu z vývoje. V LMC to je například Lead Engineer.
• Společně probereme možná úskalí, částečně náročnost a přidáme případné kompromisní varianty.

Možná řešení ale nemusím vymýšlet sám. Pokud jde o něco většího a složitějšího, nápady dám dohromady raději rovnou s týmem, například s využitím metody Design Studio nebo Crazy Eights.

Během velice krátké doby tak můžeme získat názor ostatních. A tedy i možná řešení, která zahrnují:

• Pohled na technické možnosti a náročnost výroby.
• Hodnotu pro lidi, pro které to děláme.
• Byznysová očekávání.

V podstatě pak můžeme nápady rovnou vzít a začít s nimi dále pracovat.

Desigh Showcase má tedy několik výhod, například:

• Lidé se zapojí a alespoň částečně získají „ownership“.
• Kolegové budou vědět, co se aktuálně řeší a proč. A mohou se na to v případě potřeby připravit.

Hlavní výhodou ale je, že můžeme snadno porovnat různé varianty. Díky čemuž se může Product Manager lépe rozhodnout, kterou cestou se vydáme. Může totiž lépe porovnat hodnotu pro byznys s cenou výroby a přínosem pro uživatele.

Testování a experimenty

Jak se můžeme snadno a rychle dozvědět, zda naše nápady dávají smysl nebo že hypotézy platí? Nejlepší cestou bude, pokud je hodíme rovnou mezi lidi a získáme zpětnou vazbu.

V té souvislosti mi v hlavě utkvělo tvrzení, které zmínil Ondra Válka při jedné z týmových diskuzí v GoodData:

„Designér by měl návrhy ověřovat, protože neví, že neví“.

Designér by si neměl být svým návrhem tolik jist. Protože:

• Uchopil správně všechny informace?
• Přetavil je do dobrého řešení?

A tak dále. Jistota totiž – vedle dalších věcí – hrozně zkresluje tendenci přijmout fakt, když nebude návrh fungovat.

Pokud tedy chceme zjistit, které nápady a hypotézy dávají smysl, můžeme ve spolupráci s Product Managerem udělat paralelně několik experimentů, pro které můžeme využít například metody:

• A/B a MV testování.
• Wizard of OZ.
• Fakedoor testy.
• Testování použitelnosti.
• MVP.

Primárně jde o to, abychom co nejrychleji zjistili, které z našich hypotéz platí, které ne a ideálně proč. A mohli se tak posunout dál.

V LMC se mi moc líbí spolupráce s Mírou Žebrákem, který podobný přístup uznává. Sice spolu aktivně spolupracujeme až od ledna, ale za tu dobu:

• Celý náš tým udělal již několik testů.
• Plníme jeden z našich kvartálních cílů na více než 100 %.

Míra vše pečlivě hlídá a zapojuje nás. V plánu toho máme opravdu hodně a například příští týden budeme mít několik kol testování jedné poměrně důležité části našeho produktu.

Mě testování a experimenty opravdu hodně baví. A snažím se v nich neustále zlepšovat. Je totiž skvělé se dozvědět, které nápady dávají smysl, které ne a na kterých budeme muset ještě zapracovat, díky čemuž se toho opravdu hodně naučím.

Poznámka: Neříkám, že je potřeba vše testovat před samotnou výrobou. Někdy je to mnohem nákladnější než návrh vyrobit, ověřit jej za chodu a poté případně upravit. Ale i tento přístup beru jako způsob experimentu/testu.

Groomingy a Estimace

Když jsme postupem doby dospěli k zajímavému návrhu řešení, které chce nechat Product Manager vyrobit, je potřeba zjistit náročnost výroby.

Jak jsem se již zmiňoval například v článku Designérovo myšlení je mnohdy to nejdůležitější, nedává mi úplně smysl, aby designér do návrhu zahrnoval náročnost na výrobu. Protože:

• To co umím já, neznamená, že to umí někdo další.
• Co neumím já neznamená, že to neumí někdo další nebo že to vůbec nejde.

A tak dále. Díky čemuž bych mohl velice snadno a zbytečně „zabít“ případnou invenci, do které může chtít někdo zainvestovat. (Naštěstí ale budeme mít více variant díky již zmíněnému Design Showcase.)

Ke správnému odhadu je tedy potřeba někdo kompetentní, což jsou vývojáři. Moc se mi například líbilo, jak jsme to dělali v GoodData:

• Product Manager sepsal User story.
• Jako designér jsem přidal návrhy řešení.
• Vývojáři se na „zadání“ s předstihem podívali.

Společně s Product Manažerem jsme pak návrh User stories představili a začali je s vývojáři do detailu probírat. A pokud bylo potřeba, rovnou jsme se dohodli na nějakém dalším kompromisu.

I přes to, že si na Design Showcase nápady projdeme a získáme názory ostatních, na Groomingu to jde mnohem více do hloubky. Snadno se tedy může stát, že bude potřeba najít rozumný kompromis, abychom co nejrychleji doručili alespoň základní smysluplnou hodnotu.

Proto je pro mě Grooming a Estimace důležitá seance. Jako designér totiž mohu návrhy vysvětlit a začít pomáhat s jejich doručením.

Poznámka: Co jsem zatím zažil, v žádném týmu nikdy nefungoval přístup vymýšlet řešení přímo v rámci sprintu. Vývoj se tím značně zpomalil a i řešení bylo mnohdy méně kvalitní. Proto se mi líbilo, že jsme měli „nagroomováno“ například 3 sprinty dopředu a mohli návrhy podle potřeby upravovat a lépe se rozhodovat.

Pomoc s dodáním

Z vlastní zkušenosti musím říct, že i když vývojářům dodáme sebelepší podklady, stejně bychom radši měli být při vývoji k dispozici a v případě potřeby poradit.

Zažil jsem totiž mnohokrát, že si vývojáři:

• Neproklikají celý prototyp nebo neodhalí všechny stavy.
• Neprojdou si celý flow process diagram nebo screen flow.
• Neprohlédnou všechna rozložení v grafických podkladech.
• Objeví se stavy, na které jsme primárně nemysleli nebo nebyly zcela zřejmé.
• Nezapamatují kompletní návrh, i když jsme jim ho několikrát ukázali.

A tak podobně. Což mnohdy není nutně jejich chyba.

Někdy jde jen o to zkontrolovat, že se na nic nezapomnělo nebo nepřehlédlo. Snadno se ale může stát, i přes velice pečlivou přípravu, že se během vývoje narazí na problém, který výrobu zkomplikuje. Takže aby se vývoj nebrzdil, bude potřeba rychle najít jiné řešení. (Samozřejmě tomu lze předejít i tak, že vývojáři dostanou prostor na analýzu nebo Proof of Concept ještě před samotným vývojem.)

Mnohokrát se nám tedy vyplatilo, že jsme měli k dispozici tabuli, na které jsme s vývojáři probrali možnosti a shodli se na novém řešení, které mohli kluci hned vyrobit a vývoj se tak téměř nezpozdil.

Například v LMC máme pro tyto případy vyhrazeno 20 % času. V GoodData jsem míval kolem 30 % – hlavně z toho důvodu, že jsme se s vývojáři domluvili na otevřenějších zadáních a také proto, že některé věci nebyly tak snadné na vyřešení.

Zapojujte se do tvorby produktu

Design rozhodně není o tom nakreslit, co je zrovna potřeba. Design je o tom, najít efektivní řešení s využitím aktuálních možností. A díky řešení udělat lidi spokojené.

Abyste toho ale byli schopni, měli byste být součástí celého procesu tvorby. A pomoct zbytku týmu dosáhnout cílů, které jste si vytyčili. I za cenu, že budete muset dělat kompromisy.

Pokud budete s týmem spolupracovat, mohu z vlastní zkušenosti říct, že vás budou ostatní mnohem více respektovat. Díky čemuž budete rozhodně efektivnější a výsledky mnohem kvalitnější.