Lean UX - In Windeseile zum ersten Prototyp Release

Lean und Konzern? Geht das? Jawohl.

Die Zeiten der monatelangen Software Entwicklung sind vorbei. Wir sollten unsere Software nicht in mühevollen Konzeptionsprozessen ausdefinieren ohne zuvor auch nur einmal mit den Endanwendern gesprochen zu haben. Lean UX ermöglicht uns diesen Ansatz.

Wer kennt ihn nicht? Eric Ries mit seinen Lean Startup Methoden: „Build. Measure. Learn.“ Seit der Veröffentlichung seines Buches im Jahre 2014, welches sich ursprünglich mit der Unternehmensgründung beschäftigte, sind ihm viele mit seinem „schlanken“ Konzept in anderen Bereichen gefolgt. Egal ob es um Lean Trading mit Aktien im Finanzsektor geht oder um Lean UX in der Software-Entwicklung. Alle nehmen sich die drei Ries’schen Begriffe für ein erfolgreiches Vorgehen zum Vorbild. 

Nun beschäftigen wir uns bei SprintEins mit Software, weshalb ich gerne bei Letzterem bleiben möchte – obwohl das Thema Aktien mich seit einiger Zeit ebenfalls interessiert.

Lean und Konzern? Geht das? Jawohl. Wer im Zeitalter der digitalen Welt noch Monate, gar Jahre benötigt, sein mühevoll entwickeltes Produkt zu releasen – um dann zu bemerken, dass es beim Endnutzer doch nicht so ankommt wie gewünscht – der sollte seine Unsicherheiten ablegen und ebenso wie beim Trading ein bisschen risikofreudiger sein.

Die Zeiten sind vorbei, in denen wir monatelang irgendwelche Power Point Präsentationen mit Product Benefits für das Upper Management vorbereiten, in denen wir anschließend Agenturen beauftragen wochenlang in diversen Korrekturschleifen irgendwelche „fancy“ Visual Designs mit sequentiell erstellten Animationsvideos oder sonstigen Mockups umzusetzen. Die bisherige Folge daraus: Man sieht den Wald vor lauter Bäumen nicht mehr.

Gemeint sind die altbekannten User Needs, die möglicherweise zu wenig adressiert wurden. Bevor wir allerdings einen Need definieren, sollten wir zunächst die eigentlichen Probleme identifizieren. Und diese lassen sich weder über irgendwelche schön gestalteten Visual Designs noch über ein Dutzend Power Point Präsentationen oder gar ein kundenseitiges Lastenheft definieren. Ich behaupte einmal, Software Designer können sich im Rahmen einer festgesetzten Timebox ein genaues Bild zum IST-Stand des abzubildenden Software-Prozesses machen – je nach dem Grad der Komplexität innerhalb von ein bis zwei Wochen. 

Die richtigen Probleme lösen. Während der Analyse des IST-Standes sollten die Probleme der Nutzer bzw. unterschiedlichen Nutzerrollen identifiziert und Personas und Nutzungsszenarien definiert werden. Innerhalb der gegebenen Zeit sollten in diversen Abstimmungsterminen mit dem Auftraggeber mögliche Wissenslücken geschlossen werden, um dann im nächsten Schritt gemeinsam mit dem Entwicklungsteam eine Produktvision und schlussendlich einen Prototypen mit einem prozessualen „Durchstich“ anzufertigen, der im Kern die Pain Points zu lösen versucht.

Bevor der Prototyp erstellt wird, sollte allerdings die Produktvision geschärft werden. Hierbei ist es besonders wichtig, sich immer die Frage zu stellen, warum wir etwas lösen, bevor wir uns die Frage beantworten, wie wir etwas lösen wollen. Der Value Of Use ist essentieller Bestandteil der Produktvision und kann vor allem in der Durchführung von User Interviews bereits frühzeitig den richtigen Weg in der Software-Entwicklung aufzeigen. Der andere Teil des Entwicklungsteams kann sich in den ersten beiden Wochen währenddessen um das wie kümmern und parallel mit dem Auftraggeber den Value Of Function bzw. den Tech Stack festlegen.

Vor dem Prototyp ist nach dem Prototyp. In Woche Drei wird der Prototyp, der zuvor definierten Erkenntnisse angefertigt – vielleicht bereits mit der Entwicklungsumgebung, vielleicht aber auch nur ansatzweise in reduzierter Form. Ab der vierten Woche kann der Prototyp zusammen mit dem Auftraggeber und den möglichen Endanwendern in Form eines User Tests auf seine Tauglichkeit überprüft werden. 

Nach vier Wochen des Buildings und Measurings findet infolge der Auswertung der Ergebnisse das Learning statt und wir können den Startschuss für unsere Produktentwicklung nach Scrum geben. 

Die vier Wochen vor dem offiziellen Sprintstart nutzen wir bei SprintEins – um es mit den Worten von Eric Ries zu beschreiben – für unser „Startup“ oder wie wir es auch bei uns nennen: VISION Sprint

Einige Sprints später ist unsere Software zusätzlich um den Value Of Experience gewachsen und unterstützt den Nutzer nicht nur in seinen Handlungen, sondern erreicht ihn zusätzlich auf einer weiteren Ebene und bindet ihn somit dauerhaft an unsere Nutzungsoberfläche – hoffentlich.

Und wenn nicht, geht’s eben wieder von vorne los: BUILD. MEASURE. LEARN.

Diese Webseite nutzt Cookies

Diese Webseite nutzt Cookies zur Verbesserung des Erlebnisses unserer Besucher. Indem Sie weiterhin auf dieser Webseite navigieren, erklären Sie sich mit unserer Verwendung von Cookies einverstanden. Einige dieser Cookies sind technisch zwingend notwendig, um gewisse Funktionen der Webseite zu gewährleisten.