dev-blog

Design Sprint bei karriere.at

Die Dinge richtig zu bauen ist wichtig und agile Praktiken helfen dabei. Ebenso wichtig ist es aber, auch darauf zu achten, die richtigen Dinge zu bauen. Und um letzterem gerecht zu werden, haben wir Anfang März 2017 unseren ersten Design Sprint absolviert.

Bekannt wurde der Design Sprint letztes Jahr durch das Buch „Sprint“ von Google Ventures. Dabei versucht man, komprimiert auf fünf Tage, zunächst eine Hypothese zu seinem Produkt oder einer neuen Idee zu definieren und mittels Prototypen am Ende der Woche mit echten Anwendern zu verifizieren.

Design Sprint Ablauf

Ablauf

Montag: Choose a target

Am ersten Tag dreht sich alles um die Definition der Problemstellung. Ein Team aus Mitarbeitern, die das Produkt, die technische Seite und die UX-Seite repräsentieren, suchen sich ein größeres Ziel („Long Term Goal“), welches man erreichen will. Dazu dazu stellt man ein paar Fragen in den Raum („Sprint Questions“). Davon wird dann gemeinsam ein grober Ablaufplan aus Anwendersicht erstellt („Map“).

Long Term Goal und Sprint Questions auf Flipchart

Am Nachmittag holt man sich dann firmeninterne Experten aus den unterschiedlichen Fachrichtungen in den Arbeitsraum und arbeitet deren Feedback noch in den Ablaufplan ein. Da die Map meistens zu groß ist, um alles prüfen zu können, pickt man sich eine Anwenderrolle und eine Situation heraus, welche dann an den folgenden Tagen weiter ausgearbeitet wird.

Map

Dienstag: Sketch

Basierend auf den Daten vom Montag, präsentieren alle im Team nun in Form von Lightning Demos, potenzielle Lösungsmöglichkeiten und Ideen, die man in den eigenen Prototypen integrieren könnte.

Ergebnisse der Lightling Demos

Am Nachmittag muss dann jedes Teammitglied für sich eigene Sketches entwerfen.

Mittwoch: Decide

Die Entwürfe vom Dienstag werden dann am Folgetag bewertet. Dazu wird nicht wahllos herumdiskutiert, da man sich sonst in Einzelheiten verläuft und nicht fertig wird. Stattdessen wird auf eine Abstimmung mit Klebepunkten zurückgegriffen („Sticky Votes“).

Ein Entwurf der am Mittwoch entstanden ist

Am Nachmittag wird dann eine Kombination aus den besten Ideen in Form eines Storyboards umgesetzt.

Storyboard

Donnerstag: Prototype

Das Storyboard vom Vortag dient nun als Vorlage für alle im Team, wenn es nun darum geht, die Ideen in einen funktionierenden Prototyp umzusetzen. Dies kann auf unterschiedliche Arten passieren. Im Buch wird eine Low-Tech-Variante mit Keynote oder Powerpoint empfohlen. In unserem Fall wollten wir aber das Benutzerverhalten auf einem Handy testen. Es stand kurz zur Debatte, ob wir dafür die App „POP“ von Marvel verwenden sollen. Da aber mit dem Tool noch niemand so recht Erfahrung hatte und wir auch gerne das Verhalten bei Texteingabefeldern testen wollten, haben wir beschlossen einen statischen HTML-Prototypen zu bauen.

Prototyp in Sketch

Ich als Agile Coach war hier zunächst etwas skeptisch, ob sich das in einem Tag ausgehen würde, aber ich wurde eines Besseren belehrt. Am Freitag in der Früh stand der Prototyp zur Verfügung.

Freitag: Test

Am Freitag lädt man dann Personen ein, die mit diesem Prototyp bestimmte vordefinierte Aufgaben lösen sollen. Das Team sitzt dabei im Nebenraum und beobachtet das Ganze mittels Webcam und macht sich Notizen, welche am Ende des Tages ausgewertet werden. Aus den Learnings leiten sich dann Folgeaktivitäten ab. In der Regel wird man den Prototypen nochmals etwas feintunen und anpassen und dann nochmals User Tests durchführen, bis man sich seiner Sache sicher ist und das Ganze dann in richtigen Code überführt.

Hier sind wir vom Buch etwas abgewichen, da es organisatorisch nicht möglich war fünf Leute zu finden, die am gleichen Tag zu uns kommen konnten. Wir haben daher am Freitag einen Testlauf mit zwei Kollegen aus anderen Teams gemacht. Dies war auch eine gute Gelegenheit um das technische Setup zu testen. Die tatsächlichen, externen Anwender sind dann in der Folgewoche bei uns gewesen. Die Sessions wurden aufgezeichnet und konnten dann vom Team ausgewertet werden.

Arbeitsplatz für User Tests mit externer Webcam Das Team beobachtet aus dem Nebenraum

Resümee

Wenn man so etwas noch nie gemacht hat, ist man etwas unsicher, ob sich das alles zeitlich so ausgeht, wie es im Buch beschrieben ist. Die Bedenken waren aber unbegründet. Wir waren meist sogar immer etwas schneller fertig. Es hilft allerdings, wenn sich der Produkt Owner bereits vor dem Sprint etwas Gedanken zum Ziel und den Fragen macht.

Ein weiteres Learning war, dass eine Generalprobe der User Tests sehr geholfen hat. Prinzipiell sollte man ja keine Kollegen oder Familienangehörigen für solche Tests anheuern, in unserem Fall hat es jedoch geholfen grobe technische Bugs vor den eigentlichen User Tests abzufangen.

Michael

Wenn Michael gefragt wird, was er beruflich macht, sagt er “Scrum Master”. Wenn er dann in ein fragendes Gesicht blickt, sagt er “Agile Coach”. Wenn dann die Stirnrunzeln bei seinem Gegenüber noch größer werden, wechselt er das Thema und redet über das Motorradfahren, Tai Chi oder Süßigkeiten.

MySQL InnoDB Row Format Compression, oder wie wir ...

How it is to be se Junior Web Developer

Dominik

Unser PHP Code Quality Package ist jetzt auf GitHub!