Prototyping

Lucas Dohmen: Hallo und herzlich Willkommen zu einer neuen Folge des INNOQ Podcasts. Heute wollen wir über das Thema Prototyping, Wireframes und Mock-ups reden, und dafür habe ich mir den Roman eingeladen. Hallo Roman!

Roman Stranghöner: Hallo Lucas!

Lucas Dohmen: Roman, möchtest du dich mal kurz vorstellen?

Roman Stranghöner: Ja, für alle die, die mich noch nicht kennen, mein Name ist Roman Stranghöner, ich arbeite als Senior Consultant bei INNOQ, schon seit guten 9 Jahren, und kümmere mich eigentlich vorwiegend um Frontend-Themen und vor allen Dingen um Benutzeroberflächen, alles was damit zusammenspielt, insbesondere die weicheren Themen wie User Experience und UI-Design, Produktentwicklungsmethodiken, all diese Dinge fallen in meinen Themenschwerpunkt.

Lucas Dohmen: So in den letzten Jahren hat sich das bei dir auch so ein bisschen heraus gestellt dass du weniger mit HTML und CSS zu tun hast, sondern mehr auch so in dem Prototyping Bereich.

Roman Stranghöner: Genau, also sagen wir mal in dem konzeptionellen Bereich, also auch Prototyping, aber ich auch viel Workshops leite, bei denen es auch um Methodiken geht, mit Post-its und viel Zeug am Whiteboard.

Lucas Dohmen: Wir hatten schon mal eine Folge zusammen aufgenommen, zusammen mit Robert, über Design-Sprints. Und da hatten wir schon mal ein bisschen an das Thema angeschnitten, wollten es aber nochmal aufgreifen und ein bisschen ins Detail gehen. Und das erste was mir da so ein bisschen einfällt ist, dass es da so drei Begriffe gibt, Prototyp, Wireframe, Mock-up - “Mock” manchmal auch -, die alle so im Raum schweben und wo man manchmal nicht so weiß: ist das das Gleiche, ist es was Verschiedenes, kannst du das ein bisschen einordnen, was das für Begriffe sind?

Roman Stranghöner: Ja. Tatsächlich kommen die sogar alle mehr oder weniger auch im Design-Sprint vor, aber der Prototyp ist ja so ein bisschen prominenter aufgehängt. Also wenn man sich so reine Konzeptarbeit vorstellt - Wie soll eine Benutzeroberfläche, ein Benutzerflow, eine Journey aussehen? - brauchen wir ja dafür ganz verschiedene Dinge auf konzeptioneller Ebene. Und da fängt man üblicherweise, also wenn man sich so eine Achse vorstellt, auf der man den Detailgrad abbildet, hat man ja so Dinge wie erste Skizzen, die noch sehr rudimentär sind und sehr wenig Detailgrad haben, und man hat am Ende ein fertiges Design, wo wirklich alles eins zu eins aussieht wie es später mal in der Anwendung aussehen soll. Das wären so die beiden Extreme auf einer Achse. Und dann kann man eigentlich Wireframes eher auf der linken Seite dieser Achse ansiedeln, also etwas was vielleicht kurz nach irgendwelchen Skizzen kommt. Und einen Prototypen eher sehr weit rechts auf dieser Achse, weil es im Prinzip ein mehr oder weniger fast identisches Abbild dessen sein soll was später mal umgesetzt wird. Und in der Mitte hätte man sowas wie Mocks, oder Mock-ups, und da ist der Detailgrad ein bisschen mehr auf das Design ausgerichtet. Also während wir bei Wireframes eher über die Anordnung von Dingen reden, also Layouts, welcher Content kommt wo hin, dann wäre das eher ein Skelett, oder ein Bauplan, dann wäre der Sinn und Zweck des Mock-ups eher das Design drum herum quasi zu entwickeln. Du brauchst sowohl das eine als auch das andere und im Prototypen führst du mehr oder weniger beide Dinge zusammen, und reicherst das ganze dann nochmal um einen Grad an Interaktivität an. Also wenn man sich jetzt beispielsweise einen Warenkorb bzw. einem Check-out Prozess vorstellt, dann würde ich den jetzt als erstes wireframen und mir grob überlegen, wo müssen welche Elemente hin, wie muss ich die einzelnen Positionen in diesem Warenkorb anordnen, wird die Gesamtsumme angezeigt, welche Knöpfe muss ich unten drunter anbieten, was ist die Primäraktion, was die Sekundäraktion, usw. Dann würde ich anfangen vielleicht das Design drum herum, wenn es noch nicht da ist, dazu zu bauen, und da geht es dann tatsächlich eher um optische Dinge. Also ist der Primärbutton gelb, oder rot, oder blau oder sowas, auf diesem Detailgrad, da geht es wirklich nur um Optik, aber ich brauche den Bauplan trotzdem schon um dann mehr oder weniger die Seite zu mocken. Aber da steht sonst noch keine Art von Interaktivität dahinter, das geht erstmal nur um die Positionierung und die Optik. Und beim Prototypen könntest du dann wirklich anfangen mehrere Seiten hintereinander, oder mehrere Mocks hintereinander zu klemmen, und Seitenünergänge zu definieren. Also wenn ich auf diesen Knopf drücke lande ich am Ende vom Warenkorb auf dem nächsten Screen, also dem gemockten Screen und sehe dann die Zahlungsbestätigung, und wann versendet wird und sowas. Das wär im Prinzip von den verschiedenen Detailgraden, von ganz ganz wenig Details hin zu maximal vielen Details, das hätte man im Prinzip alles abgedeckt, und so kann man die auch ein bisschen voneinander abgrenzen.

Lucas Dohmen: Das heißt aber die haben wirklich verschiedenen Zweck, das ist nicht so dass das eine besser ist, die bessere Version?

Roman Stranghöner: Nein nein, also tatsächlich verfolgen alle drei Designartefakte, wenn man sie jetzt von mir aus so nennen will, unterschiedliche Zwecke. Ein paar Sachen habe ich gerade schon genannt, also beim Wireframe geht es erstmal darum, überhaupt Informationsarchitektur so ein bisschen zu betreiben, zu überlegen wo kommen welche Dinge hin, was folgt aufeinander, wie setze ich Dinge in Kontext, welche Art von Informationen brauche ich an dieser Stelle. Auch da spielt der eigentliche Content tatsächlich schon eine große Rolle. Also lorem ipsum ist selbst schon bei Wireframes eigentlich keine gute Idee. Je eher ich echten Content habe, desto besser, auch im Wireframing. Das ist auch die Art Konzeptarbeit, die man gemeinsam tut. Also Wireframes sind eigentlich eine Sache die man im gesamten Team oder mit vielen Teammitgliedern gemeinsam erarbeitet. Das ist keine reine Designarbeit, das wäre dann eher so, also Mocks selbst werden ja eher so eingesetzt um die Optik zu definieren, und das ist dann schon eher typische Designarbeit. Und der Sinn und Zweck von Mocks ist dann auf jeden Fall den Look zu definieren. Und bei Prototypen ist ganz klar der Test, also ein Prototyp an sich ist eigentlich ein Test, aus Entwicklungssicht ein bisschen wie Test Driven Design, also man definiert im Prinzip eine Art von Annahme: das ist jetzt Feature xy und wir wollen jetzt wissen, sollten wir das bauen oder nicht, das ist quasi unser Test dafür. Und diesen Test bauen wir dann eben so nah wie möglich an das was es mal später werden soll heran, also vom Detailgrad her. Wenn wir das erreicht haben, dann können wir das dem Endnutzer vor die Nase halten und ihn das ausprobieren lassen und dann dabei herausfinden lassen ob es tatsächlich so benutzt wird wie es eigentlich mal geplant war und ob man das Feature so umsetzen kann oder nicht.

Lucas Dohmen: Okay, lass uns doch einfach nochmal bei dem niedrigsten Detailgrad anfangen und kurz über Wireframes reden. Wenn du jetzt einen Wireframe bauen möchtest, was würdest du denn dann benutzen dafür?

Roman Stranghöner: Also ich bin ein großer Freund von Stift und Papier bzw. Whiteboard und Whiteboardmarker. Wie ich es eben schon angerissen habe, ich glaube das ist eine Aktivität die man auf jeden Fall im Team tun sollte, das ist nichts was hinter der verschlossenen Tür passieren sollte. Wireframes oder generell diese Konzeptarbeit lebt ja davon dass man gemeinsam etwas erarbeitet. Man hat sich ein gemeinsames Grundwissen über eine Funktionalität erarbeitet und nur am Whiteboard hab ich das Gefühl, dass alle von den selben Dingen reden und das Gleiche meinen, denn wenn wir es eben visualisieren, dann wird sehr schnell klar, ob wir über das Gleiche reden und alle glauben wir reden über das Gleiche, aber erst dadurch, dass man es hinmalt erkennt man: oh so hab ich das jetzt nicht verstanden, aber gut, dass wir es mal aufgemalt haben. Und dieser Aha-Moment geht verloren, wenn man an der Stelle schon irgendwelche Tools einsetzt. Klar gibt es auch digitale Tools für Wireframing, ich habe aber im Projektkonktext sehr gute Erfahrungen gemacht, wenn man das tatsächlich in seinen Entwicklungsalltag einbaut, wenn man sich die entsprechenden Leute schnappt, die man für die konzeptionelle Vorarbeit für so ein Feature braucht, dass man sich die zusammen sucht und sowas relativ schnell und pragmatisch am Whiteboard löst.

Lucas Dohmen: Auch mit der Idee, dass die Leute vielleicht ein kleineres gestalterisches Talent haben, trotzdem sich befähigt fühlen, da mitzumachen.

Roman Stranghöner: Unbedingt! Guter Punkt. Das schöne an Stift und Papier ist, bzw. Whiteboard und Whiteboardmarker, dass die Hürde daran mitzuarbeiten sehr gering ist, auch für Leute die jetzt erstmal denken, “ich will aber nicht malen”. Beim Wireframing geht es ja ganz bewusst um wenig Detailgrad, also meistens besteht das aus nicht viel mehr als irgendwelchen Dreiecken und Quadraten, bisschen Text, und ein paar Linien, selbst wenn die nicht gerade sind - das ist schon okay, das versteht man auch relativ schnell, auch als jemand der jetzt gewisse Hürden hat, selbst den Stift zu nehmen und da einfach drüber zu malen. Und das ist etwas, das verliert man mit einem Tools komplett, denn sobald man in diesem kreativen Gedanken und Wissensaustausch auf einmal so ein Tool als Barriere dazwischen ist, dann ist man als jemand der da nicht so 100%ig drin ist eher gehemmt sich mit einzubringen. Und ich finde das ist ein schönes Mittel um alle mehr oder weniger dran teilhaben zu lassen, das ist eine sehr inklusive Veranstaltung. Und ein Tool wirkt dem eher entgegen, meiner Erfahrung nach.

Lucas Dohmen: Also ist es für dich auch nicht wünschenswert, dass beispielsweise du stehst vorn am Whiteboard und jemand anderes sagt dir, jetzt mal doch mal das und das da hin, sondern das sollte die Person eigentlich lieber selber machen, um das dann auch umzusetzen?

Roman Stranghöner: Das kommt so ein bisschen drauf an, wie gut man sich mit denjenigen, also wenn man das zu nehmen weiß ist das schon okay, wenn die Person auch wenn sie gerade Anweisungen gibt sich trotzdem einbringt, kann ich damit sehr gut leben, wenn ich aber merke, ich zeichne quasi die Dinge ans Whiteboard, und es kommt auch sonst nichts - also nicht mal, mach mal lieber so und so, sondern einfach gar nichts, dann ist das halt schon eher ein Problem. Also wenn das dazu führt, dass Leute dann abschalten in solchen Meetings und eigentlich nur noch so passiv konsumieren, dann ist das eher ein Problem. Aber wenn sich aktiv eingebracht wird und ich nur derjenige bin der den Stift führt, ist das auch okay. Immer noch besser als gar nichts.

Lucas Dohmen: Ja. Ich könnte mir schon vorstellen, dass du versehentlich quasi Autorität ausstrahlst, dadurch dass du den Stift in der Hand hast und dann vielleicht jemand sagt, das hab ich vielleicht nicht gemeint, aber das was Roman macht, das ist schon irgendwie cooler.

Roman Stranghöner: Sowas kann man relativ schnell glaube ich aushebeln, indem man entweder um Erlaubnis fragt, oder aber den Leuten direkt den Stift in die Hand drückt. Dann ist eigentlich relativ schnell klar, dass alle daran beteiligt sind und nicht einer vorturnt und einer sitzt daneben und macht den Daumen hoch oder runter.

Lucas Dohmen: Okay! Jetzt haben wir zum Wireframe so ein gemeinsames Verständnis erzeugt. Was wollen wir jetzt erreichen, wenn wir jetzt den Mock-up machen? Wer tut das erstmal, und was ist unser Ziel?

Roman Stranghöner: So ganz grundsätzlich kann man Mock-ups losgelöst vom Wireframe beginnen umzusetzen, weil es da ja wie gesagt eher um Optik geht, um “passen die Dinge zusammen”. Es gibt ja relativ generische, ich sag mal UI-Bestandteile, die man miteinander in Beziehung setzen kann, ohne dass da schon erstens der echte Content drin steht und ohne dass es schon in dem Kontext einer Seite passiert. Also die Optik eines Buttons kann ich diskutieren ohne dass ich schon das drum herum habe. Die Optik von einer Kachel, wo ein Vorschaubild drin ist und Text und und und, da brauche ich schon ein bisschen mehr, da brauche ich einen groben Bauplan. Aber wenn es um die rein optischen Dinge geht wie Typografie, Farben, bestimmte Form von Links oder Buttons und irgendwelchen anderen Interaktions- und Formelementen, dann kann ich das schon relativ losgelöst von irgendwelchen Features oder Seiten tun. Es wird dann interessant wenn man Richtung Wireframe geht, denn dann werden die Dinge zusammen gesetzt. Man will dann eine ganz bestimmte Ausprägung testen, von einem Nutzer, von einer bestimmten Journey oder einem bestimmten Feature, das der Nutzer ausführen soll.

Lucas Dohmen: Aber das ist eine Arbeit, die macht jetzt schon jemand der im UI-Bereich ist?

Roman Stranghöner: Üblicherweise schon. Üblicherweise ist das typisches UI-Design und da gibt es dann, mal abgesehen von einer Inspirationsphase, wo man wie in einem Moodboard anfängt die Dinge zusammenzusuchen, die man schön findet oder passend findet, ist man dann relativ schnell in so einem Tool drin - klar, es gibt Designer die mit Stift und Papier anfangen und Dinge erstmal skribbeln, aber wenn es um die Umsetzung geht ist man ja dann relativ schnell dabei, ein Vektorgrafikprogramm zu nutzen, oder Photoshop, oder was weiß ich. Also eigentlich ist Sketch ein populärer Vertreter oder InDesign. Es gibt tausende Tools, ist eine Geschmackssache.

Lucas Dohmen: Wir haben an anderer Stelle schon über Komponenten gesprochen. Was verstehst du denn darunter? Für die Hörer und Hörerinnen, die das vielleicht nicht kennen.

Roman Stranghöner: Als ‘Komponenten’ ist ein sehr generischer Begriff, kann alles und nichts bedeuten. Es gibt verschiedene Metaphern dafür, um Komponenten ein bisschen besser einsortieren zu können. Sehr populär ist dieses Atomic-Design von Brad Frost, der versucht zu unterscheiden, was sind sehr generische Komponenten, kleingliedrige, und wie setzen die sich später wieder zusammen. Ein Beispiel ist so ein Button, den kann man nicht weiter zerteilen, also ist es atomar, ein Atom, währenddessen so eine Kachel mit Vorschautext und Primäraktion, ist dann eher ein Molekül, zusammengesetzt aus einzelnen kleinen Atomen. Und diese Komponenten kann man ja sehr losgelöst in diesem Kontext zumindest was die Optik angeht entwickeln. Und das kann man üblicherweise mit relativ guten Tool-Support losgelöst tun. Also es gibt sowohl in Sketch als auch in Figma die Möglichkeit eine Bibliothek anzulegen mit verschiedenen Komponenten. Das heißt in Figma tatsächlich Components, in Sketch sind es Symbols oder so. Aber das meint alles das gleiche: man baut so Komponenten als generische wiederverwendbares Ding, und dann setze ich die quasi in meine Designs ein, und dann ändere ich zum Beispiel nochmal den Text da drin, und dann passt sich das dynamisch an. Aber eigentlich verwende ich immer den selben Bauplan, definiert durch Layout, Farbe und was sonst noch so dazu gehört.

Lucas Dohmen: Der Aspekt der Wiederverwendbarkeit ist dann quasi schon vorgesehen? Also wenn ich in dem Button sage, der Borderradius ist 50 statt 5, dann ändert sich das global an allen Stellen?

Roman Stranghöner: Das ist der Vorteil davon. Also wenn man an früher denkt, wo man mit Mocks immer Photoshop in Verbindung gebracht hat, und diese tausend Photoshop-Dateien mit verschiedenen Ebenen, und jetzt kannst du dir ja vorstellen, wie so ein Screenflow bestehend aus so 5, 6 Seiten, mühevoll zusammengesetzt in Photoshop, wenn du da einen Button ändern willst musste natürlich durch alle Seiten durch - und das will man nicht, und das kann man in diesen Tools verhindern, indem man diese Komponenten nutzt.

Lucas Dohmen: Das heißt, da ist Photoshop eigentlich das falsche Tool gewesen um das zu tun.

Roman Stranghöner: Meines Erachtens nach war das schon immer das falsche Tool um Webseiten zu bauen.

Lucas Dohmen: Gut also wir haben jetzt den look und nicht das feel, wir können schon was testen, das heißt wir haben schon Wireframes gebaut, haben Mock-ups für verschiedene Komponenten, und jetzt kommen wir zum Prototypen. Benutze ich da jetzt Sachen aus dem Mock-up?

Roman Stranghöner: Genau also ein Mock-up ist ja wenn man so will eine Zusammensetzung aus verschiedenen Komponenten aus verschiedenen Kontexten, keine Ahnung, eine Seite in meiner Anwendung, sei es jetzt eine mobile App oder eine Website, ist ja auch egal, aber eine konkrete Ausprägung. Und was ich mit dem Prototypen verproben möchte ist ja nicht das look and feel davon, also auch aber indirekt, aber was ich eigentlich testen will ist, ob der Flow passt. Ist das was der Nutzer da Schritt für Schritt in seiner Journey erreichen soll, erreicht der das tatsächlich, erreicht er sein Ziel am Ende? Dafür ist der Prototyp ja eigentlich der ultimative Test, das heißt wir setzen im Prototypen die einzelnen Schritte mehr oder weniger zusammen, also die einzelnen gemockten Seiten wenn man so will. Und dann definiert man die aktiven Elemente in so einem Mock, beispielsweise einen Button oder einen Link und definiert dann den Seitenübergang in eine andere gemockte Seite. So kann man sich das ungefähr vorstellen. Man klickt eigentlich mehr oder weniger Pfeile zu diesen einzelnen gemockten Seiten und bildet damit den Flow quasi ab. Bei so einem Prototyp wird so viel gefaked wie nötig ist, damit der Nutzer sein Endziel erreicht, aber nicht mehr. Also wir fangen nicht an, in einem Prototypen alle erdenklichen Wege auszudefinieren, sondern nur einen konkreten und den wollen wir testen, und nicht mehr. Und dann ist unser Test eigentlich beendet.

Lucas Dohmen: Ja, verstehe. Also das ist mehr wie so ein choose-your-own-adventure-Buch, wo man sagt: “Wenn du das machen willst, geh auf Seite 12, und wenn du das machen willst, geh auf Seite 20.” Und ich kann da jetzt nicht meinen Namen zum Beispiel eingeben…

Roman Stranghöner: Ah das ist auch noch ein guter Punkt, das kommt ein bisschen drauf an, was ich für meinen Prototypen eigentlich verwende. Der Prototyp an sich ist ja nur ein Test, aber wie ich den Test implementiere ist ja meine Sache. Das kann ein Prototyping-Tool sein, das kann ein Paper Prototype sein, das kann irgendwas physisches sein, wenn zu irgendeinem Produkt nicht nur Software gehört sondern auch was zum anfassen. Das kann aber auch schon eine statische Website sein, bestehend aus HTML, CSS und JavaScript. Und je nachdem, was ich da so benutze, kann ich natürlich unterschiedliche Dinge tun. In diesen statischen oder ziemlich doofen Prototyping-Tools ist es üblicherweise nicht möglich dass du jetzt anfängst Textelemente zu definieren, wo du Text eingeben kannst, dann Formvalidierung und so was. Es gibt diese Ansätze, es gibt mittlerweile auch ein paar Tools, die das können. Nach und nach entwickeln die sich quasi ein bisschen mehr in Richtung der eigentlichen Anwendung, also, man definiert dann Dinge die man in der Anwendung dann nochmal definiert, aber meiner Erfahrung nach ist das ein Detailgrad der da gar nicht nötig ist, nicht zwangsläufig. Und man sollte natürlich das Implementierungsmittel für den Prototypen immer sehr bewusst auswählen, und sich das richtige Werkzeug für den Job suchen. Da muss man dann etwas aufpassen was man da für Mittel nimmt, und wieviele Möglichkeiten es gibt, einen Test zu definieren.

Lucas Dohmen: Okay und mit welchem Tool würdest du jetzt so einen Prototypen bauen?

Roman Stranghöner: Wie gesagt, dass kommt ein bisschen darauf an, was dieser Test erreichen soll. Nehmen wir jetzt mal so eine übliche Enterprise-Webanwendung. Also eine die nicht massenhaft Text verarbeitet, wo man jetzt super viele Formulare, und Dinge einfach drin hat. Da nutzen wir häufig Figma. Mittlerweile gibt es auch in Sketch die Funktion zu prototypen. Das ist halt deshalb schön, weil es sehr nah an den Mocks dran ist, also man muss dann nicht quasi diesen Medienbruch nochmal irgendwie überbrücken sondern ist relativ nah dran an dem was schon da ist. Wenn die Mocks da sind ist es viel einfacher ein paar Pfeile in dem Tool zu ziehen, als wenn ich jetzt sage, meine Mocks sind da, jetzt fange ich erstmal an, alles, keine Ahnung, in irgendeinem anderen Prototypen zu übertragen der dann nicht in diesem selben Tool drin ist. Das ist zum Beispiel früher, bevor es noch Figma und Konsorten gab, gab es ja ein sehr prominentes Tool namens Invision, was im Prinzip nur Prototyping gemacht hat und wo man dann im Prinzip das Design rein geworfen hat. Also das Sketchfile oder das Illustratorfile, und dann da drin das Prototyping gemacht hat. Aber diese Brüche dazwischen führen ja eigentlich zu Mehraufwänden die man ja eigentlich nicht haben will. Deshalb bin ich ein großer Fan davon, wenn alles im selben Tool drin ist. Und die Entwicklung ist ja auch genau in diese Richtung, von daher ist das glaube ich schon eine ganz gute Sache.

Lucas Dohmen: Aber auch wenn es ein Tool ist ist es für dich auch schon wichtig, mental die Grenze zu ziehen: Mache ich jetzt gerade einen Mockup oder mache ich gerade einen Prototyp, oder? Weil wir jetzt schon gerade verschiedene Sachen verfolgen dabei.

Roman Stranghöner: Ja, genau. Also das Ziel ist halt immer ein anderes, wie wir am Anfang schon gesagt haben. Das Ziel von einem Mockup ist ein Design zu definieren, und das Ziel von einem Prototypen ist, das Zusammenspiel aus allem quasi zusammen zu testen. Also sowohl aus Layout, als auch aus Design, als auch aus Nutzerführung, als auch aus Informationsarchitektur - da testet man ja halt wirklich alles Ende-zu-Ende wenn man so möchte, ohne dabei tief ins Detail zu gehen, sondern man prototyped ja genau nur das bisschen was man am Ende braucht um den Nutzer von A nach B zu bringen, und nicht etwas darüber hinaus.

Lucas Dohmen: Okay. Und was sind dir im Alltag schon für Fallstricke begegnet, wo Leute Fehler machen in einem von diesen drei Bereichen, wo du sagst, das sollte man vermeiden.

Roman Stranghöner: Der erste Klassiker ist halt, diese Dinge alle durcheinander zu werfen. Oder nicht zu wissen, was die Unterschiede sind, und was eigentlich Sinn und Zweck von diesen verschiedenen Artefakten ist. Das wäre schon mal so ein Klassiker, also einen Prototypen für etwas zu nutzen wofür er dann eigentlich gar nicht gedacht ist, also vielleicht als Dokumentation, oder als, ich weiß nicht, also einfach dass der Sinn und Zweck von diesem Prototypen eigentlich ist, dass man etwas testet, das nicht verstanden zu haben, sondern im schlimmsten Fall als Komponentenbibliothek betrachtet, die dann ganz viele verschiedene zusammengesetzte - also alle Wege in meiner späteren Anwendung quasi erstmal vorprototype, und dass man immer in einem gesamten riesigen Prototype bleibt, der am Ende genauso aussieht wie meine Anwendung - also solche Sachen, die passieren halt gerne mal. Wenn man sich schwer von Dingen lösen kann. Also wenn man einmal so ein Teil gebaut hat sollte einem auch immer klar sein, so ein Prototyp ist eigentlich zum wegschmeißen. Ist auch in der Software-Entwicklung ein Klassiker - proof-of-concept, man probiert irgendwas aus, ob es technisch überhaupt geht, und dann, auf einmal ist es schwupps in der Produktion.

Lucas Dohmen: Mit allen work-in-progress-flags.

Roman Stranghöner: Genau, und fix-me und to-dos und comment-outs.

Lucas Dohmen: Ja.

Roman Stranghöner: Also das gibt es definitiv auch, sollte man sich ein bisschen von lösen, auch von den eigenen Ideen, die da drin vielleicht umgesetzt sind. Also auch das ist so ein Klassiker, wenn der PO vielleicht sehr an seiner Idee hängt die dann da geprototyped ist, dann der Nutzertest irgendwie am Ende verrät: vielleicht doch nicht so eine gute Idee dieses Feature, und der PO dann vielleicht der Meinung ist, dann haben wir die falschen Nutzer… das ist auch noch so ein beliebter Klassiker dafür. Dass die eigenen Idee so gehegt und gepflegt werden, dass man Schwierigkeiten hat sich davon zu lösen. Man muss häufig klar machen, dass es eigentlich darum geht, die Idee zu validieren, und wenn die Validierung “mh, nö, keine gute Idee”, dann lassen wir das, dann schmeißen wir das alles in die Tonne und dann bauen wir was anderes. Oder passen es an. Muss ja nicht immer heißen, dass man alles weg wirft, aber dass man es zumindest vielleicht anpasst.

Lucas Dohmen: Ja, das habe ich auch schon häufiger in Projekten erlebt. Wenn ich mir das jetzt so ein bisschen anhöre, wie du das erzählt hast da klingt es für mich so ein bisschen nach so einem Wasserfall. Irgendwie am Ende kommt so ein Prototyp raus, und dann endet hier diese Arbeit. Dann wirft das jemand über einen großen Zaun, auf der anderen Seite stehen die Code-Monkeys bereit, um HTML und CSS daraus zu bauen. Das ist ja vermutlich nicht das was du vorschlägst. Wie muss ich mir diese Zusammenarbeit vorstellen? Wann gibt es eine Übergabe und gibt es ein hin und her, wie funktioniert das?

Roman Stranghöner: Also, im Idealfall haben wir ein Cross-funktionales Team, was so ein Feature umsetzt, und das arbeitet auch zusammen. Also da gibt es keine Designabteilung und keine UX-Abteilung und keine PO-Abteilung, und die reden alle nur über Jira-Tickets miteinander, sondern die sitzen alle zusammen und erarbeiten Dinge gemeinsam. Das ist ja schon mal so eine Grundvorraussetzung. Und dann, wenn es dann darum geht von einer Idee zu einem fertigen Feature zu kommen hat man natürlich vorab ein bisschen Konzeptphase, das ist klar. Der springende Punkt ist aber, dass nicht alles vorkonzeptioniert wird, wie beim Wasserfall von mir aus, dass wir nicht alles vorab designen, sondern immer nur schrittweise, in kleinen Iterationen das was wir eben als nächstes machen wollen. Weil ein bisschen Konzeptarbeit vorher braucht man eben schon, das heißt, was sich bei uns ganz gut angeboten hat ist, die Sprints so ein bisschen phasenversetzt voneinander zu haben, sodass man die Konzeptarbeit in einem Sprint vorher gemeinsam mit dem Team natürlich erarbeitet. Also es wird genauso commitet und genauso eingepreist sag ich jetzt mal, im Sinne von: wir brauchen mehr Zeit für Konzeptarbeit wie normale Userstories beispielsweise. Und dann werden die genauso erarbeitet, da werden von mir aus Wireframes erstellt, die fließen dann zusammen mit der Userstory die dann im nächsten Sprint bearbeitet werden kann, oder in einem der nächsten Sprints, da fließt das ganze dann ein. Im Idealfall hab ich dann auch noch das Thema, dass ich dann alle notwendigen Komponenten vorher gemockt habe, dass das Design feststeht dafür, und ultimativ wäre es natürlich auch schön wenn man in bestimmten Abständen, und das muss nicht immer unbedingt ein Sprint sein, aber zumindest mal, wenn man so eine größere Userjourney vor sich hat, oder ein Epic, dass man solche Dinge prototypisch umsetzt vorab, und die tatsächlich verprobt bevor man anfängt die zu entwickeln. Und das kann dann durchaus auch ein bisschen mehr als ein klassischer Entwicklungssprint sein, der dann phasenversetzt vorab passiert, sondern das können dann durchaus mehrere sein. Es lohnt sich ja nicht immer für jedes kleine Mini-Feature fünf Leute ran zu karren die das ganze testen, sondern da macht es natürlich schon Sinn wenn man größere Teile hat, die man abtesten kann. Eine weitere Möglichkeit ist natürlich auch, dass das gesamte Team einen Designsprint zwischendurch macht, bevor es auf eine neue Journey beispielsweise zusteuert, oder herausgefunden werden soll ob man jetzt das Feature so oder so umsetzt, da kann man so einen Designsprint eigentlich immer schön zwischendurch einstreuen, um diese konzeptionelle Arbeit sehr konzentriert innerhalb von fünf Tagen zu leisten, gegenüber, keine Ahnung, einem klassischen Sprint von zwei Wochen.

Lucas Dohmen: Das heißt so ein Designsprint ist nichts was nur am Projektanfang passiert, das kann auch immer mal zwischendurch passieren?

Roman Stranghöner: Ja, also es muss nicht, aber es ist ein schönes probates Mittel um das zumindest mal für größere Dinge, die zumindest viel Risiko birgen - also das ist ja eigentlich das, was man verhindern will, man baut das falsche, versenkt viel Geld in die Entwicklung und stellt am Ende fest: war doch nicht so clever, das jetzt zu bauen. Das will man ja gerade damit verhindern. Und das kann man durchaus öfters tun, in der Entwicklungsphase, zumal ja die meisten Anwendungen oder die meisten Projekte die wir betreuen eine gewisse Größe haben, das ist ja nicht so, dass wir irgendwie so ein kleines Mini-Feature bauen und dann wieder raus sind, sondern der Entwicklungsprozess ist deutlich länger, und da kann man das sehr schön projektbegleitend immer mal wieder zwischendurch einstreuen.

Lucas Dohmen: Okay. Gibt es noch irgendwas was ich dich hätte fragen sollen?

Roman Stranghöner: Ich weiß nicht, nein. Prototyped auf jeden Fall eine Menge! Ich glaube, wir haben zwar oft Projekte, die vielleicht nur annähernd Produktcharakter haben. Aber man kann sich auch für Enterprise-Anwendungen, die jetzt nicht der klassischen App aus dem iOS-Store gleichen, viele Dinge aus der Produktentwicklung raus greifen, die auch da super funktionieren. Und Prototyping und Wireframing, dieses wie kommen wir eigentlich da hin, die richtigen Dinge zu bauen, das funktioniert auch in Enterprise-Anwendungen prima. Wir sind große Befürworter davon, das in den regulären Projektalltag mit zu integrieren, sodass man dem Kunden gegenüber jederzeit guten Gewissens die richtigen Features bauen kann, und ihn dabei auch unterstützt, die Dinge in die richtigen Bahnen zu lenken, bevor es aus dem Ruder läuft, und das kann man eben mit solchen kleinen Tests eigentlich ganz gut erreichen, die man zwischendurch fährt.

Lucas Dohmen: Na für mich klingt es auch so ein bisschen nach einem Weg, Kosten zu sparen. Wenn man schon feststellt, dass das Wireframe Müll ist, dann muss man nicht erst die Java-Anwendung fertig gebaut haben, sondern dann hat man die Kosten gespart und hat vielleicht drei DIN A4-Seiten investiert.

Roman Stranghöner: Ja, oder eine Session bestehend aus einer Stunde und drei Leuten die sich mal kurz austauschen, das ist auf jeden Fall eher zu verkraften als so ein ganzes Feature.

Lucas Dohmen: Super, dann danke ich dir für deine Zeit.

Roman Stranghöner: Sehr gerne.

Lucas Dohmen: Und dann sage ich den Hörerinnen und Hörern: bis zum nächsten Mal.

Roman Stranghöner: Tschau!

Lucas Dohmen: Tschüss!