Jak jsme využili Product Discovery pro přípravu nové funkce

Vývoj digitálních produktů se neustále zrychluje a stoupá i tlak na to, zkusit co nejrychleji minimální řešení, které můžeme v případě potřeby neustále zlepšovat. I v LMC se tímto směrem ubíráme a mně osobně to dává velký smysl.

Poměrně nedávno jsme potřebovali vyřešit jeden konkrétní problém, který sliboval nejen větší spokojenost lidi používající naší aplikaci, ale samozřejmě i pomoc s plněním byznys cílů.

Abychom danou věc efektivně vyřešili, využili jsme proces Product Discovery. Díky němu jsme o daném problému zjistili více informací a během chvilky jsme se dohodli na funkčním řešení, které budeme v brzké době vyrábět.

Pojďme to vymyslet

Než dáme cokoliv do výroby, hodně zkoušíme a zjišťujeme. Přeci jen nemáme neomezenou kapacitu a chceme dělat opravdu hodnotné věci.

Hodně nám s tím pomáhá proces Product Discovery, jehož použití se pokusím ilustrovat na jednoduchém a poměrně čerstvém příkladu z LMC.

Nejen z výzkumu a návštěv našich zákazníků víme, že lidé často bohužel neví o tom, co je v aplikaci nového. A mnohdy neví ani o věcech, po kterých se často ptají.

Je škoda a naše velká chyba, že jsme tyto informace lidem nekomunikovali a spíš jim o tom náhodou řekl jejich obchodník.

V rámci jednoho našeho týmu jsme ale potřebovali lidi o novinkách informovat. Když jsme připravovali novou věc, ptali jsme se:

„Jak se lidé dozví, že už je to k dispozici a mohou s tím pracovat?“

Nebylo to zrovna kritické vylepšení, ale něco, na co se lidé často ptali. A když jsme jim funkci v rámci uživatelského výzkumu ukázali, měli z toho poměrně radost – hodí se jim to.

S Mírou Žebrákem, Product Managerem jedné části aplikace, jsme tedy došli k tomu, že potřebujeme o novinkách a změnách informovat, protože:

Chceme mít spokojené zákazníky.
Potřebujeme plnit naše byznys cíle a věříme, že nám s tím novinky pomůžou.

Protože se s Mírou držíme přístupu „žádný sraní”, po krátké diskuzi jsme došli k tomu, že bychom mohli udělat menší experiment a rovnou jsme se dohodli na konkrétním postupu.

Rozjíždíme experiment

Zdá se to jako trivialita a klidně jsme to mohli udělat i bez nějakého bádání. Nemáme ale prostředky na rozhazování, takže jsme chtěli najít nějaký funkční základ, ze kterého bychom vycházeli.

Je potřeba si uvědomit, že pro každý problém lze najít miliardu různých řešení. I v našich diskuzích padlo mnoho nápadů, jak bychom mohli řešení udělat. S Mírou jsme ale nechtěli zbytečně marnit čas, když šlo zatím pouze o experiment.

V aplikaci jsem tedy připravil jednoduchý test. Přidal jsem odkaz na článek se seznamem změn a novinek do aplikace. Konkrétně:

Na hlavní stránku aplikace k boxu Co je nového.
Do patičky, která je stejná napříč aplikací.

Měli jsme tedy dvě varianty a protože byl článek napsaný v češtině, odkazy jsme zobrazili pouze lidem s nastavenou češtinou.

Odkaz na stránku se změnami v aplikaci byl umístěn na úvodní stránce v místě, kde publikujeme novinky a tipy a triky.

Ve druhé variantě byl odkaz umístěn do patičky.

Na nějakou dobu jsme to pustili a čekali, co se bude dít. Chtěli jsme zjistit jaký bude o novinky zájem – zda se lidé na článek vůbec prokliknou.

Překvapení

Jak nám experiment běžel, diskutovali jsme průběžné výsledky. A musím říct, že nás celkem překvapilo, že i tak minimalistická řešení vykazovala poměrně velká čísla.

Lidé na odkaz v patičce klikali téměř 5,4× více než na odkaz na hlavní stránce.

Hlavně varianta s odkazem v patičce nás mile překvapila. Když nás s Mírou tato varianta napadla, nebyli jsme si zcela jistí, zda si odkazu někdo všimne (ale chtěli jsme to zkusit). A ono se to celkem povedlo a ve výsledku měla tato varianta více než 5násobnou proklikovost oproti odkazu na hlavní stránce.

Máme proto několik vysvětlení, například:

Odkaz v patičce byl dostupný z jakékoliv stránky, oproti dostupnosti pouze v úvodní stránky. (Což jsme potvrdili daty z Google Analytics.)
Patička byla vždy jednoduchá pouze s jedním odkazem „Potřebuji pomoct”. Odkaz s vykřičníkem byl něco nového a lidé si toho všimli.

Zaujali jsme tím i ostatní lidi podílející se na vývoji aplikace. Takže jsme se společně sešli nad dalším postupem, například:

Jak a kdy budeme informace publikovat.
V jaké formě informace budou.
Zda budeme informace ukládat i historicky.

Ve hře jsme měli jednoduchá i složitější řešení.

Měli jsme ale ještě par nejasností, například:

Jak budou lidé reagovat na pravidelné novinky.
Jak moc se lidé zajímají o starší změny.

Vedle toho jsme ještě přemýšleli nad jedním řešením, jak bychom o novinkách řekli přímo v aplikaci – co kdyby se v hlavní navigaci rozsvítil nějaký symbol, například zvoneček?

Chtěli jsme zjistit, jak by takové řešení fungovalo. A abychom měli srovnání, jako kontrolní variantu jsme využili variantu s odkazem v patičce (odkaz na hlavní stránce jsme zavrhli jako nefunkční).

Oproti předchozí variantě s odkazem v patičce jsme přidali variantu, kdy se při nových změnách rozsvítí zvoneček v hlavní navigaci.

Po rozkliknutí zvoneček zešedl. Opět se „rozsvítil”, když jsme vypublikovali nový článek.

Připravili jsme tedy další experiment, ve kterém jsme například:

Aktualizovali odkaz na článek a navodili tak pocit automatické aktualizace.
Starší články uchovávali v historii a sledovali, zda se k nim lidé vrátí.

A v aplikaci jsme tedy pustili další experiment.

Budeme vyrábět?

Protože nám experiment běžel docela dlouho a výsledky se nijak zásadně neměnily, navrhl jsem, ať začneme řešit, co dál.

Udělal jsem analýzu nasbíraných čísel a dali jsme si schůzku, na které jsme diskutovali například:

Která varianta dává smysl.
Jakou cestou se vydáme.
Jak budeme informace publikovat.

Rozmýšleli jsme různá automatická a polo-automatická řešení, plnění obsahu, atp. Společně jsme se na základě dat docela snadno shodli na základní variantě, se kterou půjdeme do světa.

Lidé na odkaz pod zvonečkem klikali téměř 2,1× více než na odkaz v patičce.

Vedle vyššího zájmu se nám ale nepotvrdily další hypotézy. Například ta, že se lidé zajímají i o starší novinky, takže vizualizace formou časové osy pro ně bude užitečná. Lidé se totiž na články vraceli:

Poměr nových návštěv u dalších článků klesal a čísla přechodů na další články vyvracela naši hypotézu.

Do experimentu jsme zapojili i menší dotazníkovou studii, abychom prozkoumali očekávaní lidí. I když jsme nenasbírali dostatečně reprezentativní počet odpovědí, čísla se přiklánějí k našim hypotézám. Například:

Protože jsou lidé v aplikaci téměř každý den, nechtějí dostávat novinky do e-mailu.
Z výzkumu víme, že jim podobné zprávy plní schránku a odsouvají důležitější zprávy.
Nemá smysl publikovat informace každý den, ale spíš méně často.

Protože o to máme s Mírou velký zájem, vzal si to Míra na starost do svého týmu a společně řešení vyrobíme. (Samozřejmě budeme stále sbírat zpětnou vazbu a podle toho dále s novinkami pracovat.)

Celé to vypadá jako hrozná věda, ale opak je pravdou. Například:

Protože jsem experimenty řešil pomocí JavaScriptu, jejich příprava zabrala nepatrné množství času.
Během krátkých schůzek jsme se dohodli na poměrně jednoduchém procesu publikace, který po dobu experimentu fungoval.

Nejlepší na tom bylo především to, že:

Jsme nemuseli vůbec nic vyrábět a vývojáři se mohli věnovat důležitějším věcem.
Po dobu experimentu jsme pracovali na dalších věcech. Běžel totiž samostatně a my tak mohli pracovat na dalších vylepšeních.

Díky čemuž jsme tak ušetřili spoustu času a peněz.

Zkoušejte a zjišťujte

Product Discovery je velice mocná technika, jak snadno dosáhnout smysluplných výsledků. Skvělé je z mého pohledu především to, že se můžeme věnovat různým aktivitám naráz.

I když mám jako designér rád dotažená ideální řešení, nerad trávím čas složitou a zdlouhavou přípravou návrhů (zbytečně se v tom pak utopíme). Raději co nejrychleji zkusím a dále iteruji.

Díky tomuto přístupu v LMC ověříme spoustu nápadů. Mnohdy jich spoustu zahodíme, ale i přes to nakonec vyrobíme desítky hodnotných vylepšení, které dávají smysl a přinesou hodnotu lidem, pro které to děláme. A to je to nejdůležitější.