Transcript
Lucas Dohmen: Hallo und herzlich willkommen zum INNOQ Podcast. Heute wollen wir über das Thema “Design Sprints” reden. Dafür habe ich mir drei Gäste eingeladen, zum einen den Roman. Hallo Roman!
Roman Stranghöner: Hi Lucas. Ich bin Roman und arbeite seit ca. acht Jahren bei INNOQ als Senior Consultant. Ich kümmere mich vorwiegend um Benutzeroberflächen und alles was damit zu tun hat, sowohl auf der technologischen Seite als auch bei den eher weicheren Themen, wie zum Beispiel “User Experience” und Produktentwicklung.
Lucas Dohmen: Und den Robert, hallo Robert!
Robert Glaser: Hallo Lucas, ich bin auch 'mal wieder da. Danke, für die Einladung. Ich bin jetzt seit fast zehn Jahren bei INNOQ und habe immer schon Internetanwendungen gebaut, sowohl im Backend, als auch im Front-end und das insbesondere aus der Benutzererlebnisperspektive. Ich arbeite gerade sehr viel im Produktbereich.
Lucas Dohmen: Dann haben wir noch einen vierten, vierbeinigen Gast. Wer ist das?
Robert Glaser: Das ist unser neuer Kollege Samson. Der hat tatsächlich vier Beine, aber schläft gerade. Daher wird er sich erst später zu Wort melden.
Lucas Dohmen: Aber er hat auch viel Erfahrung mit User Experience?!
Robert Glaser: Ja, sehr!
Lucas Dohmen: Was sind denn überhaupt Design Sprints, Robert?
Robert Glaser: In einem Satz erklärt, ist ein Design-Sprint eine Methodik, mit der man als Team einen sehr großen Umfang an Problemstellungen beackern kann. Wenn man ein Produkt entwickelt, kann das typischerweise schon sehr umfangreich sein, wie zum Beispiel eine Startseite oder ein Buchungsprozess. Vielleicht sogar noch mit einem Bezahlprozess hinten dran, aber das wäre typischerweise eine Grenze, wo man abschneidet. Ich kann damit sehr große Fragen innerhalb von vier Tagen in einem Team beantworten und die Lösungen, die für diese Fragen in den vier Tagen gebaut werden, auch direkt validieren lassen: durch konkretes Nutzerfeedback. Das heißt, das was man als Lösung für die “Sprint Frage” in diesen vier Tagen als Team entwickelt, wird den Nutzern am letzten Tag zum “Fraß vorgeworfen” und dementsprechend bekommt man wertvolles Feedback. Damit kann sichergestellt werden, dass diese große Frage, die man zu beantworten versucht hat, wirklich etwas was taugt oder ob sie vielleicht nichts taugt. Das klingt erst einmal negativ, ist aber auch ein sehr gutes Ergebnis, denn man kann nach den vier Tagen auch sicherstellen, dass das was man sich überlegt hat, eben “Mist” und gar nicht zielführend ist. Damit müssen nicht Monate in Entwicklung und Konzeption versenkt werden, sondern nach vier Tagen weiß man schon sehr gut Bescheid, ob das der richtige Weg ist ein Produkt zu bauen.
Lucas Dohmen: Design Sprints sind ja etwas, das wir bei INNOQ neu anbieten. Das kommt daher, weil wir beim Kunden ein Bedürfnis festgestellt haben. Was ist denn das, was da bisher fehlte?
Roman Stranghöner: Es gibt das Sprichwort “Die Dinge richtig bauen und die richtigen Dinge bauen” und als Technologiefirma sind wir erpicht darauf, die Dinge richtig zu bauen und darin sind wir auch besonders gut. Wir haben aber auch festgestellt, dass unsere Kunden immer häufiger auch Beratung darin brauchen, die richtigen Dinge zu bauen und die essentiellen Sinnfragen vor der eigentlich Entwicklung zu klären. Dafür bieten sich Design Sprints eben sehr gut an. Die sind auch nicht neu und wir haben sie nicht erfunden. Es es eine Methodik aus dem Hause Google, streng genommen Google Ventures. Es gab schon 2016 ein Buch von Jake Knapp, einem der Mitarbeiter dort, der ein erfolgreiches Buch darüber geschrieben hat. Das können wir auch in die Shownotes packen. Er ist mehr oder weniger der Vater dieser Methodik.
Lucas Dohmen: Wir bieten Design Sprints nun verschiedenen Kunden an. Wie oft habt ihr schon welche durchgeführt? Ein, zwei Mal oder häufiger?
Robert Glaser: Wir haben Design Sprints im letzten Jahr bei uns etabliert und setzten sie immer mehr bei Kunden ein. Teilweise sowohl bevor ein Projekt überhaupt anfängt. Gerade wenn es um eine Neuentwicklung, eine “Grüne-Wiese” Entwicklung bzw. ein komplett neues Produkt oder ein bestehendes Produkt neu zu denken und zu entwickeln geht, eignen sich Design Sprints sehr gut. Wir haben aber auch mit Kunden zusammen Design Sprints eingesetzt, um größere Teile innerhalb eines bestehenden Systems oder Produkts neu zu denken und zu verbessern. Ein schönes Beispiel ist ein so genannter “Warenkorbprozess”: Wie finde ich Produkte im System? Wie lege ich sie in den Warenkorb? Wie pflege ich diesen Warenkorb als Nutzer und wie gelange ich in den Checkout? Da wäre dann auch eine schöne Grenze. Man kann es also prima sowohl für bestehende Systeme verwenden, um größere Funktionen und wirklich die ganzen Systeme mal neu zu denken, als auch für komplett neue Produkte, bei denen noch gar nicht klar ist, welche Geschäftsziele erreicht werden sollen: Den Umsatz in möglichst wenig Jahren verdoppeln oder will möglichst viele Nutzer gewinnen, wenn es sich um eine Community handelt. Oder will man Conversions erhöhen…? Diese Fragen auf sehr hoher Geschäftsebene beantwortet man auch wirklich am ersten Tag im Team. Man setzt sich ein hehres Ziel und der Prozess sieht vor, dass es sich um ein ordentliches Ziel handelt, also nicht zu klein aber auch nicht zu groß gedacht. Ein Sprint-Goal könnte zum Beispiel sein: In zehn Jahren wollen wir der Marktführer für Espresso Bohnen in Deutschland sein. Oder wir wollen innerhalb der nächsten zwei Jahre unseren Umsatz mit dem Warenkorb verdoppeln. Der Sprint soll dann auf dieses Ziel einzahlen. Das heißt, die entwickelte Lösung aus dem Sprint soll sicherstellen, dass dieses Ziel irgendwann erreicht werden kann.
Lucas Dohmen: Das heißt, man geht mit einer Zielstellung, einer Frage in den Design-Sprint und diese Frage möchte man beantworten? Oder das Ziel möchte man klarer definieren?
Robert Glaser: Genau.
Roman Stranghöner: Tatsächlich beides. Das sind die ersten beiden Punkte auf der Agenda, die man üblicherweise am Montagmorgen angeht: Als erstes über das Sprint-Ziel zu sprechen und als zweites diese Fragen zu sammeln, die man während des Sprints beantworten will.
Lucas Dohmen: Bevor wir da einsteigen, womit kommt der Kunde zu euch um einen Design-Sprint zu machen? Hat er schon ein Ziel oder was fragt der Kunde, wenn er einen Design-Sprint haben möchte?
Roman Stranghöner: Meistens ist es sogar so, dass er noch gar nicht weiß, was ein Design-Sprint ist. Es kommt darauf an: Wenn wir merken, dass es an der Stelle ist, wo der Kunde gerade steht, sinnvoll ist, dann schlagen wir es ihm vor. Es ist nicht immer in allen Situationen sinnvoll, Design-Sprint als Methode beim Kunden einzusetzen. Wenn wir aber merken, dass es Bedarf gibt, dann schlagen wir es ihm meistens vor und briefen ihn vorab durch, was er erwartet, welche Kosten auf ihn zu kommen, was er dafür bekommt. Dann muss man im Vorhinein ein paar Rahmenbedingungen mit dem Kunden klären: Welche Benutzergruppen für das Stück Software zu erwarten sind, denn der Sprint sieht vor, dass am letzten Tag Nutzertests durchgeführt und das Feedback gesammelt wird. Um diese Nutzer auszuwählen, muss man im Vorhinein schon mindestens klären, welche Benutzergruppen grob dafür in Frage kommen, um die Benutzer aus rein organisatorischen Gründen vorher einzuladen und zu briefen. Das ist im Prinzip der eine Teil. Zum anderen spricht man mit dem Kunden natürlich über den Umfang. Üblicherweise hat der Kunde an der Stelle schon sehr konkrete Vorstellungen was das Problem ist, wo der Schuh drückt. Da versucht man dann gemeinsam den Umfang einzugrenzen oder sogar weiter zu dehnen, je nachdem, wie viel man in diesem einen Sprint schaffen kann. Da versuchen wir schon ein wenig anzuleiten, was in einem Sprint möglich ist und an welchen Stellen mehrere Sprints nötig wären, die auch zeitlich versetzt sein oder aufeinander aufbauen können. Oder eben mit anderen anderen Methoden an der Stelle weiter zu arbeiten.
Lucas Dohmen: Das heißt also, die Benutzer als Zielgruppe zu ermitteln ist nicht Teil des Design Sprints. Das ist etwas, was vorher schon passiert? Auch das Erstellen von “Personas” gehört nicht dazu?
Roman Stranghöner: Genau. Alle diese üblichen Research-Methoden gehören nicht in den Design-Sprint rein. Für uns gehört es zum “guten Ton”, diese Dinge im Vorhinein zu erfragen und uns schlau zu machen, damit wir einfach in den Sprint starten können und nicht so viele Verluste entstehen. Gerade am ersten Tag gibt es zwar einen Bereich, wo man mit Experten ein wenig darüber spricht, was die eigentliche Anwendung ist, was sie tut und wer darin arbeitet. Aber die typischen Research-Themen sind eher im Vorfeld anzusiedeln. Wir machen das meistens sogar auch bis zu einem gewissen Grad, aber wir bauen nicht im Vorhinein irgendwelche Personas für den Kunden zusammen. Sowas machen wir eigentlich nicht.
Lucas Dohmen: Wenn man jetzt so einen Design-Sprint starten möchte, wen muss man denn da mitbringen? Wer ist dabei, wie viele Leute sind das? Fünf, zehn, zwanzig..?
Robert Glaser: Ein guter Umfang ist so um die fünf Leute. Wir hatten schon den Fall, dass es auch acht Leute waren, aber damit steigt der Zeitaufwand immens. Man muss dann an den Pausen kürzen und so weiter, weil die Teammitglieder sehr viele Lösungen in so einem Sprint produzieren. Das Buch spricht auch ganz schön davon, dass man “als Team zusammen alleine arbeitet”. Also das Team ist zwar immer zusammen in einem Raum, aber es gibt sehr viele zeitintensive Phasen, in denen jeder für sich in Eigenarbeit Lösungen produziert. Diese werden auch “Solution Sketches” genannt. Wenn man viele in so einem Sprint hat, dann steigt natürlich die Zahl der Lösungen, die produziert werden und das folgende Voting nimmt dann auch viel mehr Zeit in Anspruch. Generell wird alles, was man macht, sehr viel länger. Deswegen haben wir für uns fünf Leute als gute Zahl herausgefunden, acht eher weniger. Das geht zwar auch noch, aber davon raten wir generell ab. Bei weniger als fünf Leuten muss man schauen, dass die Perspektiven noch abgedeckt werden, die man in so einem interdisziplinären Team haben will. Man will nämlich weder nur Entwickler noch nur Designer dort sitzen, sondern eine gute gute Mischung haben. Idealerweise hat man eine UX-Person und eine Person, die die technische Entwicklung abdeckt. Je nachdem, um was es bei der Frage geht, möchte man einen “Marketingmenschen” dabei haben, und wenn es irgendwie geht, auch den CFO. Damit man direkt eine möglichst breite Meinungsperspektive ins Team bekommt. Wenn man also so eine Mischung von fünf interdisziplinären Menschen aus dem Unternehmen hat, dann ist das mit Sicherheit eine gute Sache.
Lucas Dohmen: Wenn ihr jetzt für einen Kunden zu einem Design-Sprint kommt: Wen bringt ihr da mit?
Robert Glaser: Wir bringen einen “Facilitator” mit. Der ist im Grunde nichts anderes, als ein Moderator, der diese vier Tage komplett anleitet und moderiert. Ein großer Teil eines Design Sprints ist auch Wissensvermittlung. Obwohl es kein Training ist, lernen die Teilnehmer sehr viel und im Prinzip kann man dann so einen Sprint auch irgendwann alleine ohne uns durchführen. Generell ist es aber, zumindest in der Moderatorenrolle, weil viel moderiert werden muss und es gerade intern oft auch “Gräben” gibt, gut, eine externe Perspektive zu haben. Wir müssen häufig noch ein bis zwei weitere KollegInnnen von uns mitbringen, wenn es darum geht den Prototypen an dem Mittwoch selbst zu bauen. Dabei machen wir dann mit dem jeweiligen Kunden vorher aus, ob Designwissen vorhanden ist und die Leute Prototyping-Tools möglichst zeiteffizient bedienen können. Der Mittwoch ist extrem eng getaktet, da dann auch der ganze Prototyp entsteht. Wenn das nicht der Fall ist, bringen wir ein bis zwei KollegInnnen mit, die das können. Wir entscheiden von Fall zu Fall, was am besten passt.
Lucas Dohmen: Reden wir also nun über den Ablauf. Sagen wir mal, der Sprint geht von Montag bis Donnerstag: Was passiert am Montag?
Roman Stranghöner: Man muss noch kurz einen Schritt zurück gehen: Ursprünglich ist die Methode auf die die vollen fünf Tage angedacht gewesen. Mittlerweile hat es sich, seit die Methode erfunden wurde, herauskristallisiert, dass sich vier Tage etwas besser dafür eignen. Man kann noch komprimierter und mit weniger Aufwand beim Kunden dasselbe Ergebnis erreichen. Deshalb empfehlen wir immer, es sei denn es spricht irgendetwas organisatorisches beim Kunden dagegen, die vier-Tage-Variante. Bei dieser Variante ist es so, dass der Montag damit startet, die fachlichen Dinge zu besprechen. Dabei geht es dann viel um “Anforderungsmanagement”. Wie vorhin schon erwähnt, startet man mit dem eigentlichen Sprint-Ziel, mit den Fragen, die man klären möchte und dann geht es über in das Interview mit verschiedenen Fachexperten. Dies können sowohl Personen sein, die am Sprint teilnehmen, als auch Personen aus der Organisation, die dann für einen kleinen Plausch eingeladen werden. Dann sitzen die Sprintteilnehmer daneben und führen mit diesen Personen ein offenes Gespräch und “fragen ihnen ganz viele Löcher in den Bauch”. An der Stelle ist es übrigens auch sehr gut, wenn man Externe dabei hat, weil die Kunden häufig dazu neigen, in einem “Tunnel” zu sein oder sich schon sehr stark auf ihr Produkt eingeschossen zu haben. Da ist es häufig sehr hilfreich, wenn jemand von außen “blöde Fragen” stellt. Gerade die simplen, einfachen Sinnfragen werden häufig gar nicht mehr so wirklich wahrgenommen. An der Stelle ist es sehr gut, wenn man jemanden dabei hat, der von außen kommt und das Ganze erst einmal verstehen muss, weil es dazu führt dass man auch über diese einfachen und eher grundlegenden Dinge redet. Man führt also, diese Experteninterviews und dabei machen sich die einzelnen Teammitglieder des Sprints Notizen. Diese Notizen werden in einem bestimmten Format erfasst: “How might we” oder “Wie könnten wir?”-Notizen. Das Format ist einheitlich, damit man die Notizen aller Mitglieder sammeln, vergleichen und bewerten kann. Das macht man in einem definierten Zeitraum, so wie eigentlich jede Technik eines Sprints in einer fixen Timebox durchgeführt wird. Der Moderator ist an der Stelle dafür zuständig, die Timebox einzuhalten. Die Notizen dienen dazu, Potentiale frei zusetzen und weniger kritische Fragen als die Sprintfrage wie am Anfang, sondern eher essentielle Fragen zu stellen: Wie könnten wir dieses oder jenes lösen? Wie könnten wir dieses oder jenes Problem angehen? In einer positiv formulierten Art und Weise wird aufgezeigt, welche Dinge im Sprint angegangen werden können. Welche uns dazu dienen, das Produkt besser zu verstehen und eine optimale Lösung zu generieren. Nachdem die ganzen Notizen gesammelt wurden, sucht man in der Gruppe diejenigen heraus, die für diesen Sprint sehr essentiell sind. Mit der nächsten Technik geht einher, dass eine große Landkarte aufgemalt wird, auf der, linksseitig beginnend, die Interaktionspunkte für die eigentlichen “Aktoren” des Produkts aufgezeichnet werden, sei es jetzt Software oder irgendetwas anderes. Dann werden in der Horizontalen verschiedene Phasen aufgemalt. Man beginnt üblicherweise mit der “Discovery-Phase”: Wie findet dieser Aktor zu diesem Produkt? Dabei bewegt man sich auf dieser Landkarte schrittweise auf die rechte Seite der Karte. Es ist etwas schwierig zu erklären, ohne es zu zeigen. Die Karte ist in die Discovery-Phase, in die “Learn-Phase” - der Benutzer macht sich mit dem Produkt vertraut und die “Use-Phase” - er benutzt das Produkt, und das ist meistens auch die, an der man sehr interessiert ist, eingeteilt. Man malt sich also einen ungeordneten, “lustigen” Graphen auf. Der hat nichts mit UML zu tun, sondern ist bewusst sehr roh gehalten, da man viel darin “rumkritzelt” und der teilweise angepasst wird. Wenn die Experten interviewt werden, besteht meistens viel Diskussionspotential darüber. Insgesamt aber, dient die Karte dazu, ein gemeinsames Verständnis innerhalb des Sprintteams aufzubauen und das ist ganz essentiell. Eines der vielen Probleme in der Produktentwicklung ist, dass jeder in seinem Silo wohnt und jeder eine andere Sicht auf dieses Produkt hat. Man weiß daher häufig gar nicht, dass ein Entwickler eine ganz andere Sicht darauf hat, ganz andere Annahmen trifft, andere Bedürfnisse bei dem Entwicklungsprozess hat. Diese Karte dient also dazu, alle auf den gleichen Nenner zu bringen und dafür ist sie unglaublich effektiv. Dafür verwendet man ungefähr eineinhalb Stunden. An der Stelle wird dann ein Cut gemacht und es geht weiter. Im nächsten Schritt beginnt man damit, einzelne Konzepte zu generieren und das passiert in einem mehrphasigen Prozess in vier Schritten. Insbesondere bei Personen, die es nicht gewohnt sind, Notizen, Skizzen oder gar Konzepte zu zeichnen, wird versucht dieses Konzept in vier Schritten aufzubauen. Man beginnt dabei erst einmal mit losen Notizen. Jedes Teammitglied bekommt die Zeit sich noch einmal alle bisherigen Ergebnisse anzugucken und sich alles aufzuschreiben, was für wichtig empfunden wird. Im zweiten Schritt werden diese Notizen mit Skizzen erweitert. Im dritten Schritt versucht man sehr schnell viele Varianten einer Idee, die man vielleicht dazu hat, zu erstellen. Dies dient auch als Fingerübung, zum auflockern und einfinden. Am Ende des Tages gibt es dann noch einen großen Block, wo das eigene Konzept in Form von drei querformatigen Din A4 Seiten aufgemalt und auch sehr viel dazu geschrieben wird. Insbesondere darüber, wie die eigene Idee dieses Konzeptes für dieses Produkt auszusehen hat. Damit schließt der erste Tag ab. Man hat am Ende des Tages also schon Konzepte von jedem Teammitglied aus dem Sprint und die hängt man sich auch schön auf. So wie alles, was ich bisher erzählt habe, auf Papier oder Whiteboard festgehalten wird. Das ist alles sehr visuell und bleibt auch für die komplette Dauer des Sprints in diesem Raum hängen. Dadurch ist das ganze Wissen, was man sich aufgebaut hat, nicht auf einmal weg, sobald die Leute aus dem Raum gehen. Es bleibt stattdessen alles sehr transparent überall hängen. Am Ende des Tages hat man dann, wenn fünf Teilnehmer dabei waren, fünf Konzepte und schließt den ersten Tag ab.
Lucas Dohmen: Wie geht’s dann am zweiten Tag weiter?
Robert Glaser: Am zweiten Tag geht es mit einer “Vernissage” weiter. Es werden Getränke gereicht und die Leute müssen dann durch die Arbeitshöhle gehen. Also die Getränke sind optional. Man guckt sich an, was am Vortag vom Team alles produziert wurde und dann, um es ein wenig abzukürzen, geht man in einen Voting-Prozess über, der auch sehr spielerisch und visuell ist. Es werden Dot-Sticker verteilt und damit kann jeder auf diesen Konzepten an den Wänden Dinge voten oder bepunkten, die er oder sie besonders cool findet. Es kann entweder das ganze Konzept sein, dann macht man den Punkt außen am Rahmen dran oder wenn sich jemand eine coole Mikro-Interaktion überlegt hat, zum Beispiel spielerisch etwas in den Warenkorb zu legen, dann mache man einen Punkt da dran. Jeder hat eine gewisse Menge von Punkten und man kann auch mehrere Punkte an eine Sache machen, wenn man etwas pushen will, das man genial findet. Wichtig ist auch die Anonymität: es stehen keine Namen an den Lösungsansätzen. In einem kleinen Team weiß man zwar, wer die “Sauklaue” hat und von wem Konzept “A” ist, aber im Groben weiß nicht jeder, wer welches Konzept gemacht hat. Außerdem ist es wichtig, dass es in den Teamrollen immer einen “Decider” geben muss, einen Entscheider, der immer alles überteuern kann. So ein Design-Sprint ist kein basisdemokratischer Prozess, sondern nimmt sich den Realitäten aus der Produktentwicklung an. Man sagt, ein “wohlwollender Diktator” ist bei dem Entscheidungsprozess in einem Team oftmals eine gute Sache, um Dinge abzukürzen. Durch dieses Voting ergibt sich für den Decider ein Bild darüber, was viele gut finden und wohin die Reise in Bezug auf die Lösung gehen könnte. Er ist aber auch völlig frei, diejenige Lösung zur Umsetzung im restlichen Sprint zu voten, die keine Punkte bekommen hat, weil er der Meinung ist, dass das große Ganze noch nicht verstanden wurde oder weil er etwas riskieren und in die Richtung gehen will, die nicht offenkundig nützlich ist. Da ist der Decider vollkommen frei. Wir hatten bisher allerdings selten den Fall, dass alles “eiskalt übervotet” wurde. Oftmals ist es für den Entscheider sehr hilfreich zu wissen, was seine anderen Teammitglieder favorisieren. Der Entscheider wählt also eine Lösung, mit der es weiter gehen soll und die im Rest des Sprints in Form eines Protoytpen ausgearbeitet wird. Das findet dann am Mittwoch statt. Dieser Protoytp wird, wenn er fertig ist, am Donnerstag von Nutzern komplett getestet. Der Mittwoch ist für viele der anstrengenste Tag, weil dann schon zwei intensive Tage hinter dem Team liegen und das Ganze nun noch gebaut werden muss. Typischerweise gibt es dabei auch verschiedene Teamrollen.
Lucas Dohmen: Du redest jetzt über den Donnerstag?
Robert Glaser: Nein, über den Mittwoch. Mittwoch wird der Prototyp gebaut. Donnerstag ist alles vorbei, denn da laufen die Tests und dann war’s das. Am Mittwoch empfehlen wir zwei “Stitcher”. Ein Stitcher ist jemand, der alles zusammensetzt. Das sind die, die den Prototypen in einem Prototyping-Tool bauen. Wir nutzen dafür gerne “Figma”. Das Sprint Buch empfiehlt dafür beispielsweise “Keynote”, was auch nichts anderes als ein Vektorgrafikprogramm ist, mit dem man auch Dinge interaktiv zusammenführen kann. Wir finden aber, dass Figma an der Stelle besser geeignet ist.
Lucas Dohmen: Was ist Figma? Ein Vektorgrafikprogramm?
Robert Glaser: Figma ist im Grunde auch ein Vektorgrafikprogramm mit Prototypingfunktion, vor allem für remote Kollaboration. Darüber könnten wir vielleicht auch einen Podcast machen.
Lucas Dohmen: Ja.
Robert Glaser: Dann baut das Team, die zwei Sticher, den Prototypen zusammen. Die anderen sitzen dabei nicht tatenlos daneben, denn es gibt noch andere Rollen, zum Beispiel den “Gatherer”. Der Gatherer sammelt Dinge, visuelle Assets, zusammen: Logos, Schriftarten und kann, je nachdem, wie fit die Person darin ist und Lust darauf hat, Farbpaletten bauen. Außerdem sammelt der Gatherer auch Icons, die man oft haufenweise braucht. Dann gibt es den “Texter”, der Texte zusammenstellt. Am Ende soll sich der Prototyp wirklich echt anfühlen und dafür braucht man auch Texte. Der Texter textet in Absprache mit dem Team Header, Hero-Messages, Fließtexte, Erklärtexte und so weiter zusammen. So baut das gesamte Team den Prototypen an dem Mittwoch zusammen. Wichtig zu erwähnen ist auch, dass man dabei einen gewissen Qualitätsgrad anstreben sollte. Es sollte auf keinen Fall eine Software sein. Mann sollte nicht programmieren, denn dabei ist der Aufwand zu groß, um den Prototypen an diesem einen Tag zu schaffen. Es sollte aber auch kein Papier-Prototyp sein, bei dem dann die Nutzer irgendwelche Papierschemen hin und her schieben oder handgemalte Wireframes. Man will sein Produkt schon mit echten Nutzern konfrontieren und ehrliches Feedback, ehrliche Reaktionen abzapfen. Das bekommt man mit einem Wireframe, bei dem nur schemenartig Dinge erkennbar sind, nicht hin. Dabei sind die Nutzer dann mental zu sehr mit dem Übersetzungsprozess in ein echtes UI beschäftigt, der sie daran hindert oder davon abhält, sich in den Flow zu begeben und echt Aufgaben zu lösen. Die Nutzer sollen schließlich Aufgaben lösen, damit wir die Reaktionen mitschreiben können.
Lucas Dohmen: Ihr hattet so etwas schon einmal in einem Workshop mit einen Formular gezeigt: Da tippt man auf ein Formularfeld, das dann ausgefüllt wird. Das wäre also das Level von diesem Prototypen?
Robert Glaser: Ja, das ist ein gutes Level. Würde man jetzt wirklich HTML bauen, würde man dem Umfang des Sprints gar nicht gerecht werden, denn je nach Sprint-Ziel könnte man wirklich das komplette Produkt zusammenbauen. Wenn man damit beginnt, echte Formularfelder zu bauen, die jemand ausfüllen kann, dann ist der Mehrwert gering. Im Feedback nimmt man in der Menge letztendlich nicht mehr mit, als dem Nutzer klar zu machen: wenn du hier drauf klickst, dann füllen wir das schon für dich ein. Da es sich eben um einen Prototypen handelt, und das verstehen auch alle ohne den Übersetzungsprozess auf ganz niedriger Ebene zu machen, wie das Formular denn “in echt” aussehen könnte, wenn alles nur mit Bleistift gemalt wäre. Das Buch spricht in dem Zusammenhang von “Goldilocks quality”. Es sollte zwar “goldene Locken” haben, aber es ist in Ordnung, wenn der Nutzer erkennt, dass es sich um keine echte Software handelt.
Lucas Dohmen: Wir haben nun einen fertigen Prototypen am Mittwoch gebaut. Jetzt geht der Donnerstag los. Wen muss ich da einladen? Oder was passiert da?
Roman Stranghöner: Im Vorfeld muss dafür gesorgt sein, dass die Benutzergruppe durch konkrete Personen, die eingeladen wurden, halbwegs repräsentiert ist. Wir empfehlen, die Nutzer zu inzentivieren, sie nett darauf aufmerksam zu machen, dass man sehr an ihrem Feedback interessiert ist. Wir sprechen da auch lieber von Nutzern als von “Testern”. Der Begriff “Test” hat gerade bei Benutzertests einen negativen Touch, weil sie glauben, dass sie selbst getestet werden und das ist ja gar nicht der Fall. Man möchte das Produkt testen und ist auf ehrliches Feedback angewiesen. Dieser organisatorische Teil, bei dem die Nutzer vorher eingeladen werden, passiert also vorher. Dann wird der letzte Tag, in dem Fall der Donnerstag, so strukturiert, dass man im Idealfall fünf Tester hat, die jeweils eine Stunde testen. Zwischen den Tests gibt es jeweils eine halbe Stunde Zeit plus Pause. Im Vorfeld wird im Sprint eine Person auserkoren, die das Interview mit der Person führt. Dieses Interview klingt erst einmal nach Frage-Antwort, ist aber eigentlich ein sehr natürliches Gespräch, für das der rote Faden allerdings schon im Vorhinein, meistens vom Facilitator zusammen mit der Person, die dann das Interview führt, entwickelt wurde. Der Facilitator klärt auch darüber auf, wie man das Interview führt, welche Do’s and Don’ts es gibt und generiert den roten Faden, der viele wichtige Punkte innerhalb des Prototypen abklappert. Diese Punkte sollen wiederum dazu dienen, die Fragen am Anfang zu klären. Daraus ergibt sich also der rote Faden. Dann setzen sich Interviewer und Benutzer in einen anderen Raum, weil es eine sehr einschüchternde Situation sein kann, als einzelne Person vor fünf völlig durchgekämpften Menschen zu sitzen, die nach fünf Tagen Sprint schon blutunterlaufene Augen haben… nein. Jedenfalls wird das Interview in einem anderen Raum geführt und man bringt etwas Technik mit, um dafür zu sorgen, dass das Interview live in den Teamraum gespiegelt wird. Das kann man zum Beispiel mithilfe von Webcams, Mikrofon und der entsprechenden Technik aufsetzen. Robert hatte dazu auch schon einmal einen Blogpost geschrieben, wie man sich die Technik gut zu Nutze machen und ohne viel Aufwand, schmerzfrei in den Teamraum reinspiegeln kann. Eine gute Internetverbindung vorausgesetzt natürlich. Das Interview wird also mit der Person und dem Interviewer durchgeführt und auf der anderen Seite im Teamraum, hat das Team die Möglichkeit live dabei zuzuschauen, wie der Nutzer mit dem Produkt interagiert. Jedes Teammitglied schreibt für sich dazu Feedback in Form von roten und grünen Post-Its auf oder direkt digital in Form eines Spreadsheets beispielsweise. Dabei werden die Dinge aufgeschrieben, die positiv laufen und die, die eher negativ laufen. Und das macht jeder für sich, damit am Ende ein großes Bündel an Feedback mit verschiedenen Perspektiven zusammen kommt. An dieser Stelle wird auch nicht viel miteinander gesprochen oder diskutiert, was der Nutzer gerade nicht verstanden hat, sondern jeder schreibt für sich sein Feedback darüber auf, was er oder sie als Teammitglied mitkriegt und wahrnimmt. Dieser Vorgang wiederholt sich dann fünf Mal an diesem Tag. Die Zahl fünf ist nicht völlig willkürlich: Mehr ist an einem Tag auch nicht zu schaffen: nach fünf Stunden hat man schon eine ziemlich “glühende Birne”. Es ist außerdem tatsächlich so, dass fünf Nutzer schon ein aussagekräftiges Feedback darüber bilden, wie der Rest der Nutzergruppe damit wahrscheinlich interagieren wird. Dazu gibt es auch Studien von der “Nielsen Norman Group”: ein bestimmter, kleiner Satz an Personen ist für die gesamte, zu erwartende Nutzergruppe schon sehr repräsentativ. Voraussetzung ist, dass die Nutzer aus der selben Gruppe stammen, sonst muss man mit mehr Testnutzern an der Stelle rechnen. Nach den Interviews wird das Feedback vom Team komplett eingesammelt. Üblicherweise kommen Benutzer und Interviewer nach jedem Interview in den Teamraum, wo man ihnen alles noch einmal zeigt und wertschätzt, dass sie dort waren. Für die Person selbst ist es auch immer interessant zu schauen, wie denn so ein Produkt entwickelt wird und es hat bisher häufig zu leuchtenden Augen geführt, als Nutzer so miteinbezogen zu werden. Das ist einerseits ein schönes Gefühl und andererseits ein wahnsinnig erhellender Moment für Leute, die sehr intensiv an einem Produkt arbeiten und sich das ehrliche Feedback live anschauen können. Es ist wie ein Augenöffner an der Stelle, denn häufig werden Nutzertests von unseren Kunden leider nicht durchgeführt. Wenn man zum ersten Mal mit der Realität konfrontiert wird, was der Nutzer über das eigene Produkt denkt, dann hat das schon einen starken Impact. So wird das Feedback am Ende sogar noch wertvoller. Der Tag schließt also mit den fünf Interviews und einer Retrospektive von einer Stunde ab, in der noch einmal darüber gesprochen wird, was gut lief und was nicht, welche größten und besten Erkenntnisse es gab und was der größte Erfolg war. Damit wird dieser Design-Sprint dann abgeschlossen. Der Kunde hat am Ende den Prototypen, das gesammelte Feedback und eine Ergebnispräsentation von uns. Dafür machen wir Fotos von allen Ergebnissen, die während des Sprints erzielt worden sind, weil diese ja an den Wänden hängen und von den Putzkräften meistens entfernt werden. Es liegt dann beim Kunden, ob er das Ganze noch digitalisiert aufbereitet und entscheidet, ob noch ein Design-Sprint gemacht werden muss oder ob einer ausreichend ist, ob auf dieser Basis Userstories generiert oder ein MVP definiert werden soll. Was auch immer daran anschließt, weiter zu planen.
Lucas Dohmen: Du hast es schon an ein paar Stellen angesprochen: Es ist eine große Investition. Es sind viele Leute involviert und es vergeht viel Zeit. Warum denkt ihr, ist diese Investition es wert? Warum lohnt es sich, das zu tun?
Robert Glaser: Wahrscheinlich denkt man: Man muss fünf oder drei Personen aus allen Prozessen rausziehen. Vielleicht ist auch ein Marketingleiter dabei. Dazu muss man auch noch den “Nasen von innoQ” Geld dafür zahlen, dass sie uns dabei begleiten und es mit uns durchführen. Dann müssen auch noch Nutzer in Vorarbeit akquiriert werden. Wir hatten auch schon Fälle, bei denen Kunden keine Nutzer gefunden haben. Da haben wir ihnen dann auch geholfen welche zu finden. Das alles wirkt zu Beginn etwas teuer. Wenn man es aber in Korrelation mit den Problemen setzt, die man damit tackeln kann, ist das ein Witz. Es werden vier Tage mit fünf Leuten investiert und, je nach Umfang des Sprint-Ziels, das komplette Produkt oder ein sehr großer Teil davon in einem “Best-Guess” und, das ist der entscheidende Unterschied, nicht nur in einem “Guess”, entworfen und bereits validiert. Hausintern kann man sich damit bei der Geschäftsleitung durchsetzen und den richtigen Weg aufzeigen, weil das Nutzerfeedback es gezeigt hat. Oder man kann eine Strategie aufgeben, die das Nutzerfeedback als “Mist” herausgestellt hat. Was sind da vier Tage? Wir kennen alle die Situation, in der wir mit Teams Monate oder Jahre Dinge entwickelt haben, Guesses, die wir mal gemacht und implementiert haben und sich dann zeigt, dass es vollkommen am Ziel vorbei geht oder dem Ziel nicht dient: Es wird nicht mehr Umsatz oder mehr Conversions gemacht. Aus der Perspektive betrachtet, sind vier Tage noch eher ein Witz, ein “No-Brainer” an der richtigen Stelle in einen Design-Sprint zu investieren. Der entscheidende Unterschied ist, dass ein Design-Sprint den Best-Guess liefert und nicht nur einen Guess und die Validierung dessen. Das finde ich immer sehr überzeugend und das finden auch viele unserer Kunden.
Lucas Dohmen: Ich danke euch für diese gute Übersicht.
Roman Stranghöner: Sehr gerne.
Lucas Dohmen: Das Buch, in dem man noch etwas mehr erfahren kann, werden wir verlinken. Danke für’s zuhören und bis zum nächsten Mal.
Robert Glaser: Unser dritter Interviewpartner hat leider die ganze Zeit geschlafen und ist jetzt aber aufgewacht. Er könnte also auch noch etwas sagen, aber er geht gerade zum Trog.
Lucas Dohmen: Dann auf Wiedersehen.
Roman Stranghöner: Auf Wiedersehen.Ciao.
Robert Glaser: Danke, Tschüss.