Okay, kurze Geschichte..
Viele verurteilen den Begriff und die Methode als eine Verleugnung umfangreicher Dokumentationen und Prozesse, während andere behaupten es sei einfach nur ein Rebranding von Techniken, die sie bereits seit Jahren praktizieren.
Meiner Meinung nach ist Lean UX schon etwas Neues und ich will euch hier mal etwas näher bringen, warum es gerade jetzt wichtig ist, den klassischen UX Prozess etwas zu entschlanken oder etwas flexibler zu gestalten.
Damals, also als man noch monochrome Bildschirme und gelochtes Endlosdruckerpapier benutzte, wurde Design noch per Hand gescribbelt und auch technische Zeichnungen wurden mit der Hand gemacht und damals wie auch heute mussten die Bereiche Produkt- Industriedesign oder Druck gewisse Einschränkungen beachten, da tatsächlich physische Produkte entstehen und produziert werden, wie z.b. Spritzgussformen oder Spielzeug oder Handyhüllen. Ab den 80er und 90er Jahren wurde dann zunehmend auf Software bzw. CAD (Computer Aided Design) umgestellt.
In diesem neuen Zusammenhang mit der Arbeit mit Software und Design sahen sich Designer dann plötzlich mit ganz neuen Aufgaben konfrontiert.
Mit entprechendem Fokus auf und mit Software arbeitend, entstanden gänzlich neue Herausforderungen. Designer mussten die Syntax dieser neuen Medien herausfinden und wir sahen, wie sich dadurch neue Spezialgebiete wie Interaktionsdesign und Informationsarchitektur heraus entwickelten. Der eigentliche Designprozess wie wir Designer arbeiten blieb aber im Grunde derselbe und wird durch das wachsende Interesse an Design Thinking immer populärer.
Und heute?
Heute stehen wir Designer vor einer neuen Realität. Das Internet hat die Distribution von Software radikal verändert. Software wird jetzt online vertrieben und wir sind nicht länger auf einen physikalischen Herstellungsprozess beschränkt. Wir können nun in viel kürzeren Fertigungszyklen, viel freier gestalten und arbeiten.
Aber leider ist dies nur die halbe (positive) Wahrheit über die Freiheit. Denn nun sehen sich die Teams enorm starkem Konkurrenzdruck ausgesetzt. Modernes Software Projektmanagement und Produktentwicklungsprozesse setzen Techniken wie agile Softwareentwicklung, “Continuous Integration” und “Continuous Delivery” ein, um die Zykluszeiten radikal zu reduzieren. Teams bringen neue Features oder neuen Code in Produktion und nutzen diese kurzen Zyklen als einen Wettbewerbsvorteil. Vorherige intensive Planung zur Risikoverminderung durch Phasenmodelle wie z. B. “4 Phasen Wasserfall” haben aufgrund der Zeitintensität eher ausgedient und werden zunehmend durch agile Methoden abgelöst. Am bekanntesten sind SCRUM (oder XP) in der IT und V-Modell XT bei der Projektplanung. Heute zählt es mehr, ein funktionierendes Produkt (MVP) früh auf den Markt zu bringen, dadurch Feedback zu bekommen und entsprechend schnell mehrere dieser Feedbackschleifen zu durchlaufen. Basierend auf dem, was wir dadurch lernen und dann extrem schnell anpassen können, erhöhen wir parallel die Kundenerwartungen in Bezug auf Qualität und Reaktionszeiten.
In dieser neuen Realität sind die traditionellen Ansätze von Software Projektmanagement oder Planung wie beispielsweise Wasserfall oder RUP nicht mehr ganz zeitgemäß. Auch das Prinzip “Form Follows Function” kann heutzutage nicht mehr ganz so dogmatisch aufrecht gehalten werden. Die kürzeren Entwicklungszyklen lassen eine so umfangreiche Planung nicht mehr zu. Also, was sollten wir als Designer nun tun, wenn wir im Vorfeld schon genau wissen müssen was und wie designed werden soll? Was sollen wir tun, wenn von uns erwartet wird, ebenso auch das “wie genau” bereits definiert zu haben, aber wir dazu viel mehr Zeit im Voraus benötigen, als so ein Sprint Zero?
Es wurde Zeit für eine Veränderung. Lean UX (UX = User Experience) ist die Evolution des Produktdesigns. Es nimmt die besten Teile aus der Toolbox eines UX Designers und transferiert sie in eine moderne an die heutige Realität angepasste Art und Weise.
Lean UX
Lean UX ist eine sehr nützliche Methode, wenn wir an IT-Projekten arbeiten, bei denen Agile-Entwicklungsmethoden verwendet werden. Herkömmliche UX-Techniken funktionieren oft nicht, wenn die Entwicklung in schnellen Iterationen durchgeführt wird – es gibt nicht genug Zeit, um UX Konzepte auf die gleiche Weise bereitzustellen. Grundsätzlich haben Lean UX und andere Formen von UX alle dasselbe Ziel einer Schaffung von großartigen Benutzererlebnisses. Die Art und Weise, wie Du mit Lean UX an einem Projekt arbeitest, ist etwas anders. Sehen wir uns mal an, wie das funktioniert.
Grob beschrieben:
Lean UX ist zunächst zutiefst kollaborativ und funktionsübergreifend, weil wir nicht länger den Luxus haben, isoliert vom Rest des Produktteams zu arbeiten um vorab perfekte Lösungen zu erarbeiten. Wir können unsere Teams nicht weiter bitten, auf uns zu warten, um alles Relevante herauszufinden. Wir brauchen tägliches, kontinuierliches Engagement mit unseren Teams, wenn wir effizient sein wollen. Dieses fortwährende Engagement ermöglicht es uns, schwere Anforderungen zugunsten von leichtgewichtigen Lösungen zu streichen, die es uns ermöglichen, mit unseren Teamkollegen ein gemeinsames Verständnis aufzubauen.
Es lässt uns auch die Art, wie wir über Design sprechen, überdenken. Anstatt über Features und Dokumente zu sprechen, reden wir mehr über das was funktioniert. In dieser neuen Realität erhalten wir schnellere Rückmeldungen vom Nutzer, als je zuvor. Dieses Feedback ermöglicht es uns, Designgespräche in Bezug auf die Geschäftsziele neu zu führen, da wir nun, durch die schnelleren Feedbackzeiten auch schneller messen und validieren können, was funktioniert und sozusagen zeitgleich Anpassungen vornehmen können.
Meiner Meinung nach sind vor allem 3 Dinge bezeichnend.
- Es ist als Prozessänderung für uns Designer zu verstehen.
- Es ist eine Denkweise, die uns unsere Arbeit auf neue, leichtgewichtigere Weise angehen lässt.
- Es ist eine neue Art zu denken.
Lean UX – Was macht es?
Lean UX konzentriert sich auf die tatsächliche Erfahrung im Designprozess und weniger auf im Vorfeld validiertenErgebnisse wie in herkömmlichen UX Prozessen. Es erfordert dadurch ein höheres Maß an Zusammenarbeit mit dem gesamten Team. Das Hauptziel besteht darin, sich so früh wie möglich auf Feedback zu konzentrieren, damit schnelle Entscheidungen getroffen werden können. Die Art der agilen Entwicklung besteht darin, in schnellen, iterativen Zyklen zu arbeiten, und Lean UX ahmt diese Zyklen nach, um sicherzustellen, dass die erzeugten Daten rechtzeitig in jeder Iteration verwendet werden können.
Die Notwendigkeit von Annahmen in Lean UX
Im herkömmlichen UX basiert das Projekt auf der Erfassung von Anforderungen und Ergebnissen. Ziel ist es, sicherzustellen, dass die zu erbringenden Leistungen so detailliert wie möglich sind und angemessen auf die Anforderungen reagieren, die zu Beginn des Projekts festgelegt sind. Lean UX ist etwas anders und konzentriert sich nicht auf detaillierte Ergebnisse, sondern wir suchen nach Veränderungen, die das Produkt im Hier und Jetzt verbessern – im Wesentlichen, um das Ergebnis ad hoc zum Besseren zu formen. Dies funktioniert in der Praxis indem “Anforderungen” verworfen werden und eine “Problemaussage” verwendet wird, die zu einer Reihe von Annahmen führen sollte, die zur Erstellung von Hypothesen verwendet werden können.
Was ist eine Annahme?
Eine Annahme ist im Grunde eine Aussage von etwas, das wir für wahr halten. Sie dient dazu, ein gemeinsames Verständnis für eine Idee zu schaffen, die es jedem ermöglicht, ohne Verzögerung anzufangen. Es sollte jedem stehts Bewusst sein, dass diese Annahmen sich möglicherweise als nicht korrekt erweisen und während des Projekts geändert werden können, da sich innerhalb des Teams ein anderes, besseres Verständnis entwickelt.
Annahmen werden normalerweise auf Workshopbasis generiert. Du bringst das Team zusammen, stellst das Problem dar und erlaubst deinem Team, Ideen zur Lösung des Problems zu sammeln, um aus diesen Annahmen Hypothesen zu bilden.
Typische Fragen könnten sein:
- Wer sind unsere Nutzer?
- Wofür wird das Produkt verwendet?
- Wann wird es verwendet?
- In welchen Situationen wird es verwendet?
- Wie wird es verwendet, was sollten wir wissen?
- Was wird die wichtigste Funktionalität sein?
- Was ist das größte Risiko für die Produktlieferung?
Es kann natürlich mehrere Antworten auf jede Frage geben. Das lässt dann oft eine größere Anzahl von Annahmen entstehen als es praktisch wäre. Wenn dies der Fall ist, sollte das Team seine Annahmen zunächst einmal priorisieren. Idealerweise sollten diese Annahmen dann erneut priorisiert werden. Wieso? Aus meinen letzten Workshops wurde klar, dass es ratsam ist, die bereits priorisierten Annahmen erneut zu überdenken und zwar durch das Risiko, welches sie darstellen. “Was sind die Folgen davon, wenn diese Annahme komplett falsch ist?”
Je schwerer die Konsequenz ist, desto höher sollte die Priorität sein und damit die Notwendigkeit für ein besseres Verständnis des Problems (je weniger du weißt, desto höher der Misserfolg). Klar oder?
Erstellen einer Hypothese in Lean UX
Die erstellten Hypothesen sollen unsere Annahmen überprüfen. Es gibt ein einfaches Format, womit ihr eure eigenen Hypothesen schnell und einfach erstellen könnt.
Ein Beispiel:
Du glaubst, dass es für Smartphone-Nutzer wichtig ist ihre Fortschritte jederzeit zu speichern. Dies würde zu einer höheren Anzahl von Zielerfüllungen (Anmeldungen) führen. Wenn eine signifikante Verbesserung der aktuellen Anmeldungen von z. B. 10% eintritt, ist die Hypothese richtig.
Du setzt nun diese Hypothese fest und auch warum sie und für wen sie wichtig ist. Schließlich bestimmen wir welche “Beweise” nötig sind, um zu beweisen, dass unsere Hypothese wahr ist. Diese Beweise sollten realistisch und von den anderen Teilnehmern ebenso fair diskutiert werden.
Wenn wir jedoch feststellen, dass es keinen Weg gibt, unsere Hypothese zu beweisen, laufen wir Gefahr in die falsche Richtung zu gehen, weil unsere Ergebnisse dann nicht klar definiert sind. Daher ist es unbedingt nötig klare Definitionen zu finden.
Einer der großen Vorteile ist, dass es viele der “Ich glaube nicht, dass das eine gute Idee ist” sowie selbsternannte Designexperten und politische Machtkämpfe aus dem UX Designprozess entfernt. Jede Idee wird getestet und die Evidenzkriterien klar festgelegt. Der Beweis wurde nicht erreicht? Dann ist es Zeit, die Idee fallen zu lassen und etwas anderes zu versuchen.
Wenn das Team die Hypothesen und die daraus entstandenen Erwartungen versteht, neigen die Teammitglieder dazu, ersteinmal abzuwarten, ob die Hypothesen haltbar sind, anstatt ständig über ihren subjektiven Standpunkt diskutieren zu wollen. Es wird professioneller! 🙂
MVP oder das Minimum Viable Product
Das Minimum Viable Product (MVP) ist ein Kernkonzept in Lean UX. Die Idee besteht darin, die grundlegende Version des Konzepts so gut wie möglich (nahezu experimentell) zu erstellen, um sie unverzüglich testen zu können. Wenn das MVP keine wertvollen Ergebnisse einspielt, kann es nach dem Trial and Error Prinzip verworfen und neu erdacht werden. Die MVP’s, die vielversprechend sind, können dann ohne großen Aufwand in weitere Design- und Entwicklungsrunden integriert werden.
Dies ist eine großartige Möglichkeit, deinen “Outcome” zu minimieren, deine Erkenntnisse zu maximieren und einer der Gründe, wodurch nun agile Entwicklung gut mit UX funktioniert – es ermöglicht die experimentelle Herangehensweise, ohne die Erwartungen von durchdefinierten Flows&Journeys und High Fidelity Prototypen, oder die oft erwartete “Eierlegende Wollmilchsau”.
Benutzerforschung und Tests in Lean UX
Die Benutzerforschung und -tests, die Lean UX zugrunde liegen, basieren auf denselben Prinzipien wie in herkömmlichen UX-Umgebungen. Der Ansatz liegt jedoch eher auf “quick and dirty” D.h. Ergebnisse müssen vor Beginn des nächsten Sprints geliefert werden. Da oft im 2 Wochentakt gesprintet wird, gibt es also weniger Fokus auf High-End Requirements, sorgfältige Dokumentationen, sondern mehr Fokus auf das was grob gut funktioniert.
Forming Storming Norming Performing
Beeindruckend ist immer der Teamzusammenhalt, wenn das gesamte Team von Anfang an selbst die Anforderungen und Hypothesen generiert. Es fördert die Verantwortlichkeit innerhalb des Teams und entlastet somit den Einzelnen, da sich jeder für die Ergebnisse verantwortlich fühlt. Der berüchtigte Flaschenhals wird dadurch zur Nebensache, da UX Design nicht mehr an einer einzigen Ressource hängt, sondern auch oft vom Entwicklerteam allein schon aus reiner Neugier geleistet wird, die das Testing, ein so wichtiger Teil der UX-Arbeit quasi “hands on”, selbst durchführen. Es trägt zum besseren Verständnis der Benutzungsproblematiken der Zielgruppe, für das Verständnis von UX-Arbeit an sich und vor allem zur Team-Motivation bei.
Fazit
Dies war ein sehr allgemeiner Überblick über Lean UX und natürlich gibt es noch viel mehr. Dieser Artikel soll Dir einfach ermöglichen, von hier aus in die richtige Richtung zu gehen, wenn es darum geht, Lean UX beispielsweise in deinem agilen Umfeld einzusetzen. Ich empfehle dir übrigens auch meinen Artikel über “UX Prozess” und “Warum der UX Prozess kein Prozess ist”.
Wenn du etwas über Motivation erfahren willst, ließ mein Review über “Drive – The Surprising Truth About What Motivates Us” von Daniel Pink
