Ötletből validált prototípus 4 nap alatt: Design Sprint 2.0

A product design akkor válik értékessé, ha túllép a produkciós szerepén, és felhasználó centrikus módon jobb termékeket tud előállítani gyorsabban.

A Sprint című könyv már évek óta porosodik a könyvespolcomon, de bevallom még csak most, sok évvel a megjelenése után olvastam el. Zseniálisan jó módszertannak gondolom, melyet számos esetben tudunk használni a product designban.

A fejlesztési folyamatok kőkemény valósága

A mediumos cikkek szerint a tipikus lean fejlesztési folyamat így néz ki:

A valóságban ezzel szemben mikor kitalálnak egy terméket a build fázis a végtelenségig el tud nyúlni, ami elég nagy probléma mind a megbízónak, mint a beszállító cégnek. Ennek oka, hogy például nem minden érintettet vonnak be időben, így utólag bárki megfúrhatja a koncepciót. Illetőleg a folyamat során használt ócska módszerek – „megbeszéljük a meetingen” – során, amiben maradnak feledésbe merül, értsd a megbízó utólag meggondolja magát, és mást akar. Szóval az ideális kör alakú lean folyamat az előbbiek miatt valahogy így szokott festeni a valóságban:

A Design Sprint erre hoz egy rendkívül hatékony megoldást, segítségével minden érintett egyetértésre juthat 2 nap alatt. Az előbbi loop így néz ki a sprintben, egyfajta ötlet+validáció ciklus:

A design thinkinggel szemben – nyilván a saját korlátaival együtt – megvan az az előnye is, hogy egy konkrét receptet ad, egy olyan folyamatot meghatározott eszközökkel, amin végighaladva garantált az eredmény, egy felhasználókkal kitesztelt prototípus. Azaz anélkül, hogy magán a folyamaton kellene gondolkodnod, mindig pontosan tudod mi következik, és az eredmény is kézzelfogható.

Mire jó a Design Sprint?

A design sprint eredetileg ötnapos módszer a problémák megoldására és az ötletek tesztelésére.

A sprint összetett problémák megoldására való, ami lehet létező termék, vagy teljesen új produktum is. Inkrementális változások tisztázására – például egyetlen kis jelentőségű oldal redesignjának kitalálására – nem alkalmas.

• Hétfőn meghatározzuk a célt, térképet készítünk, és beszélgetünk a téma szakértőivel
• Kedden megoldás vázlatokat készítünk
• Szerdán eldöntjük, hogy a javasolt megoldások közül mivel megyünk tovább, majd megtervezzük a forgatókönyvet
• Csütörtökön prototípust készítünk
• Pénteken pedig felhasználói teszteket végzünk.

A sprintet anno startupoknak találta ki Jake Knapp, amikor a Google Ventures-nél dolgozott. A módszer  kiválóan segít a kezdő cégeknél, hogy felmérjék, jó úton járnak-e, mielőtt további kockázatokat vállalnának a termékük gyártásával. A folyamat végén nem lesz még termék (sem pedig MVP) csupán prototípus, azt viszont gyorsan validáljuk, így jelentősen csökkentjük a kockázatokat.

A sprint ereje a hatékonyságában rejlik, ami például annak köszönhető, hogy minden napnak egyetlen magas prioritású célja van. Ugyancsak hatalmas szerepe van a figyelemelterelések kiiktatásának, nem lehet mobilt/laptopot használni a workshopok során, ami a résztvevők fókuszáltságát drámai mértékben javítja.

Az egyik kedvenc sprint elvem az egyedül, mégis együtt. Ma már kijelenthetjük, hogy a csoportos brainstorming a csoportdinamikák negatív jelenségei miatt nem működik. Általában annak az ötlete megy át, aki a leghangosabb, vagy a legjobb saleses a szobában. Ha introvertált vagy, esetleg fáradt, akkor csendben maradsz. Ennek kiküszöbölésére szolgál az előző elv, számos feladatban – például a vázlatkészítés során – , egyedül dolgoznak a részvevők.

A Design Sprint 1.0 hiányosságai

Két hiányosságát érzem az eredeti Design Sprint módszertannak. Egyrészt a probléma feltárására csak a szakértői interjúk állnak rendelkezésre. Az esetek többségében ez nem elég, én a sprint elé tennék még egy user interjús hetet a probléma teljes feltárására.

Kritikus ugyanis, hogy a valódi felhasználói problémát is jól értésük, mert ha ez félremegy, akkor rosszabb esetben nem létező problémára adunk szükségszerűen nem valid megoldást. Ezt a fajta kutatást azonban nem kell túltolni, én a mami teszthez hasonló felhasználói interjúkat ajánlom.

A másik hiányossága az eredeti módszertannak, ami miatt anno el is vesztett, hogy 5 napos elköteleződést kíván a résztvevő csapatoktól. A megbízók leterheltségét ismerve ez eléggé irreális elvárásnak tűnik.

Időközben viszont megjelent a Design Sprint 2.0, ami többek között ez utóbbi aggályaimra is válaszul szolgál. Az upgradelt verzió az AJ&Smart berlini product design ügynökség és Jake Knapp közös munkájának eredménye.

A cikk keretei nem teszik lehetővé, hogy az alapoktól és a módszerekkel együtt részletesen ismertessem a folyamatot, tehát azt feltételezve, hogy olvastad a könyvet lehetnek az alábbiak hasznosak számodra.

Design Sprint 2.0: 4 napos sprint, kevesebb áldozat árán

A legnagyobb változás, hogy az updatelt folyamat 4 naposra csökkent. Ugyancsak hatalmas előny, hogy a teljes teamre csak hétfőn és kedden van szükség.

Hétfő

A délelőtt a probléma definiálásáról, a délután a megoldások kereséséről szól.

Délelőtt: Kihívások meghatározása

Nagyobb változás az eredeti ütemezéshez képest, hogy hétfő reggel a szakértői interjúkkal indítunk – és a “hogyan tudnánk” kérdésekkel -, ami segít a csapatnak megérteni a problémát. Ezen tudás birtokában történik meg a célok meghatározása és a sprint kérdések összegyűjtése.

Ezt követően rajzolják meg a térképet 45 percben, melyre a könyvben fél nap volt számolva eredetileg, viszont ennek az időkeretnek is elégnek kell lennie, hiszen ez csak egy vázlatos map. A döntéshozó ez követően kijelöli a térképen a kulcsterületeket és ezzel a hétfő délelőtt pipa.

Délután: Megoldásvázlatok

Megtudtuk, amit érdemes tudni a problémáról, itt az ideje, hogy gondolkodjunk a lehetséges megoldásokról. Alapvetően a Sprint 1.0 kedd egész napját hétfő délután tartjuk.

A villámdemókra kerül sor először, azaz más cégek/iparágak megoldásait keresünk. A lényeg, hogy tágabban értelmezve hasonló problémák szimpatikus megoldásaira próbálunk rábukkanni. A Spint 1.0-ban erre 3 óra van, ezt nyilván jelentősen le kell rövidíteni.

Miután megszavaztuk a villámdemókból származó legjobb ötleteket, a vázlatkészítés következik (ugyanaz a 4 lépés, ami a könyvben szerepel). Így is rendelkezésre áll az a maximum 2 óra, ami szükséges, hogy elkészülhessenek a megoldásvázlatok. Amint megvannak, mehetnek a falra, kedden reggel velük folytatjuk.

Kedd

Ebben a változatban a kedd nagyjából hasonló mint az eredetiben a szerda, de délután van némi változás.

Délelőtt: Szavazás a megoldásokra

Eldöntjük, hogy melyik megoldásból készül prototípus. A hőtérképpel kezdünk, azaz minden résztvevő pöttyöket tesz a neki tetsző részekhez. Ezután kerül sor a gyors kritikára, majd a próbaszavazásra. A délelőttöt a szuperszavat zárja, azaz a döntéshozó szavazata alapján eldől melyik prototípust készítjük el.

Délután: Forgatókönyv

Most következik a forgatókönyv, azaz amikor a megoldásokat egy sztorira fűzzük fel. Az eredeti verzióhoz képes egy optimalizáltabb, hackelt változat van a 2.0-ban, a User Test Flow.

A lényeg, hogy minden résztvevőnek egyenként 6 lépést kell felírnia a megoldáshoz. Ez lehet bármilyen interakció, amit a usertől várunk a prototípus használata során. Célszerű először az első és az utolsó stepet felírni, és a sztorit a maradék négyre kitalálni. Ezt követően mindenki felragasztja a lépéseit, és szóban elmondja (1 perc/fő).

Ezt követően megszavazzuk, hogy melyikkel menjünk tovább. Ha megvan a nyertes, eredeti Sprintben szereplő rácssorozatba mehetnek a nyertes lépések.

Ezzel kedd végére minden döntéshozatal megtörténik, és a szakemberek (ügyfelek) visszatérhetnek a munkájukhoz. Egyértelműen kijelöltük az irányt és továbbléphetünk a prototípusok készítéséhez majd pedig a user teszthez.

Szerda: prototípus

Ez a nap nem tér el sokban az 1.0-tól kivéve, hogy szerdán van, illetve nincs jelen már döntéshozó. A prototípusnál fontos, hogy minél kidolgozottabb legyen, azaz nem drótvázat kell készíteni, illetve a nap végén célszerű az ügyfélnek megmutatni, hogy mire jutottunk.

Csütörtök: User interjúk

Itt szintén nincs nagy változás, csak annyi, hogy egy nappal korábban történik.

Péntek

A Sprint 2.0-ban a péntek elvben szabad, ezt a napot lehet visszatekintésre használni.

Mi történik a Sprint után?

A Sprint után a döntés és a következő lépések meghatározása sokkal egyszerűbbé válnak. Egy alkalommal mindenképpen számolni kell, amikor ismertetik a teszt tanulságait.

Ha egy olyan termékről van szó, ami már létezik, akkor a Sprint során talált és validált megoldást a javításokkal lehet is implementálni nem nagyon van más teendő.

Leginkább még korábban nem létező termékek esetén sor kerülhet egy második sprintre, amivel optimalizálod a visszajelzések alapján a prototípust. Ez már nem feltétlenül egy teljes sprint, hanem egy prototípus és user tesztes nap leginkább. Ha pedig esetleg az esett ki, hogy a megoldás nem valid, akkor egy újabb teljes négy napos ciklusra is sor kerülhet, de az gyanítom ez ritka lehet. Ezt követően viszont hozzá lehet látni a fejlesztésnek.