Mi az design discovery és miért tilos kihagyni?

A design folyamat nulladik, és kihagyhatatlan lépése a discovery szakasz. A cégek mégis kihagyják, vagy rosszabb eseteben fejlesztési projekteben összekeverik a követelmény elemzéssel.

A product design egyik alapköve, hogy problémacentrikusak vagyunk, azaz nem ugrunk egyből a megoldásra.

Mikor nemrég megírtam a product design szemléletről szóló cikket, valaki azt kommentele, hogy nyilvánvaló dolgokat írtam le. Egyetértek vele. Azonban a magyar valóságban a probléma centrikusság mégis hiányzik, ezen megfigyelésemet pedig konkrét ágazati tapasztalatom mellett arra alapozom, hogy még mindig jóval több a nehezen használható termék – a jelen helyzetben gondoljunk csak a rosszabbnál-rosszabb élelmiszer webshopra – , mint a jó, és úgy vélem ez annak a következménye többek között, hogy a probléma feltárás nem elég alapos, vagy nem is történik meg.

Egyebek mellett, de különösen a probléma megértése végett kezdjük mindig a designt az úgynevezett discovery phase-zel.

A design discovery a product design egyik legfontosabb, és esetenként legmasszívabb fázisa, ezért akadnak olyan szervezetek, akik külön emberre bízzák a nemes feladat drivolását. Nálunk például én vagyok az, aki a legtöbbet van discoveryben, és alap esetben ez is a kedvenc szakaszom manapság. Elég sokat és hosszan tudnék írni a témáról, és bár igyekeztem visszafogni magam, így is valószínűleg legalább kétrészes lesz a design discovery alapjait bemutató cikkem.

Mi az a design discovery?

Az NN/g elegáns definíciója szerint a discovery fázis a product design folyamat előzetes része,  amely magába foglalja a problémakör teljes megértését, a megoldandó problémák pontos meghatározását és elegendő bizonyíték összegyűjtését, ami irányt mutat a következő lépésekhez.

A discovery azért esszenciális a design folyamatban, mert a megfelelő problémák megtalálására irányítja a projekt fókuszát és ezáltal pedig a megfelelő termék létrehozását teszi lehetővé.

A product designban éppen ezért ez a legfontosabb fázis, és semmilyen körülmények között nem hagyható ki (ami nem zárja ki, hogy ne lehetne optimalizálni az adott helyzetre, például ha kevés idő, vagy pénz állna rendelkezésre).

A híres double diamond modell szerint először a csapat kutatások segítségével megérti a problémakört és a kontextust, majd egyetértésre jutnak abban, hogy mi a pontos probléma, és csakis ezután lépnek a ötletelés és tesztelés fázisába:

Design discoveryt, nem pedig termék discoveryt végzünk

Gyakran product discoverynek is hívják ezt a folyamatot, de az egy valójában egy teljesen más folyamat, mint amit mi UX, UI vagy product designerek művelünk a projektek nulladik lépésében.

A design discovery ugyanis amennyire csak lehetséges technológia és megoldás mentes, ez pedig egy egészen más mindset, mint amit a fejlesztő csapatok képviselnek.

Amikor az agilis csapatok elhatározzák, hogy megépítenek egy terméket, a product discovery valójában már nem is felfedezés, hanem inkább követelménygyűjtés vagy validálás, ahol lényegében meg akarják erősíteni, hogy megoldásuk a megfelelő.

Ezzel szemben a design discovery sokkal kevésbé konkrét irányú, inkáb olyan holisztikus céllal kezdődik, hogy például “tudjunk meg többet erről a problémáról, hogy mekkora, és milyen lehetőségek rejlenek benne”. Jóval később persze foglalkozunk már a technológiai megvalósíthatósággal, de a nulladik lépésben soha.

Mikor van szükség discoveryre? 

Design discoveryre bármikor szükség lehet, amikor számos bizonytalanság akadályozza a csapat előrehaladását. Sajnos rendkívül gyakori, hogy a kizárólag feltételezésekre alapozott továbblépés kockázatos lehet, mert a csapat akár megoldhat egy olyan problémát is, amely nem igazán számít – tonnányi idő, pénz és erőfeszítés elpocsékolásával.

Aki beszállítói oldalon dolgozik, annak ismerős lehet az a helyzet is, hogy gyakori a megalapozatlan határozottság is, azaz az ügyfél váltig állítja, hogy tudja a user problémáját, aztán hamar kiderül, hogy egy darab felhasználóval sem beszélgettek még soha. Azaz lényegében saját zéró mértékben megalapozott, vagyis vélt problémájukra hoznak egy megoldást. Mivel a probléma kétséges, a megoldás sikeressége hazárdjáték, és ennek elkerülésében segíthet egy jól felépített discovery folyamat.

De discoveryre akkor is szükség lehet, ha a csapat nem igazán érti, hogy mi a közös cél, amit el kell érnünk.

A design discovery elemei

A felhasználók megértése: A UX kutatások révén a projekt csapat megérti, hogy kik a felhasználók és hogyan érinti őket az adott probléma, valamint hogy mik a szükségleteik, vágyaik.

A megoldandó problémák és a lehetőségek megértése: A csapat megérti, hogy miként és miért fordul elő a probléma, milyen hatással van a felhasználókra és a szervezetre. Ugyancsak megértik a probléma mértékét és a lehetőségeket a szervezet, a termék vagy a szolgáltatás számára.

Közös vízió: A discovery során a csapat az érdekelt felekkel együttműködve megérti az átfogó üzleti célokat és a kívánt eredményeket. A csapatnak meg kell határoznia az is, hogy miként fogja mérni a siker elérésének mértékét.

Problémák keretezése és továbbhaladási irány meghatározása

A design discovery egyrészt a problémák összegyűjtéséből és feldolgozásából áll, másrészt ezekre alapozva a továbbhaladási irány és fókusz meghatározása a végső cél.

Dan Brown a Practical Design Discovery című könyv szerzője éppen egy erre a gondolatra felfűzhető gyakorlatban kitűnően használható frameworköt alkotott:

Mind a probléma, mind a továbbhaladási irány két szakaszra van bontva:

• Egyrészt van a korai szakasz, ahol a csapat először divergensen, minél széleskörűbben gondolkodik, feltárva a problémák és megoldások körét
• Másrészt van a későbbi szakasz, ahol már konvergenciára törekszünk, amelyek konkrét problémákat és konkrét megoldásokat fogalmaznak meg.

A két szakasz szabja meg az aktivitások körét, melyekről a cikk folytatásában fogok írni.