Kapiteln

0:00:00 Einführung und Vorstellung des Gasts Stefan Bierwirth
0:02:01 Anwendungsbereiche und Voraussetzungen für den Design Sprint
0:06:02 Vergleich mit anderen Methoden und Alternativen zum Design Sprint
0:08:19 Der Design Sprint: Zeitplan und Ablauf
0:10:18 Zusammensetzung des Design Sprint Teams
0:16:09 Unterschiedliche Varianten je nach Team und Problemgröße
0:20:02 Vorbereitung und Ramp-Up: Phase 0 des Design-Sprints
0:24:27 Fokus setzen und starten
0:26:38 Tag 2: Lightning-Demos und Inspirationen von anderen Lösungen
0:30:03 Mittwoch: Sketches werden aufgehängt und diskutiert
0:32:09 Ideenauswahl und Voting
0:35:00 Bau des Prototypen und Erstellung eines Interviewleitfadens
0:40:00 Live Feedback
0:42:22 Anstrengende Woche im Designsprint, aber fokussierte Arbeit
0:44:04 Emotionale Reise der Teilnehmer 
0:45:30 Erfolg und Feedback beim Design Sprint
0:47:52 Zusammenfassung und Dank an den Gast

Zusammenfassung

In dieser Episode von „Die Macht der Craft“ dreht sich alles um Design Sprints. Unser Gast Stefan Bierwirth erklärt, dass ein Design Sprint eine Möglichkeit ist, Kundenfeedback zu Ideen innerhalb von 5 Tagen zu erhalten, ohne das Produkt bauen oder Monate an Arbeit investieren zu müssen. Ein Design Sprint sollte für wichtige Themen mit hoher Priorität eingesetzt werden, wenn noch keine Lösung vorhanden ist und das Ergebnis noch offen ist.

Man kann also auch Teile aus dem Design Sprint nehmen oder andere Workshops durchführen. Es gibt bereits Versionen 2.0 und 3.0 des Design Sprints, der auf bereits existierenden Ansätzen basiert. Der Design-Sprint erstreckt sich über fünf Tage. Am Montag geht es darum, ein gemeinsames Verständnis und einen Fokus zu entwickeln. Am Dienstag werden Inspirationen gesammelt und Skizzen angefertigt. Am Mittwoch wird die Lösung ausgewählt und ein Prototyp erstellt. Am Donnerstag wird der Prototyp gebaut und am Freitag verprobt.

In einigen Fällen werden Tag 1 und Tag 2 zu einem Tag zusammengelegt, um den Design-Sprint auf vier Tage zu verkürzen. Die Auswahl hängt von der Komplexität des Problems und der Erfahrung der Teilnehmer ab. Das wichtigste beim Design-Sprint sind die Teilnehmer. Ein Team von etwa sieben Personen mit verschiedenen Fähigkeiten wie UX-Designern, Requirements-Engineers, Software-Entwicklern, Architekten, Marketingleuten und Kundenbetreuern wird empfohlen, um verschiedene Blickwinkel einzubringen und alle Stimmen zu hören.

Experten können auch eingeladen werden, um spezifisches Wissen beizutragen. Der Entscheider ist eine wichtige Rolle im Design-Sprint und trägt in der Regel die Verantwortung. Nach jedem Übungsteil gibt der Entscheider seine Entscheidung bekannt und holt vorher Input vom Team ein. Der Entscheider ist auch dazu da, Diskussionen abzukürzen, wenn das Team festfährt. Bei vielen Dingen im Design-Sprint kommen letztendlich mehrere Versionen heraus, und es geht darum, eine davon auszuwählen und damit weiterzuarbeiten.

Der Entscheider hat das letzte Wort bei Unentschieden. Die Phasen eines Design-Sprints bestehen aus der initialen Phase, in der das Problem und das Team geklärt werden, gefolgt von der Vorbereitung, in der die Woche geplant wird. Am Montag wird das Sprintziel und die Sprintfragen festgelegt. Am Dienstag werden How-Might-We-Fragen erstellt, um Probleme in Chancen umzuwandeln und mögliche Lösungen zu skizzieren.

Am Mittwoch werden die Sketches vorgestellt und eine Idee ausgewählt, um sie weiterzuentwickeln. Der Prototyp wird am Donnerstag gebaut und am Freitag werden Kundeninterviews durchgeführt, um Feedback einzuholen und die Sprintfragen zu beantworten. Das Team entwickelt sich im Laufe der Woche und ist am Ende oft zufrieden, aber erschöpft. Insgesamt ist der Design Sprint eine effektive Methode, um in kurzer Zeit von einer Idee zu einem Prototypen mit echtem Kundenfeedback zu gelangen.

Einführung und Vorstellung des Gasts Stefan Bierwirth

[0:00] Hallihallo und herzlich willkommen. Eine neue Folge der Macht der Craft ist für dich da.
Heute haben wir einen Gast zu uns eingeladen, Stefan Bierwirth.
Er wird uns alles Wissenswerte über Design Sprints erzählen.
Eine interessante Methode? Dann lass uns anfangen und unseren Gast begrüßen.
Die Macht der Craft arbeitet für dich.
Wir haben heute einen Gast bei uns, den Stefan Bierwirth. Stefan, herzlich willkommen bei der Macht der Craft.
Dankeschön. Willst du dich mal kurz vorstellen für unsere Ja, sehr gerne.
Ich bin der Stefan, ich bin Softwareentwickler, mache auch noch ein paar andere Sachen, zum Beispiel Design Sprints, wo es ja heute gehen wird.
Ich bin momentan bei der Dativ als Softwareentwickler, war davor in Regensburg, tätig und ja, ich glaube recht viel mehr braucht man gar nicht hier sagen.
Alles klar, dann nochmal herzlich willkommen. Schön, dass du da bist.
Jawohl, herzlich willkommen, Stefan.

[1:08] Danke. Ja, dann fangen wir mal mit unserem Interview an.
Wir haben ein bisschen was vorbereitet und zuallererst wollen wir uns mal überhaupt die Frage stellen, was ist denn eigentlich ein Design Sprint?
Ja, ein Design Sprint ich verwende da mal ganz gern die Metapher einer Zeitmaschine unter anderem auch, weil ich den Film Zurück in die Zukunft sehr gut finde Der Design Sprint ist wie eine Zeitmaschine um zu einem Punkt in die Zukunft zu reisen wo der Nutzer mit einem Produkt interagiert, das es jetzt so noch gar nicht gibt Also der Design Sprint ist eigentlich eine Möglichkeit, um eine Abkürzung zu haben zu einem Kundenfeedback von einer Idee innerhalb von 5 Tagen und das Ganze ohne das Produkt bauen zu müssen und veröffentlichen zu müssen und Monate, Jahre an Arbeit reinstecken zu müssen.

Anwendungsbereiche und Voraussetzungen für den Design Sprint

[2:01] Okay, cool. Ja, und eignet sich das für jede mögliche Aufgabe oder gibt es bestimmte Aufgaben, die sich besser eignen?
Oder wie würdest du das einschätzen? Wann würdest du sagen, ja, das ist die Methode, die wir jetzt nutzen sollten?
Ja, es ist auf jeden Fall kein Allheilmittel und es hängt auch ganz schön viel dran.
Also da gehen wir bestimmt nachher noch drauf ein, was alles an Menschen und Zeit notwendig ist. Also in diesen fünf Tagen.
Also man sollte es wirklich nur einsetzen, wenn es um ein wichtiges Thema geht, also das eine hohe Prio hat, weil es ansonsten auch schwer wird, die Menschen dafür so lange zu binden.
Man sollte es auch nicht einsetzen, wenn schon eine Lösung da ist oder wenn man schon recht weit im Prozess ist und eigentlich direkt mit dem Kundeneinbezug starten könnte, weil dann kann man viele Teile des Design Sprints eigentlich überspringen.
Und man kann es eigentlich am besten einsetzen, wenn das Ergebnis noch sehr offen ist, aber man trotzdem wirklich ein konkretes Problem lösen möchte.

[3:12] Also es geht auch nicht, dass man es irgendwie verwendet, um irgendwelche Weltlösungen zu entwickeln, sondern es sollte schon was Konkretes sein, weil man ja doch nur begrenzt Zeit hat eben.
Man möchte ja in den fünf Tagen zu einem realistischen Prototypen mit Kundeneinbezug kommen. Okay, also damit ich mir das ein bisschen vorstellen kann.
Also ein konkretes Problem musste man haben, die man zum Beispiel mit einer Softwarelösung entgegenwirken möchte, weil man diese Probleme auf der Welt schaffen möchte.
Man sollte aber noch in eine recht frühe Phase sein.
Also so grüne Wiese sowieso, aber auch noch relativ gut, was Requirements und Akzeptanzkriterien und diese Geschichten. Habe ich dich richtig verstanden?

[4:01] Genau, so kann man es eigentlich sagen. Also es muss jetzt nicht unbedingt, dass das ganze Produkt noch auf einer grünen Wiese ist, aber zum Beispiel das Feature, das man mit dem Design-Spin entwickeln möchte.
Wenn da noch wirklich Requirements und so weiter alles offen ist, dann bietet es sich perfekt an, weil dann kann ich in der Woche mir wirklich Gedanken machen von Null bis zu Prototyp.
Und ja, es ist ansonsten auch vergeudete Zeit, wenn schon irgendwie Arbeit reingeflossen ist, die man dann vielleicht doppelt hat. Okay, danke dir.

[4:32] Also um vielleicht nochmal ein bildliches Beispiel reinzubringen, also jetzt nochmal als Check, ob ich es richtig verstehe.
Wir bringen öfter Beispiele im Kontext von E-Commerce. Keine Ahnung, worum das ist, aber ich halte bei das Muster.
Also könnte es so ein Feature sein, zum Beispiel, ich habe einen Online-Shop und ich möchte meinen Kunden in Zukunft einen Produktkonfigurator zur Verfügung stellen.
Und dann dieser Produktkonfigurator, den gibt es noch nicht, ich weiß, ich will den haben, aber ich weiß noch nicht, wie es umgesetzt sein soll. Wäre das so ein klassisches Beispiel?
Das wäre eigentlich optimal. Also wenn ich sage, ich möchte den Produktkonfigurator in irgendeiner Form anbieten für meine Seite.

[5:13] Dann kann ich im Design Sprint wirklich mir tiefe Gedanken machen, also von einerseits, wo wollen wir in x Monaten sein, über was machen eigentlich unsere Wettbewerber oder was haben wir schon alles so gemacht, bis hin dann eben zu einer, wirklich einer Lösung für diesen, ja, für diesen, Konfigurator und das Wichtige ist halt auch, es sollte ja eh kein zu großer Brocken sein, weil man hat im Designsplan nur einen Tag Zeit, den Prototypen dann letztendlich zu bauen, und ja, wenn das zu, wenn man sich zu viel vornimmt, dann kann das natürlich nicht klappen.
Deswegen, das wäre eigentlich ganz schön, ganz schönes Beispiel, so ein Feature.
Okay, dann habe ich es auch verstanden. Wunderbar. Dann, ich hätte auch ein bisschen eine machiavellische Frage.

Vergleich mit anderen Methoden und Alternativen zum Design Sprint

[6:02] Ja, also wenn wir jetzt nicht gerade einen Design-Spring machen wollen, gibt es andere Möglichkeiten, das Gleiche zu erreichen?
Das klingt für mich auch sehr ähnlich wie DDD-Workshop oder so. Zum Beispiel, ne?
Ja, also ich würde sagen, man kann natürlich auch, Der Design-Spin besteht ja aus verschiedenen Methoden, also wie zum Beispiel das Prototyping oder am Montag gibt es so eine Übung, die heißt How Might We Notes, wo man sich überlegt, wie könnte man Problem XY lösen.
Also man könnte auch, wenn man nur Teile aus dem Design-Spin nehmen will, auch die rausnehmen.
Ich denke, es gibt auch für viele Sachen andere Möglichkeiten, andere Arten von Workshops durchzuführen oder das Ganze halt eben anders aufzuteilen, je nachdem, wo man halt im Prozess ist, ob man den ganzen Umfang des Design-Springs braucht oder ob es eher ein bisschen technischer ist.
Du gerade hattest mit dem DDD-Workshop.
Also es gibt ja noch verschiedene andere Methoden, aber ich denke mal, so in Richtung Design-Thinking ist der Design-Sprint auch so ein bisschen immer bekannt als in Anführungsstrichen Best-of von vielen Methoden.
Also da haben die beiden bei Google also, ja, eigentlich gut geklaut von anderen Methoden, die es schon gab und da eine super coole, ja, ein Gesamtpaket draus gebaut.

[7:30] Okay, danke dir. Klingt total interessant.

[7:35] Ja, was wäre deine nächste Frage, Matthias? Von diesem Design Sprint gibt es ja jetzt nicht nur eine Variante.
Da gibt es ja, glaube ich, jetzt schon eine Version 2, oder?
Ja, genau. Genau, es gibt inzwischen, glaube ich, sogar auch eine Version 3.0 und was weiß ich alles.
Ich glaube, da würde ich gerne mal jetzt noch kurz ein bisschen auf die, also wie die einzelnen Tage aufgebaut sind, eingehen.
Ich glaube, dann kann man es besser verstehen. Also, wie schon vorher erwähnt, es ist ja wirklich in fünf Tagen, also…
Innerhalb von einer Woche, es soll auch wirklich innerhalb dieser einen Woche stattfinden, fünf Tage, alles füllt sich da ab und Tag 1 am Montag geht es darum.

Der Design Sprint: Zeitplan und Ablauf

[8:19] Sich eben gemeinsam ein Bild zu machen und ein gemeinsames Verständnis und einen Fokus zu legen und Dienstag dann, Inspirationen zu sammeln und Sketches anzufertigen, am Mittwoch dann sich, ja, die Lösung, die man dann weiter verproben will, aussuchen, ein Drehbuch für Prototypen überlegen, also sprich, was will ich dem Nutzer am Freitag zeigen, am Donnerstag Prototyp bauen und dann am Freitag verproben.
Jetzt hat sich aber im Laufe der Zeit so ein bisschen ergeben, dass man in manchen Fällen, wenn jetzt schon ein bisschen mehr da ist oder wenn es sich einfach anbietet, dass man Tag 1 und Tag 2 zusammenlegt in einen Tag und das Ganze auf eine 4-Tage-Version verkürzt.
Das ist auch so in der neueren Literatur auch so meistens die Empfehlung kann ich nicht ganz so bestätigen, dass man das pauschal sagen kann, aber also diese 4-Tage-Version ist dieser Design Sprint 2.0 und ich würde mal sagen, es hängt echt davon ab, wie komplex ist das Problem, wie geübt sind die Teilnehmer mit der Methode und ja, also ich meine es gibt, es soll Firmen geben, die sehr.

[9:31] Komplexe und ja schwierige Themenstellungen behandeln und ich glaube, da kann man dann wirklich sich den einen Tag mehr guten Gewissens gönnen und versuchen, das Problem zu verstehen und zu schauen, dass wirklich jeder das Problem versteht und anstatt halt das wirklich durchzuruschen und in anderen Fällen kann natürlich auch die Vier-Tage-Version gut sein.

[9:55] Jetzt hast du ja vorhin gemeint, dass das Wichtigste genug sein muss, dass man die Leute bekommt, die da teilnehmen sollen.
Also welche Leute brauche ich denn überhaupt? Und, Also wer macht dann bei so einem Design Sprint mit? Welche Leute brauchen wir und wozu?

Zusammensetzung des Design Sprint Teams

[10:18] Also das ist eigentlich auch, ja ich sag mal, mit eine der coolsten Sachen am Design Sprint, dass man ein Team für diese fünf Tage hat, das durchgehend zusammenarbeitet und das Team besteht aus einem sehr diversen Skillset.
Also Ziel ist immer so, um die sieben Personen, plus minus zwei ist immer so die Empfehlung, sieben Personen zu haben, Und diese sieben Personen, die sollten wirklich, also das sollten nicht alles nur Requirements-Engineers sein oder alles nur UX-Designer, sondern das sollten halt wirklich UX-Designer, Requirements-Engineer, ein Software-Entwickler, vielleicht ein Architekt, vielleicht jemand aus dem Marketing, jemand, der mit Kunden jeden Tag zu tun hat.
Also möglichst um verschiedene Blickwinkel reinzubringen und auch wirklich, ja, auch alle Stimmen ein bisschen zu hören.

[11:11] Und genau, diese sieben Menschen sind halt dann die ganze Woche zusammen.
Wenn man jetzt sagt, ja, ich hätte aber noch gern Person XY, der weiß da noch was, das wir so sonst nicht mitkriegen, dann kann man am Tag 1 auch noch sogenannte Experten einladen.
Die können dann nochmal ihren Input geben, sind aber dann wieder raus.
Weil einfach so Workshops in einer zu großen Gruppe, die ziehen sich und die machen die Teilnehmer eher mürbe, als dass sie bessere Ergebnisse liefern.
Und im Sinne dessen ist es auch im Design Sprint so, um wirklich dieses durchgetaktet durchziehen zu können, gibt es noch die Rolle des Entscheiders. ist.
Und der Entscheider ist im Normalfall die Person, die das dann auch später verantwortet.
Und nach jeder Übung im Design Sprint ist es so, dass der Entscheider dann sagt, ja, wir machen es jetzt so.
Er holt sich immer vorher den Input ab von dem ganzen Team.
Aber er kann auch sagen, nee, aber wir machen es ganz anders.
Weil die Erfahrung halt einfach gezeigt hat, dass wenn der Entscheider, der es später verantwortet, nicht den Hut auf hat, sondern es so eine demokratische Entscheidung ist, dass der dann halt auch vielleicht mal nach einem Monat sagt, nee, ich wollte es aber eigentlich doch anders, ich habe das weg.

[12:21] Aber meistens ist da schon recht starker Konsens, aber es sollte einem bewusst sein.
Ja, aber was macht das Ganze für einen Sinn, wenn wir alle zusammenarbeiten, um ein Ziel zu erreichen und dann kommt einer und sagt, nee, kein Bock, machen wir anders? ist.
Ja, der Entscheider hört sich natürlich den Input von der Gruppe vorher an.
Also bei den meisten Übungen gibt es irgendwie Dot-Votings und der Entscheider bekommt dann von der gesamten Gruppe halt so ein Stimmungsbild, wo es hingehen soll und im Normalfall wählt er dann schon in die Richtung aus.
Aber klar, es kann auch sein, dass der Entscheider immer etwas anderes auswählt als die Gruppe, aber dann stimmt es nicht.
Das verstehe ich, Stefan. Der Entscheider kriegt nicht nur eine Möglichkeit, sondern mehrere.
Und zwischen diesen mehreren Möglichkeiten entscheidet er sich für eine normalerweise. sehe. Genau.
Der Entscheider ist halt auch ein bisschen dazu da, um Diskussionen abzukürzen.
Also wenn, ja, irgendwo sich das Ganze festfährt und die eine Hälfte will A, die andere B, dass man einfach sagt, Entscheider, sag bitte jetzt, was du willst und dann machen wir weiter, weil es sich ansonsten einfach sieht.

[13:43] Okay, verstanden. Danke dir. Ich glaube, was man auch dazu sagen kann, ist, dass dass bei ganz vielen Sachen, die man im Design Sprint macht, ja letztlich mehrere Versionen von Dingen rauskommen und da geht es dann darum, eine der Versionen, die ja bei den, Ergebnissen rausgekommen sind, als damit arbeiten wir weiter.

[14:04] Auszuwählen. Genau, ja.
Wunderbar. Und die anderen Sachen sind ja auch nicht verloren.
Also auch zum Beispiel, wenn jetzt die Sketches, die von den Teilnehmern angefertigt werden, wenn da der Entscheider da seine vielversprechendsten Ideen rauswählt, bleiben die anderen ja natürlich noch für später, die man immer noch verproben kann als Fundus.
Ja, okay. Danke dir. So wird eher ein Shoot raus.
Ich dachte mir, das macht wenig Sinn, wenn wir uns die ganze Arbeit machen und dann kommt einer und sagt, nee, nee, weiß schon, das machen wir jetzt ganz anders.
Weil das hatten wir ja früher schon. Brauchen wir keinen Design Sprint.
Ich glaube, im Kontext vom Design Sprint ist das ein bisschen anders, weil der Entscheider ja auch mitarbeitet.
Der ist ja sonst ganz normales Mitglied, wenn ich das richtig verstehe. Oder Stefan?
Also der ist ganz normales Teammitglied, hat nur eine gewichtigere Stimme, weil er am Ende des Tages vielleicht zum Beispiel für das Projekt den Hut auf hat. und halt die Sache nach oben verantworten muss zum Beispiel.
Wäre das zum Beispiel eine Scrum-Struktur, wäre der PO zum Beispiel?

[15:18] Meistens ist es ein PO. Okay. Aber wie Matthias schon sagt, der muss auch ran und der soll auch die ganze Woche wirklich dabei sein und sich nicht irgendwie mal rausnehmen, sondern wirklich genau als Teammitglied, da auch mitarbeiten, mitsketchen, schon mit, leiden, wenn es mal ein bisschen länger dauert.
Also im Falle eines Unentschieden bei irgendein Thema hat diese Entscheider die, Die gewichtige Stimme, würde ich sagen. Okay. Genau. Super. Danke für die Erklärung.
Naja, ich… Du weißt schon, ich bin alt. Ich kenne solche Muster von Entscheider, die kommen und sagen, zack, jetzt anders.
Das ist Wort vorbelastet. Ja. Genau.

Unterschiedliche Varianten je nach Team und Problemgröße

[16:09] So, aber jetzt hatten wir ja vorher über die unterschiedlichen Varianten gesprochen, die es da so gibt.
Jetzt habe ich bei dir so rausgehört, das ist eigentlich nicht wenig eine Frage des Geschmacks, sondern mehr eine Frage, mit was für einem Team arbeite ich.
Ja. Bist du richtig? Ich würde sagen, dass das einer der Faktoren ist, aber auch was für ein Problem habe ich.
Also, wie konkret ist es schon und wie groß ist es?
Also, wenn ich noch recht viel präzisieren muss, dann ist es schon besser, die Fünf-Tage-Version zu nehmen.
Aber klar, das mit dem Team ist auch ein wichtiger Faktor.
Okay. Und hast Hast du irgendeine Vorliebe, eine Präferenz persönlich, also was du lieber machst? Ich habe da mal was rausgehört.
Also ich würde sagen, wenn ich mit, also ich meine, das sage ich natürlich vorher verschwiegen, neben diesen Teilnehmern gibt es natürlich auch noch Leute, die es moderieren.
Wenn ich das mit Leuten zusammen moderiere, die vielleicht noch nicht so viel Erfahrung haben, dann finde ich die Fünf-Tage-Version besser, weil es halt einfach entspannter ist und man auch mehr Puffer hat.
An sich finde ich die vier Tage schon gut. Ich würde sagen, fünf Tage ist meistens besser zu investieren.

[17:23] Dann würde ich sagen, mich würde jetzt interessieren, ob wir vielleicht diese Methode, das ist ein Prozess und der hat unterschiedliche Phasen.
Welche Phasen sind die und was machen wir in jeder Phase?
Welche Ziele hat die Phase?
Wie wird aufgebaut? Welche Methoden verwenden wir in dieser Phase, sodass unsere Hörer halt mal einen guten Überblick bekommen, wie sich so eine Woche darstellt?

[17:56] Ja, also ich würde sogar sagen, oder vor der Woche würde ich sogar schon mal anfangen, weil natürlich das Ganze auch viel Vorbereitung braucht.
Und also die initiale Phase ist erstmal, meistens irgendjemand hat sich überlegt, ich möchte das machen, dann sollte man als Moderator oder Moderatoren-Team erstmal mit der Person klären, ist das wirklich das Richtige, also wir hatten es ja vorher, wann sollte man es einsetzen, dann eben diese sieben plus minus zwei Menschen zu finden und da auch eben zu schauen, dass die passen.
Die Kunden natürlich akquirieren, was auch nicht immer so leicht ist, die müssen ja auch schon, also die kann man ja nicht meistens nicht in der Woche dann spontan einladen, auch wenn das so im originalen Buch drin steht einfach mal schnell, Leute am Dienstag anschreiben findet man schon irgendwo jemanden im Normalfall sollte das gut vorbereitet sein und wir machen das Ganze eigentlich meistens inzwischen remote, und das heißt man muss natürlich auch diese ganzen ganzen Boards und Räume, ich mein …
Inzwischen ist das ja jeder gewohnt, aber es muss halt alles vorbereitet sein.

[19:08] Und man muss auch wirklich den Leuten einschärfen, ja, blockt euch bitte die ganze Woche. Ihr müsst euch wirklich dafür Zeit nehmen.
Wenn sich die Leute eben nicht diese Woche blocken, dann ist es meistens so ein Anzeichen dafür, dass es vielleicht eben doch nicht das wichtigste Problem ist, weil sie haben ja irgendwas Wichtigeres zu tun.
Und deswegen, das sollte man alles wirklich gut im Vorfeld klären.
Auch schon mal ein bisschen das Problem mit dem Auftraggeber besprechen und schauen, ja, macht das Sinn?

[19:38] Und dann auch schon mal den Leuten natürlich sagen, hey, das ist ein Design Sprint, schon mal grob ein bisschen Infos vorab, für die, die es interessiert, ihnen sagen, legt euch bitte einen Zettel und Stift zu, weil das machen wir dann auch immer wirklich mit Papier, also für die Sketches.
Und ja, dann hat man schon einiges zu tun als Moderator. und ich würde mal sagen, das ist so diese Phase 0 von dem Ganzen.

Vorbereitung und Ramp-Up: Phase 0 des Design-Sprints

[20:02] Erstmal Ramp-Up, Vorbereitung und wenn das erledigt ist.

[20:07] Dann kann man eben in den Design-Spin starten und genau, dann geht’s los am Montag mit so dem ersten, ja, also ich würde mal sagen, der Montag ist einer der anstrengendsten Tage.
Man startet zuerst mal, damit sich gemeinsam die Fachlichkeit anzuschauen und einfach gemeinsam zu zu verstehen, um was soll es da gehen.
Es sind auch oft mal Leute dabei, die vielleicht gar noch nicht so tief drin sind im Thema und die man erst abholen muss.
Und da ist es einfach gut, erstmal noch Zeit zu investieren und zu sagen, wir versuchen, das gemeinsam zu verstehen.
Wir holen alle ab. Und dann geht es in die ersten, ja sag ich mal, wirklichen Übungen des Design Sprints.
Man startet mit dem sogenannten langfristigen Ziel.
Das ist die Frage, wo möchten wir im besten Fall in zwölf Monaten, 18 Monaten stehen, Wenn alles perfekt läuft und geht dann über danach zu so einer Übung, ja wer so ein Premortem kennt, eigentlich da ein bisschen angelehnt, was könnte alles schief laufen und was sind die Fragen, die wir beantworten wollen und leitet daraus sogenannte Sprintfragen ab.

[21:13] Die Sprint-Fragen, das sind Fragen, die mit Ja oder Nein beantwortet werden können.
Also zum Beispiel so eine Frage wie, werden die Nutzer in unserem Konfigurator Feature XY verstehen?
Und diese Fragen sind halt dahingehend wichtig, dass das Ganze am Freitag mit den Kunden dann auch wirklich, ja, sag ich mal, empirisch ein bisschen verprobt werden kann und nicht irgendwie zu sagen, ja, ich glaube, das war ganz gut, sondern wirklich sagen zu können, Sprint-Frage war, wird der Benutzer mit unserem Konfigurator zurechtkommen?
Und das kann ich halt dann wirklich am Freitag mit Ja oder Nein beantworten pro Kunde und dann sagen, naja, vier sind nicht damit zurechtgekommen, einer schon, ist vielleicht nicht ganz so gut.
Genau, das ist wirklich so am Montag eine der ganz wichtigen Sachen, einfach da diese Grundlage zu legen mit einem Sprintziel und Sprintfragen.

[22:04] Dann, danach werden, wenn es Experten gibt, die eben auch interviewt und das ganze Team schreibt sich, während es von den Experten den Input kriegt, sogenannte How-Might-We-Fragen auf.
Das habe ich vorher schon mal ganz kurz angerissen, jetzt mal kurz noch erklärt vielleicht.
Das sind Fragen, wo man Probleme in Chancen übersetzt.
Also, ja, der Experte nennt irgendein Problem, das ein Kunde zum Beispiel mit der Anwendung hat und man schreibt sich dann halt auf How-Might-We, also wie könnte man Problem XY lösen.
Und da machen alle ganz fleißig Notizen und auch das Das dient dann eben so als Grundlage, um die wichtigsten Ziele, die man erreichen will, rauszubekommen.
Und nicht halt jetzt schon davon auszugehen, was jetzt irgendwie die Leute davor sagen, das und das ist wichtig, sondern wirklich gemeinsam das zu erarbeiten und dann die Spür dafür zu kriegen.
Ja, daraus folgend wird dann eine sogenannte Map erstellt. Das soll ein relativ einfaches Diagramm sein.
Sein, das aufzeigt, wie der Nutzer durch die Anwendung sich bewegt.
Das dient einerseits dazu, um später den Fokus zu setzen, aber auch um gemeinsam das Verständnis dazu zu entwickeln.

[23:20] Dadurch, dass man es gemeinsam erarbeitet, müssen auch alle dann gewissermaßen das gleiche Bild davon haben, wie die Kunden mit der Anwendung umgehen.
Und das ist halt natürlich auch wichtig als Grundlage für die Woche, dass man einfach weiß, der Kunde macht das und das damit. Und ihr merkt, ich erzähle schon recht lang von dem Tag 1, der ist auch echt lang und anstrengend.
Dann, ein bisschen zusammengefasst, nach dieser Map nimmt man dann diese Sprintfragen und das langfristige Ziel und die How-My-Tweets und klebt die auf diese Map und schaut nach, wo sind jetzt diese Punkte verortet, die uns am meisten beschäftigen.
Und zieht dann gemeinsam einen Kreis in dieser Map um den Teil, den man in der Woche behandeln möchte.
Also man baut nicht irgendwie das ganze Produkt gleich dann als Anwendung, sondern man sucht sich wirklich einen kleinen Fokus raus, um diesen kleinen Teil wirklich gescheit machen zu können und auch sich nicht zu überfordern.
Da muss man auch immer als Moderator die Leute einbremsen.
Und diesen kleinen Teil, diesen Fokus, ja, mit dem startet man dann in die Woche.

Fokus setzen und starten

[24:27] Und nach Montag sind meistens alle platt, so wie jetzt ihr wahrscheinlich alle nach dieser Erklärung.

[24:34] Und dann am Dienstag wird es aber wieder ein bisschen entspannter für die Teilnehmer.
Und ja, nach diesem ganzen Wust an Infos, die man aber dann einigermaßen strukturiert hat, kann man dann am Dienstag ins Kreative starten.
Alex hat, glaube ich, eine Frage. Ja, um es ein bisschen zu unserem Konfigurator zurückzukommen.
Wir machen am ersten Tag alle möglichen Sachen, die wir für unsere Konfigurator uns vorstellen können, die unsere Kunden brauchen werden.

[25:07] Und das sind natürlich, ich will mein PC konfigurieren zum Beispiel, da brauche ich natürlich eine CPU und ich brauche Speicher und ein Motherboard und so weiter.
Aber da brauche ich auch Peripheriegeräte und eventuell Monitore und vielleicht Windows-Lizenzen, wenn ich Windows installieren möchte.
Und wir entscheiden uns aber in diesem ersten Tag, um den Zeug kommen wir uns gar nicht.
Wir kümmern uns nur um unsere Kerngeschichte, nämlich dass der der Prozessor auswählen kann, der Motorboard, XYZ, 15 Varianten, was auch immer.
Und das ist unsere Kerngeschichte und alles andere kennen wir, wissen wir, dass es irgendwann einmal kommen wird, aber kümmern wir uns jetzt nicht darum. Habe ich dich richtig verstanden?
Genau so ist es, ja. Genau so kann man es sagen. Wunderbar.
Hätte ich schon irgendwann mal was verstanden. Also das wäre quasi der Kreis, den wir dann auf dieser Map gezogen hätten.

[26:08] Genau, es könnte ja sein, dass ihr eine Sprintfrage definiert habt, die irgendwie sagt, ja, wie unsere Kunden können sich genau den Prozessor auswählen, den sie möchten.
Und eine How-Mighty-Frage, die irgendwie ist, ja, wie können wir es schaffen, dass die Nutzer leichter zum passenden Prozessor kommen.
Und dann würde man natürlich eben ja, seinen Fokus eher auf diese Teile legen.

[26:33] Ja, genau. Okay.
Aber ich wollte dich nicht unterbrechen. Mach einfach weiter mit Tag 2.

Tag 2: Lightning-Demos und Inspirationen von anderen Lösungen

[26:38] Wir haben noch vier Tage vor uns. Das kann anstrengend werden.
Ja, genau. Das soll ein bisschen rüberbringen, so wie man sich im Designs-Bund auch fühlt.
Weil es ist eine lange Woche und es ist durchaus anstrengend.
Also das muss man wirklich sagen.
Aber es macht auch wirklich Spaß und das sagen auch die Leute immer. Also geht es zu Tag 2.
Genau, nach dem ganzen theoretischen Teil und so geht es dann ein bisschen mehr ins Praktische. und man startet damit mit einer echt coolen Übung und zwar den Lightning-Demos.
Da zieht jeder los und sucht mögliche Lösungen, die uns helfen können, das Problem zu lösen.
Kann sein innerhalb der Firma, außerhalb. Kann für unser Beispiel jetzt sein, dass jemand draufkommt, ja, für diese Konfigurator-App, ich habe mir, keine Ahnung, eine Speisekarten-App oder was weiß ich, eine Fast-Food-App angeschaut und da kann man sich voll cool sein Menü zusammenstellen Und dann bringt man das halt als Beispiel rein.
Da geht es wirklich halt darum, sich von guten Lösungen inspirieren zu lassen, weil man wird jetzt nicht irgendwie, im Normalfall nicht die Brillanz automatisch haben, sondern man muss wirklich schauen, was gut funktioniert.
Könnte ich mir auch in dieser Phase ein Produkt der Konkurrenz anschauen?
Absolut. Bei der Konkurrenz zu klauen ist natürlich auch da immer sehr gut.

[27:56] Oder zu schauen, was die Konkurrenz schlecht macht. Was wir besser machen wollen.
Wir nennen es nach wie vor einfach inspirieren lassen.
Genau, inspirieren lassen von der Konkurrenz ist auf jeden Fall auch ein guter Punkt. Sollte man auf jeden Fall machen.
Kann echt alles möglich sein. Wir hatten auch schon mal ein Beispiel, da hat jemand von das Gebäudeplatzierungssystem von Warcraft als eine gute Lösung rausgesucht und also es ist echt alles möglich.
Weißt du noch für was für ein Problem das die Lösung war? Ich glaube um Schritte in einem Ablauf anzuordnen. Ah, okay.

[28:33] Also ich finde das ist einer der schönsten Teile immer das mitzukriegen, wie kreativ die Menschen sind und was da alles kommt, echt immer cool.
Und ja, aus diesem ganzen Fundus und dem am Montag entwickeln geht es dann in so Also ja, das, was eigentlich auch allen immer Spaß macht, am Dienstag zu sketchen.
Das Sketching ist dann nochmal unterteilt in ein paar so Unterübungen, aber ich glaube, da müssen wir jetzt nicht so weit drauf eingehen.
Das Wichtige ist, es passiert halt einfach mit Papier und Stift und es entstehen dann eben Screens aus der Anwendung, was der Kunde macht, Interaktionen auch und, Lösungen eben für unser Problem darstellen. Und die werden aber natürlich auch ein cooler Part im Designs und die werden anonymisiert eingeschickt.
Das heißt, wenn irgendwie der UX-Designer seinen Sketch einschickt oder der Entscheider, dann sind die Leute nicht schon vorbelastet, dass sie sich denken, oh, da muss ich jetzt aber dafür dann stimmen, sondern die sind anonymisiert.
Und auch ganz wichtig, die darf keiner selbst erklären, sondern die müssen für sich selbst sprechen, weil weil das Produkt beim Kunden, bei dem Konfigurator sitzt auch später keiner daneben und sagt, ach, du musst dann übrigens da klicken, sondern das muss für sich sprechen.
Und ja, das ist eine Herausforderung, aber wichtig, dass das so gemacht wird.
Und die Sketches werden dann eben eingeschickt und dann sind wir jetzt auch schon bei Mittwoch. Dienstag ging schon ein bisschen schneller. Moment.

Mittwoch: Sketches werden aufgehängt und diskutiert

[30:03] Moment. Moment.

[30:06] Bleiben wir beim Dienstag nochmal kurz. Was ist der Sinn der Sache? warum machen wir das?
Also ich habe verstanden, was wir am ersten Tag und warum wir es tun.
Ich habe verstanden, warum wir Dienstag Vormittag das machen, was wir machen.
Inspiration, Ideen. Warum malen wir dann? Ja, da musst du dich noch gedulden bis zum Mittwoch, weil da arbeiten wir dann weiter mit den Sketches. Okay.

[30:31] Dann schauen wir mal, ob es deine Frage beantwortet. Auf jeden Fall Mittwoch werden die Sketches dann, also wenn es vor Ort ist, wirklich alles Alles an der Wand geklebt, wie in einer Kunstgalerie.
Ansonsten in einem Board. Werden alle Sketches aufgehängt, anonymisiert.
Und erstmal bekommt jeder Zeit, sich alles anzuschauen und kleine Pünktchen zu kleben, wo was cool sein könnte.
Einfach, um wirklich alle Ideen mal zu sehen, alles in Ruhe anzuschauen.
Und daraus, also danach werden die Sketches dann vorgestellt, aber natürlich nicht von der Person, die es gemacht hat, sondern von einer anderen Person.
Man lässt es halt dann immer random jemandem vorstellen.
Und man kann dann nach der Vorstellung noch sagen, ja, Sketch-Out, boah, willst du noch was ergänzen?
Wird inzwischen aber sogar weggelassen, weil das eigentlich meistens gar keinen Mehrwert bringt, sondern ja, was da nicht verstanden wurde, das wird meistens dann später eh nicht mehr relevant.

[31:27] Deswegen, ja. Ist schon mal vorgekommen, dass die Random-Person zufällig der war, die den Sketch gemacht hatte? Ja, da haben wir auch schon aufgepasst.
Also irgendjemand weiß? Ja, also die Moderatoren wissen das natürlich schon.
Ja, das wäre natürlich lustig, wenn es gar niemand wüsste.
Ich dachte, es ist halt völlig anonym und dann könnte es ja vorkommen, dass… Achso, ne, die Moderatoren wissen das natürlich schon.
Aber die haben ja auch, also die Moderatoren haben auch im Normalfall selber selber gar keinen Sketch natürlich gemacht.
Wobei ich auch sagen muss, ich mach schon manchmal ganz gerne einen Sketch.
Es ist dem Moderator überlassen. Um die Leute zu verwirren, ne? Ja, genau.

Ideenauswahl und Voting

[32:09] Auf jeden Fall, genau nach der Vorstellung, dann haben alle schon echt ein gutes Bild, was so an Ideen da ist.
Und dann geht’s darum, daraus, ja, ich sag immer, die beste Idee zu wählen ist eigentlich falsch, weil es sind alles gute Ideen, sondern eher die Idee, die man jetzt erstens verproben will am Freitag.
Diese Idee auszuwählen und dazu darf halt jeder voten und der Entscheider wählt dann nochmal endgültig und dann wählt man halt also entweder einen ganzen Sketch oder Teile von Sketches und nimmt die dann weiter in die nächste Übung.

[32:44] Es gibt auch hier noch den Bonus-Schritt zu sagen. Also ich finde Sketch A und Sketch B irgendwie voll cool.
Die kann ich aber irgendwie nicht kombinieren. Dann kann man einen sogenannten Rumble machen und die gegeneinander antreten lassen und einfach zwei Prototypen bauen.
Ist aber schon ein bisschen risky, also um das zeitlich unterzubringen.
Aber kann man machen, wenn man gleich zwei Ideen verproben will.
Im Normalfall aber ist es eben so, aus diesen ganzen Sketch-Fundus werden dann so drei, vier Ideen ausgewählt und ein Sketch, der als Basis dient und dann eben in dem nächsten Schritt vom Mittwoch dann ein Drehbuch erstellt, das so einen Schritt-für-Schritt-Durchlauf von dem, was der Nutzer am Freitag sehen soll, darstellt.
Also zunächst sieht der Kunde die Startseite, dann geht der Kunde auf unseren Konfigurator, Konfigurator, dann wählt der Kunde Komponente A aus und so weiter.
Und dann kann man in diesen Schritten, die man dem Nutzer zeigen will, dann natürlich auch eben aus den Sketches die Ideen reinkleben, die gevotet wurden.
Kann an Stellen, wo man jetzt gerade aus den Gewinner-Sketches keine Ideen drin hat, auch aus anderen Sketches sich natürlich was rausnehmen.

[34:02] Und das ist dann das Ziel eben für Mittwoch.
Einen fertigen Plan Plan in Form von einem Drehbuch zu haben von dem, was will ich in dem Prototypen Schritt für Schritt haben und schon ein bisschen eben, wie soll es ausschauen durch die Sketches.
Ist diese Drehbuch das, was wir arme Entwickler so ein Happy Path nennen würden?
Ja, das ist eigentlich…
Im Normalfall ein Happy Path, ja. Also es wäre mal auch interessant und ich denke, das wäre auch mal wichtig und gut, mal auch irgendwie einen Design Sprint zu machen, wo man, also man könnte auch sowas betrachten, wo irgendwie, keine Ahnung, vielleicht ein Fehlerfall, der oft auftritt, den man auch mal gut lösen will, könnte man auch machen.
Aber im Normalfall ist es, wie du sagst, der Happy Path.
Genau. Das ist total interessant, ja. Aber anstrengend.

[34:53] Ja, genau. Es ist nämlich noch lang nicht vorbei.
Jetzt sind wir dann erst beim Donnerstag. Den kann ich aber recht schnell zusammenfassen.

Bau des Prototypen und Erstellung eines Interviewleitfadens

[35:00] Aus dem Drehbuch und so weiter baut das Team, die einen liefern fachlichen Input, die anderen Designs und wieder andere kümmern sich um Abläufe, baut man einen Prototypen und erstellt einen Interviewleitfaden.
Und das ist eigentlich, was am Donnerstag passiert.
Ist das eine tatsächliche Anwendung jetzt dann oder immer noch sketchy oder was auch immer?
Also der Prototyp soll ja möglichst realistisch sein, um eben diese Zeitreise zu ermöglichen, um zu sehen, wie würde der Kunde mit der echten Anwendung umgehen.
Das heißt wiederum, also man hat ja nur einen Tag Zeit, aber er soll möglichst realistisch sein.
Deswegen sollte man natürlich das Tool wählen, mit dem man am besten umgehen kann.
Das kann alles sein von Keynote, PowerPoint über so Tools wie Figma.
Mal, aber man kann auch theoretisch sagen, hey, wir haben eine Truppe, wo irgendwie, weiß nicht, drei, vier Leute gut Frontend coden können.

[35:58] Lass es uns gleich als kleine Anwendung hinstellen.
Es ist tatsächlich einem vollkommen frei, es ist nur wichtig, dass es eben möglichst realistisch für den Kunden dann wirkt.
Also, dass er nicht in diesen Feedback-Modus reingeht, sondern dass er halt wirklich durch die Anwendung sich klickt und sagt, ja, dann klicke ich da hin und dann sollte das passieren und nicht, dass er halt ja, von Adam und Eva anfängt zu erzählen, was er sich wünscht.
Und es muss in die 6-8 Stunden reinpassen.

[36:28] Genau, ja. Also man sollte sich da nicht zu viel vornehmen und irgendwie Nachtschichten schieben.
Auch wenn es, ja, also man weiß schon, dass immer so der Ehrgeiz die Leute packt und dann will man doch noch das und das reinpacken.
Aber es geht ja wirklich darum, eine Idee schnell zu validieren und das auch gegebenenfalls wegzuwerfen.
Also da gehe ich dann beim Freitag nochmal kurz drauf ein. Aber es ist ja auch nichts, das jetzt für die Ewigkeit ist oder wo.
Es kann auch rauskommen, dass es eben nicht gut ankommt. und das muss einem auch bewusst sein und das darf man nicht als etwas Schlechtes ansehen.
Genau, und hauptsächlich wird man sich da ja eh jetzt auf relativ statische Daten, mit denen man arbeitet, konzentrieren.
Also niemand erwartet, glaube ich, dass man in sechs bis acht Stunden irgendwie eine Anwendung, die irgendwas Sinnvolles macht, hinstellen kann, sondern wir reden da halt tatsächlich von einem Click-Dummy, der eine Sache kann, nämlich genau diesen Happy Path, der durchdefiniert wurde und sonst nichts.
Das sollte man auch klarstellen.

[37:29] Der muss nicht viel können, bin ich bei dir, aber das, was er kann, muss er es gut rüberbringen.
Genau. Und das ist in der gegebenen Zeit, stelle ich mir nicht leicht vor.
Ich kann jetzt nur von dem Sprint erzählen, bei dem ich mal mitgemacht habe und da haben wir tatsächlich so ein Tool wie Figma benutzt.
Das ist im Prinzip ein Tool, mit dem UX-Designer Wunder vollbringen können und da echt in rasend schneller Zeit einen Click-Dummy hinstellen können.

[38:01] Der halt genau ein Playbook abspielen kann, sozusagen.

[38:06] Ja, also es ist echt so diese Devise, fake it till you make it, also möglichst viel faken.
Es gibt, also ich finde es auch, es ist immer anspruchsvoll, also man schafft es dann doch irgendwie immer, weil man halt echt talentierte Leute meistens dabei hat, die wirklich Gas geben und sich dafür begeistern.
In den Büchern gibt es ja auch immer Beispiele, dass selbst ganze, also von einem Hotel-Delivery- Robot, dass selbst sowas möglich war zu faken.
Da haben die halt dann einen Controller einfach genommen und den so gesteuert und so getan, als wäre der schon, ja, würde der halt wirklich diese Lieferungen, den Zimmerservice machen.
Oder auch für, ich glaube, es gibt auch ein Beispiel, wo es um so eine Fitness-App ging.
Da hätte so so eine Chat-Funktion drin sein sollen und dann haben halt auch einfach die Leute die Antworten on the fly getippt und das auch gefakt.
Also wenn man ein bisschen Kreativität hat, dann kann man vieles auch, was vielleicht sonst schwierig wäre, auch irgendwie faken.
Und wie Matthias schon sagt, mit Figma ist auch immer echt ein gutes Tool, um da realistische Prototypen zu kriegen, wo dann auch die Kunden sich teilweise denken, ja, ist das jetzt schon fertig?
Das schaut ja schon voll gut aus. Ist das jetzt schon die fertige Anwendung?
Wann kann ich das benutzen?

[39:24] Genau. Es gibt ja schon noch ganz viele andere Tools übrigens, die das gleiche können wie Figma. Genau.
Selbst, wie gesagt, mit dem allseits verhassten Tool PowerPoint kann man dafür Prototypen machen, wenn man sich gar nicht anders zu behelfen weiß, ist auch das eine Möglichkeit, solange man damit umgehen kann.
Genau. Wenn der Prototyp steht und der Leitfaden, dann kommen eben am Freitag die fünf Kunden, die werden dann interviewt, jeder einzeln.
Das Team macht sich Notizen. Wer jetzt denkt, das Team kann es doch einfach auch abhauen, die haben ja schon ihren Teil erledigt. Nein.

Live Feedback

[40:00] Es ist echt auch ganz wichtig, dass die Leute wirklich das Feedback live erleben, weil ansonsten glaubt nämlich keiner, wenn irgendwie der Kunde zehnmal über irgendwas stolpert, dann sagen die alle, das ist, glaube ich, der Nette, sondern das muss schon wirklich, alle sollen dabei sein, alle sollen sich Notizen machen, alle sollen wirklich sehen, wo der Kunde die Schmerzen hat und dann nach den fünf Interviews kann man sagen, Unsere Sprintfragen wurden beantwortet oder eben nicht.
Und wie machen wir jetzt weiter?
Ich habe es ja schon gesagt, es ist auch nicht unbedingt was Schlechtes, wenn dabei herauskommt, ja, das kam nicht so gut an.
Wir sollten vielleicht das wegschmeißen, den Prototypen, und nochmal neu anfangen.
Weil dann habe ich halt nur fünf Tage investiert und nicht halt schon einfach mal ins Blaue entwickelt oder losgelegt oder sonst was.
Aber es ist natürlich auch sehr schön und ein gutes Erfolgserlebnis, bis wenn rauskommt, die Nutzer finden das super cool und würden am liebsten gleich loslegen, weil klar, dann freut man sich natürlich mehr.
Aber weil du sagst, wir haben nur fünf Tage verwendet, aber das sind fünf Tage, sieben bis neun Leute, plus Experten, plus Kunden, das ist eine Menge Zeit.
Ja, aber auf der anderen Seite, wenn man sich jetzt überlegt, man entwickelt dieses Feature von A bis Z.

[41:17] Dann hast du auch fünf bis sieben Entwickler wahrscheinlich über, sagen wir mal, zwei, drei Monate beschäftigt und stellst dann fest, dass es nichts ist. Ich will ja nicht sagen, dass das schlecht wäre.
Ich will nur bewusst machen, dass ja, wir kriegen Feedback viel schneller und wir haben ein Ergebnis viel schneller.
Also in diese fünf Tage und nicht in einen Monat oder zwei Monate oder was auch immer es dauern würde.
Aber der Invest, den wir machen müssen, ist nicht zu vernachlässigen in meinen Augen. Es ist nichts geschenkt.
Ja, der Invest ist auf jeden Fall sehr hoch, weil meistens da auch mit Entscheidern und so weiter auch oft Leute drin sind, die halt ja vielleicht noch mehr kosten als andere.
Also der Invest ist echt hoch, auch dass sich die Leute die ganze Woche blocken.
Deswegen sollte man es halt, wie gesagt, nur für Dinge machen, die auch wirklich eine hohe Relevanz haben. Aber das Feedback ist eigentlich meistens, dass die Leute sagen, also so fokussiert und schnell haben wir sonst selten gearbeitet.

Anstrengende Woche im Designsprint, aber fokussierte Arbeit

[42:22] Aber ich gebe dir recht, es ist auch eine anstrengende Woche.
Also man ist danach wirklich ausgelaugt. Also wenn Freitagabend dann alles durch ist, denkt man sich, man hat jetzt einen Monat investiert.
Und ja, es bindet Leute komplett, also für die eine Woche, also auch wenn es nur sechs Stunden eigentlich angesetzt ist pro Tag, aber ja, mal überzieht man, dann noch viele Pausen ist natürlich wichtig.
50 bis 20, ne? Genau.

[42:51] Mich würde immer noch was anderes interessieren, weil offensichtlich, das ist eine sehr anstrengende Woche, am Ende von so einem Tag holst du dir bei solchen Sprints Feedback ein, wie die Leute sich fühlen, wie ihr Gefühl ist, wie sie auf den Sprint gerade blicken sozusagen, ob sie guter Dinge sind oder eher…
Ja, also Feedback sich einzuholen, finde ich, ist bei dem Designsprint schon wichtig jeden Tag.
Aber man muss im Hinterkopf behalten, viele oder die meisten haben dann halt die Methode noch nie so erlebt.
Und wie ich es gerade auch beschrieben habe, der Montag zum Beispiel, der klang ja schon so anstrengend, jetzt allein in der ewig langen Erklärung von mir.
Die Leute denken sich oft am Montag, hä, was wird denn das, was haben wir jetzt hier für ein Zeug?
Also man darf das Feedback dann auch, wenn es auf den Prozess bezogen ist, auch mal, man muss es schon, ja, mit einem, ja.
Mich würde vor allem dann als nächstes interessieren einfach, ob es da eine Entwicklung dann gibt über die Woche.
Und ob die bei den Sprints, die du so bisher moderiert hast, vergleichbar ist, diese Entwicklung.