Hogyan építs sikeres terméket folyamatos exploringgal?

A digitális termékek soha nem készülnek el, ezért valójában a discoverynek is folyamatosnak kellene lennie.

Egy korábbi cikkemben már írtam arról, hogy a service vagy product design folyamatában az emberek strukturált megismerésének leghatékonyabb módja, a design kutatás akkor tud a legnagyobb hatást elérni, ha a problémákat minél elemibb szinten próbáljuk megérteni.

Ennek eszközei az un problem spaceben zajló – tankönyvi értelemben legalábbis – agilissá kevésbé tehető generatív kutatások, amik lényegében a nagy problémákat boncolgatják. 

Például, hogy az emberek havi pénzügyeiben melyek a legfontosabb Jobs to be Done-ok, célok, amiket el akarnak érni. Tehát a problem spaceben nem érdekelnek még minket folyószámlák, hiteltermékek, amelyek már a megoldás részei.

A nagy, összett problémák megértése után viszont felmerül a kérdés, hogy mi ad választ az apróbb kérdésekre? Például, hogy egy alkalmazásban mi legyen egy gomb szövege?

Egy ideális világban a problem space research után a discovery soha nem ér véget, hanem folytatódik a solution spaceben is, az úgynevezett continuous discovery formájában. 

Mi az a continuous discovery?

Ahogyan a nevéből is sejthető, a continuous discovery azt jelenti, hogy nem(csak) projekt alapon történik a felhasználók megismerése, és megértése hanem folyamatosan. Azaz proaktívan kapcsolatba lépünk az ügyfelekkel, felhasználókkal, érintettekkel, egyrészt, hogy visszajelzéseket kapjunk a meglévő szolgáltatásunkról másrészt akár a jövőbeli ötletek kapcsán is vizsgálódjunk. 

A vállalatok egyébként sem tudják különböző okokból az ügyfél szempontjából látni önmagukat, ezért a folyamatos discovery ebben is segíthet valamelyest, az un. outside-in behozásával.

Maga a visszajelzés sokféleképpen érkezhet, a módszerek nem különböznek a hagyományos design kutatási eszközöktől, például a usability tesztelés, vagy experiment. 

A legnagyobb különbség abban áll a klasszikus design discoveryhez képest, hogy ideális esetben az agilis csapatoknál a continuous discovery folyamatosan zajlik, nem pedig egyetlen nagy előzetes exploring projektben, mielőtt a design és a fejlesztői munka megkezdődne. 

Hogyan lesz a discoveryből szokás?

Erre a kérdésre ad választ Teresa Torres Continuous Discovery Habit című könyve – amit mellesleg minden termék közeli embernek nagyon ajánlok. A kiváló könyvből alább néhány ajánlást mindenképpen kiemelnék.

Egy interjú minden egyes héten

Ahogyan említettem az általában design kutatók által végzett generatív kutatásban elsősorban az összetett kérdésekre, a big picturre fókuszálunk. A continuous discoveryben kisebb kérdések kerülnek terítékre, és a legfontosabb a kutatás folyamatossága.

Nem kell viszont 50 fős interjúkra gondolni, bármilyen kutatás jobb ugyanis, mint a semmi. Teresa Torres a könyvében azt ajánlja, hogy az agilis csapatok induljanak heti 1 interjúval. Minél rendszeresebb az interakció az ügyféllel, annál valószínűbb, hogy a csapat megtanulja, hogyan kell kérdéseket feltenni az embereknek és gyorsan hasznos insightokhoz jutni. 

Hogyan lesznek rendszeresen kutatási alanyok?

A kutatási alanyok rekrutálása nehéz feladat, de Teresa Torres könyvében erre is írt több tippet.

• Rekrutálás használat közben: Az egyik lehetőség ha – természetesen nem agresszív módon, az aktuális feladatát zavarva, mint a reklámcélú megoldásoknál – egy modalban kérdezed meg a felhasználót, hogy jutalomért cserében volna-e kedve egy 20 perces beszélgetésre. Ha látogató az igent választja, el lehet kérni a telefonszámát. 
• Cégen belül a segítség: Általában minden cégben vannak olyan részlegek, akik így vagy úgy rendszeresen kommunikálnak ügyfelekkel, például az ügyfélszolgálatos kollégák. Érdemes velük kollaborálni és például ügyfelek beszervezésben kérni a segítségüket, amikor előre meghatározott attribútumokkal rendelkező felhasználókba futnak. Például ügyfelek, akik éppen lemondták az előfizetésüket, vagy valamilyen funkciót nem értenek. 

A csapat minden tagja vegyen részt valamilyen formában a kutatásban

Abban nagyon jók vagyunk, hogy mások produktumait kritikával illessük, ez a saját munkáknál persze nincs így. Éppen ezért a continuous discovery jó lehetőség arra, hogy a team tagokat minél jobban involválva magukénak érezzék a kutatás eredményeit, ezáltal például a változtatások átvitele is könnyebbé válik. 

Az a mininum, hogy az interjúkat a product team streamelve, vagy utólag megtekintheti, de még jobb ha valamilyen formában részt vesznek a team tagok – például forgóban – interjú jegyzetelőként.

A continuous discoveryt segítő technikák

Four on Friday 

Tehát az kritikus, hogy rendszeresen használhatósági tesztelésnek vessük alá a terméket, hiszen az idő előrehaladtával egyre több funkció kerül bele, ami fokozatosan elkezdi erodálni a használhatóságát.

Az is egy veszélyforrást jelent, ha csak egyetlen projektszerű discovery történt, ugyanis az élesítés utáni iterációknál hajlamosak a csapatok feltételezésekre hagyatkozni, ami jelentős kockázat a termék kívánatossága és életképessége szempontjából is.

Leginkább ennek megelőzésére való a Four on Friday vagy éppen Three on Thursday a lényeg, hogy a minden héten legyen 1-2-3-4 vagy éppen 5 usability teszt. 

Ami viszont fontos, hogy rendelkezésre álljon valamilyen viszonylag automatizált rendszer a rekrutálásra, mert ha valami, ez megakaszthatja a folyamatot. 

A usabiliyt teszt menete kapcsán egyébként lehet inspirálódni a design sprintben lévő megközelítésből is, amikor is egy nap során kipörögnek a usability tesztek, a nap végén pedig kiértékelitek az eredményeket.

A Four on Friday jellegű kutatások nyilvánvalóan nem tudják kiváltani a nagy generatív kutatásokat, de mellesleg kapudrogként működhetnek benne.

Customer insights morzsák

Mivel az agilis csapatok spritnekben dolgoznak, kritikus kérdés a kutatási eredmények gyors megosztása. Általában a cégek amúgy is gyűjtenek ügyfél visszajelzéseket, bug riportokat, vagy kérdőíves feedbackeket. Olyan is van, hogy ezekből riportot gyúrnak, de sajnos ahogy a legtöbb riporttal lenni szokott: ignorálják.

Ami segíthet ezen az állapoton, az az automatizálás, például a customer panaszokat be lehet dobni egy slack csatornába automatikusan, amit a product team minden tagja lát. Ilyen módon gyakorlatilag a csapat real-time infokat kap arról, hogy milyen a felhasználói élmény.

Sőt, ami még jobb, elérhetővé válik az a régi vágyunk is, hogy mindenki magáénak érezze az experience fejlesztését. Például, ha a Slack csatornában a product teamből a user feedbackek között egyik fejlesztő kiszúr egy gyorsan javíható bugot, le is csaphat rá.

Sponsor Users

Az IBM Enterprise Design Thinking frameworkjéből származik a sponsor users koncepciója. A főleg B2B-ben jól működő koncepció lényege, hogy néhány kiválasztott felhasználóval, ügyféllel rendszeresen találkozik a product csapat. Ezek a felhasználók domain szakértelmünkkel, visszajelzésekkel, ötletekkel járulnak hozzá ahhoz, hogy a fejlesztésekbe bekerüljenek a felhasználói szükségletek. 

A kiélesítés után jönnek a kvantitatív adatok is

A cikkben eddig azt fejtegettem, hogy az exploring, soha nem ér véget – hiszen a termék sem lesz soha kész. Ehhez a törekvéshez viszont még egy dolog hozzátartozik szerintem, mégpedig az, hogy az élesítés után könnyebb lesz kvantitatív adatokat is becsatornázni a discoverybe. 

Úgy is fogalmazhatnánk, hogy kutatási szempontból ekkor kezdődik a mennyország, ugyanis megvalósulhat a mixed-methods működés: a rendszeres discovery révén lesznek kvalitatív, a digitális termékekből pedig kvantitatív adataink. 

Például a webanaltikából és az ügyfélszolgálati adatokból kiderülhet, hogy egy weboldal mely részei tűnnek problémásnak, azt pedig rendszeresen usability tesztelés tárgyává tehetjük, a visszajelzések alapján pedig kidolgozhatjuk a megoldást.