Így lesz kerek a Design Sprint: Mi történik a negyedik nap után?

Egyfelől örvendetes a design sprint népszerűsége – már a hazai konferenciák is felkapták -, viszont nem teljesen kerek történetet mesélnek el az előadók, akik a sprintet a negyedik/ötödik napon a user tesztelést követően késznek nyilvánítják.

A design sprint egy 4 napos team munka, egy nagy problémák megoldására szolgáló módszertan – korábban már írtam róla. A sprint azzal zárul, hogy megmutatjuk a felhasználóknak a közös munka eredményeként összerakott prototípust. Akár házon belül használod a design sprintet, akár külsős cégként vagy közreműködőként, joggal merül fel a kérdés: hogyan tovább?

Az biztos, hogy itt nem állhat meg az élet, ugyanis a design sprint időpocsékolás mindaddig, amíg nem kezdünk valamit az eredményekkel.

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

A design sprint után két lépést mindenképpen meg kell ejteni: összegezni az eredményeket és találkozni a sprint teammel.

A sprint eredmények összegzése

Miután a user tesztek lefutottak a legfontosabb, hogy összegezzük az ismétlődő mintázatokat, ugyanis ez határozhatja meg a következő lépéseket. Mi a Virgo Product Design csapatban ezen elvárásnak egy sprint riporttal szoktuk eleget tenni, amit átküldünk a team összes résztvevőjének. Amit a sprint riportnak tartalmaznia kell:

• Az összes feladat összegzése, amin a sprint során végigmentetek
• A sprint cél és a sprint kérdések
• A fő visszajelzések, a pozitív és negatív kommentek egyaránt, amelyek a user teszt résztvevőktől érkeztek
• A user teszt résztvevők releváns demográfiai adatai
• Részletes javaslatok a folytatásra a tesztben megfigyeltek alapján 
• A feature lista, priorálva effort/impact mátrixon

Ez a riport nem csak egy jó referencia anyag, hanem ahhoz is segítséget nyújthat, hogy a sprint team tagjai promózni tudják más kollégáiknak a tanultakat. Egyébként csak a user teszt videók 5 órásak lehetnek, nem is várhatjuk el, hogy a sprintben részt nem vevő kollégák megnézzék azokat.

Follow up

Hasznos lehet a sprint utolsó napja után egy találkozót tartani a teljes sprint teammel. Ha egy irodában vagytok, akkor egy rövid meetinget, ha nem, akkor confcall is megteszi.

Érdemes megtudakolni, hogy kinek milyen volt a “sprint élmény”, főleg azok számára, akik még nem vettek részt hasonló workshopokon korábban. Egyúttal ragadjuk meg a lehetőséget arra, hogy megköszönjük a team tagoknak az áldozatos munkát, amivel a hét során hozzájárultak a sprint lebonyolításához.

Ezt követően tekintsétek át a sprint riportot és a visszajelzéseket.

A design sprint sokféle eredményre vezethet, ami a riportból és a follow up-ból eshet ki:

• A prototípus szinte tökéletesen működött, a legtöbb hipotézisünk validnak bizonyult, a felhasználók imádták és teljesen egyértelmű, hogy az implementációra kell lépni. 
• Találtunk valamilyen jelentősebb learning pillanatot, bár az alapötlet nem feltétlenül invalid, de a felhasználói visszajelzések alapján vissza kell menni még dolgozni rajta. 
• Kiderülhet, hogy nem valid a megoldás, teljesen új taktikát vagy megközelítést  kell keresnünk.

Bármelyik itt említett kiment is legyen az eredménye a folyamatnak, a sprint mindegyik esetben eredményes volt, hiszen csupán 4 nap alatt derült ki, nem pedig hónapok után, amikor már nehéz változtatni. Az eredmények inkább a következő lépések szempontjából érdekesek.

Iterációs Sprint

A legtöbb esetben szükség van még egy iterációra, az első hét tapasztatalati alapján. Ez egy második design sprint lényegében, de kicsit más felosztásban.

Az első hét általában jól kiadja az irányt, ami felé haladni kell, az iterációs sprint pedig némileg pontosítja a megoldást. Attól tehát nem kell tartani, hogy az iteráció alatt az egész hercehurcát újra kell csinálni, az első héten ugyanis számos feladat használható eredményre vezetett.

Ezen a héten az első nap a workshop, ami a következőkből áll:

• A user teszt visszajelzések átbeszélése
• A fő problémák összegyűjtése (mi ment rosszul és jól a teszten)
• Megfogalmazunk 3 új sprint kérdést az előbbiek alapján
• Szükség esetén újabb villámdemók inspirálódásra
• Az első héten is szereplő 4 lépéses megoldásvázlat
• Koncepció szavazás

A storyboardot többnyire már nem kell updatelni, mert általában ezen a héten már csak kisebb funkciók, finomítások szoktak kiesni.

Az első nap után még 2 nap áll rendelkezésre a prototípus feljavítására, amit végül újabb tesztelésnek vetünk alá a negyedik napon.

Hogyan lesz ebből termék?

Született egy eléggé kimaxolt prototípusunk – különösen, ha iterációs sprint is volt a történetben – a kérdés, hogyan fog mindez implementálódni. Design oldalról elég jól briefeli a feladatokat ez az állapot, de azért főleg a fejlesztés oldaláról érdemesebb mélyebbre menni.

Ha jól végeztük dolgunkat kirajzolódott a feature lista – hála az említett impact/effort mátrixnak -, de ettől tovább is léphetünk.

Ezen a ponton működhet jól a user story mapping. A lényege, hogy a terméket vagy a szolgáltatást, amit a design sprint során kiötlöttünk és validáltunk, task listára bontsunk a felhasználó szempontjából. Gyakorlatilag egy gridet kell elképzelni, aminek felső tengelyére a felhasználó útjának állmásai kerülnek, az egyes állomásokhoz pedig az azokhoz kapcsolódó funkciók.

Egy termékvásárlás esetében például így néz ki a user story map:

A taskokat tovább is bonthatjuk releasekre és így egy elég jól használható inputot kapunk a fejlesztéshez:

Azért is ajánlom ezt a rendszert, mert így a user kerül a központba, ezáltal segítve a fókusz megtartását. Másfelől egy gyakorlatban eredményesen használható framework, ami alapján a legtöbb esetben meg lehet tervezni az MVP-t.