Bylo to jen jedno z našich dalších setkání s uživateli. Nedávno jsme dokončili nový produkt a uživatelé s ním již nějaký čas pracovali. Na tomhle setkání nám měli sdělit své zážitky, připomínky a nápady na zlepšení, které jsme s radostí sesbírali. Jedním z těchto nápadů byla možnost vidět v aplikaci statistiky. Tento nový produkt totiž obsahoval seznam reklamních pozic, tzv. děr na stránce, ve kterých se může zobrazit reklama. Na seznamu reklamních pozic by tak bylo možné vidět například to, kolik reklam se zobrazilo v jednotlivých pozicích. Tato data jsou aktuálně k dispozici v reportingovém systému, který obsahuje čísla ze všech našich produktů. Nicméně z pohledu uživatelů by bylo dobré mít statistiky právě na zmíněném seznamu pozic.
Veškerou zpětnou vazbu jsme si jako obvykle zdokumentovali a následně požadavky postupně implementovali. Jako kritéria výběru jsme používali například to, jak často se připomínky opakovaly, jak dlouho se na ně čekalo, jak nám připadaly užitečné a nebo jak jednoduché to dle nás bylo. A jelikož se podobný požadavek opakoval i na dalších setkáních, rozhodli jsme se jejich přání splnit.
Celá záležitost vypadala na první pohled jednoduše – rozšíříme již existující seznam reklamních pozic o pár statistik. Řekli jsme si, že už vlastně máme starší produkt, který je na reportingový systém napojený, takže získávání těchto statistik a jejich zobrazování v našich produktech nebude žádná neznámá. Tím pádem uživatelé uvidí vysněná čísla a u nás to bude za hubičku. Jasná win-win situace. Rozjeli jsme tak náš analyticko-designový vlak s cílem dodat do systému statistiky. Při diskuzi se nicméně objevila otázka “Proč vůbec ty statistiky chtějí vidět? Co tím řeší za problém?”
Najít odpovědi na takové otázky pro nás nebylo těžké, protože jsme měli bohaté zkušenosti se statistikami a reportovacími systémy. Zároveň jsme měli po ruce náš Customer Care tým, který je v podstatě také uživatel, který se setkává s podobnými záležitostmi na denní bázi. Společně jsme si tak odpovídali na již položené otázky a zároveň pokládali nové: “Proč uživatel ty statistiky potřebuje?” Pokud tyto statistiky používají k monitorování výkonu reklamních pozic, nepomohou jim zároveň informace o tom, jak tomu bylo například před týdnem? Nepomohou zde spíše trendy? Například zda dochází k nárůstu či poklesu zobrazených reklam oproti minulému týdnu. A pokud tedy sleduje trendy, můžeme nějak z historických dat vydolovat informace o tom, v jakém rozpětí se výkon reklamní pozice obvykle pohybuje? Pak by v grafu uživatel jasně viděl to, zda se aktuální výkon pohybuje v obvyklých mezích a pokud ne, tak na vzniklou situaci může hned reagovat. Mezi těmi všemi otázkami náš analyticko-designový vlak nabíral rychlost, ale nikdo si nevšiml, že na špatné koleji. Ale o tom až dále.
Společnými silami jsme si tak vytvořili jasnou představu o tom, jakým problémům uživatelé čelí a jaký je nejlepší způsob tyto problémy vyřešit. Celé tohle společné snažení vyústilo v tento krásný graf níže. Není nádherný?
Nad tímto “mistrovským” dílem jsme několikrát iterovali. Předcházelo mu hned několik prototypů, které jsme diskutovali na mnoho schůzkách s kolegy z různých oddělení. Mezi sebou jsme se plácali po ramenech, přeci jen se nám podařilo návrh doslova vypiplat do dokonalé formy, kterým uživatele doslova oslníme. A pro jistotu jsme v rukávu měli ještě další nápady na vylepšení už tak krásného grafu, například vizualizaci mimořádných událostí, které mohly ovlivnit výkon. Pro lepší představu by to mohlo být zahájení Olympijských her. Pak by náš uživatel přímo v grafu viděl, že nárůst nad obvyklé rozpětí výkonu reklamní pozice bude pravděpodobně důsledkem této událostí a nemusí to dále nijak řešit.
Zároveň jsme si byli na 100 % jisti, že celé naše snažení vyústí ať už v grafy nebo ve statistiky – proč tak brzdit vývoj? Již teď můžeme začít pracovat na získávání dat z reportovacího systému. A taky bychom měli začít zkoumat, který software využijeme pro vykreslování grafu. Vše tak bylo připravené, už jen scházelo to představit koncovým uživatelům.
Samotné setkání jsme si řádně naplánovali. Nejdříve jim ukážeme jednoduchý návrh, kde budou v aplikaci zobrazeny jen statistiky. A následně je oslníme naším skvělým návrhem. Nicméně stalo se něco, co jsme nečekali – navzdory všem našim předpokladům uživatelé neskákali nadšením do stropu. Dle jejích slov to bylo něco, co nutně nepotřebovali, ale jinak to bylo dobré, možná jen pár malých úprav… tohle nás poněkud zarazilo. Cítili jsme, že něco není úplně správně. Že by námi navrhované řešení nebylo tak dokonalé, jak jsme si mysleli? Nebo že by vůbec nebylo tím správným? Rozhodli jsme se proto naplánovat další setkání.
Na dalším setkání jsme se blíže zaměřili na to, co konkrétně řeší. Po krátké diskuzi jsme se dozvěděli, že největší úskalí pro ně tkví v tom, že je složité získat ID reklamní pozice z naší aplikace. Toto ID následně vloží do systému, který jim poté vygeneruje report pro danou reklamní pozici. Toto trápení jsme po snadném ověření vyřešili přidáním tlačítka do naší aplikace. Po kliknutí na toto tlačítko se rovnou otevřel vygenerovaný report pro dané ID. Za málo peněz hodně muziky, co říkáte?
Jaká poučení z toho plynou?
Nebojte se si hrát na detektiva při sbírání zpětné vazby. V tomto případě došlo k tomu, že uživatel k nám přišel již s řešením, tedy že chtějí statistiky, ne s problémem. A jak má takový detektiv pracovat když k tomu dojde? Jednoduše. Stačí z uživatele postupně vydolovat celý kontext. Pokud Vám řekne, že mu chybí v aplikaci statistiky, tak jej požádejte ať Vás provede celým svým pracovním procesem. Klidně ať začne i od rána, kdy přijde do kanceláře a udělá si kafe. Jak postupně došli v celém svém dni k tomu, že si nakonec řekli “zde by se mi hodily statistiky.” Jaké akce tomu předcházely? Otázek není nikdy dost. Možná nechcete své uživatele příliš otravovat, ale právě díky otázkám přijdete na jádro problému a díky tomu pak přijdete se správným řešením. Buďte ten otravný pán v šedém baloňáku.
Udržujte uživatele v celém procesu, držte feedback loop. V našem případě jsme chtěli uživatele ohromit. Nechtěli jsme jim ukázat něco, co by se nám samotným nelíbilo. Zároveň jsme raději zahrnuli náš Customer Care tým, protože jsme byli přesvědčeni, že mají stejný problém. Bylo pro nás jednodušší se ptát jich. Pokud bychom, ale přímo uživatelům ukázali některý z prvních náčrtů, tak jsme si mohli snadno ověřit, zda jsme na správné cestě či nikoliv. Uživatel zahrnutý do těchto raných fází Vám může často potvrdit, zda jste na správné cestě či nikoliv. A to Vám ušetří nejen hodně času, ale zejména peněz.
A v neposlední řadě – prioritizace. Tahle eskapáda nás rovněž donutila se zamyslet nad způsobem prioritizace požadavků. Uvedený problém jsme chtěli odbavit kvůli tomu, že se nám objevoval často ve zpětné vazbě a že byl na první pohled triviální. Nicméně během představování našeho dokonalého řešení šlo z uživatelů poznat, že i když se jim naše grafy líbí, tak existují možná důležitější záležitosti, které by potřebovali vyřešit. Naše poučení tak bylo v tom, že jsme otočili a začali nutit prioritizovat zákazníky své požadavky mezi sebou. Přestali jsme se k nim chovat jako k izolovaným skupinkám. Rozhodli jsme se tyto skupinky pravidelně nahnat do jedné místnosti, kde mohou všichni využít tuto příležitost k předání zpětné vazby a k pobavení se o tom, co je pro koho důležité a proč. Díky těmto společným schůzkám jsme zajistili, že jako další budeme implementovat právě tu věc, na jejíž důležitosti se shodli naši uživatelé. A zároveň díky těmto společným diskuzím nad problémy provedeme část užitečné detektivní práce.
Náš příběh má i jeden happy ending – jelikož jsem si byli na samém začátku jisti, že určitě budeme nějakou formou pracovat s daty z reportingu, vytvořili knihovničku pro jejich získávání. Ta ale nakonec zůstala nevyužitá. Před nějakým časem jsme ji ale oprášili a nakonec použili ve zcela jiném projektu. Ne všechno tak bylo zbytečné. Ale museli bychom se tímto vůbec zabývat, kdybychom věci udělali dle našeho ponaučení?