Aus dem Nichts gekommen, ist Lean UX plötzlich ein heißes Thema für Usability-Fachleute, das die gesamte Spanne an Reaktionen von der kompletten Übernahme der Methoden bis hin zu "Das ist kompletter Mist!" generiert. Ist da wirklich etwas dran? Oder hat man, wie ich auch schon mehrfach gehört habe, einfach etwas Altbekanntes umbenannt, um mehr Workshops zu verkaufen?
Ich war neugierig, also machte ich mich daran zu lernen, worum es bei Lean UX geht. Ich habe mit Dutzenden Leuten aus allen UX-Bereichen gesprochen und nachgegraben, was die Leute wirklich meinen, wenn sie darüber reden.
Meine Zusammenfassung: Das ist wirklich etwas. Lean UX ist ein wichtiger neuer Weg, um darüber nachzudenken, was wir tun, und ich meine, dass tatsächlich was dran ist. Lassen Sie’s mich erklären.
Zeitmaschine, bitte einsteigen!
Um zu begründen, warum ich Lean UX jetzt wichtig finde, muss ich Sie ein Stück zurück in die Vergangenheit mitnehmen – in die 60er und 70er Jahre. In jenen Tagen kamen die Computer auf, zumeist als riesige Großrechner. Unternehmen setzten sie für mehr und mehr Funktionen ein. Sie fanden Anwendungsfälle für alle möglichen Arten von Firmen.
Mit den ganzen neuen Anwendungsmöglichkeiten wuchsen auch die Software-Projekte. Und mit ihrem Wachstum wurde es exponentiell schwieriger, funktionierenden Code zu vernünftigen Budgets auszuliefern.
Um alles im Griff zu behalten, musste sich der Software-Bereich weiterentwickeln. Den größten Beitrag dazu leistete damals eine Managementmethode namens Software Development Life Cycle. Der SDLC zeigte einen standardisierten Weg auf, um große Anwendungen zu entwickeln, indem der Prozess in Phasen zerlegt wurde – eine Art Staffellauf, bei dem der Stab nach jedem Stadium in Form eines Zwischenergebnisses in die nächste Phase übergeben wurde.
Für diese ersten Großrechneranwendungen bedeutete der SDLC eine Menge Ordnung, wo bislang eine Menge Chaos geherrscht hatte. Er machte auslieferbare Anwendungen möglich, insbesondere große.
Allerdings berücksichtigte der SDLC nicht die Bedürfnisse der Endnutzer, und das brauchte er ehrlich gesagt auch nicht. In diesen Tagen wurden die Nutzer nicht gefragt, was sie mit den Anwendungen machen wollten. Sie standen vor der Wahl, den Computer zu nutzen oder die Arbeit per Hand zu erledigen. Alle User waren geschult (und zumeist wurde im Bewerbungsverfahren getestet, ob sie kompetent genug waren, um die Software zu nutzen).
Da keine Notwendigkeit bestand, auf die Bedürfnisse der Nutzer einzugehen, ignorierte der SDLC alle Aspekte, die wir heute unter nutzerfreundlichem Design und User Experience (UX) zusammenfassen. Über diese Dinge dachte einfach niemand nach.
Schneller Vorlauf: Das Business übernimmt die Kontrolle
Mit dem Aufkommen der ersten Kleinrechner und anschließend der ersten PCs gewannen die Unternehmen mehr Kontrolle über die Software, die sie einsetzten. Sie verlangten bestimmte Features, um effektiver und effizienter zu werden.
Leider fand im SDLC der Großrechner-Ära die inkrementelle Erweiterung um Funktionen keine Berücksichtigung. Man hatte keine Vorstellung davon, vorausschauende Architekturen zu bauen und Erweiterungen einzukalkulieren, die im Grundsystem nicht vorgesehen waren. Die IT-Entwickler brauchten ein neues Modell für ihre Arbeit. Heute kennen wir es als Wasserfall-Ansatz.
Das Wasserfall-Modell übernahm die Phasen der SDLC-Methode und ergänzte sie um die initiale Anforderungsdefinition. Diese Anforderungen kamen von Business-Analysten und den Fachexperten auf den jeweiligen Gebieten und standen fortan im Zentrum des Entwicklungsprozesses.
Von Hunderten zu Millionen
In den später 70ern und den frühen 80ern erreichten nur die populärsten Anwendungen die Tausend-Nutzer-Marke. Die meisten Applikationen hatten einige Hundert User. Daher war es nicht schwer herauszufinden, was die Nutzer brauchten. War die Anwendung komplex, konnten die Leute einfach trainiert werden. Und weil es ewig dauerte, neue Features umzusetzen, war man mit diesen Schulungen lange Zeit up to date.
Als sich jedoch der PC endgültig durchgesetzt hatte, knackten die ersten Anwendungen die Millionen-User-Schallmauer. Andere folgten, und bald war es gar nichts Ungewöhnliches mehr, Software für sehr viele Nutzer zu entwickeln.
Einmal mehr stieß die Art und Weise, wie wir Software entwickelten, an Grenzen und führte zu Chaos. Schließlich trat um 2001 die Agile-Bewegung auf den Plan, um die Dinge wieder in den Griff zu kriegen.
UX in der Wasserfall-Welt
Während der Prä-Agile-Epoche bezogen die Entwickler der meisten Anwendungen die User lediglich insofern mit ein, dass sie sie fragten, welche Anforderungen an die Features, die das Team umsetzte, sie denn hätten. Die Endnutzer wurden selten integriert, die Anforderungen kamen von anderen Leuten im Prozess.
Doch nun wuchs das Bedürfnis, es besser zu machen. GUI-Oberflächen boten den Entwicklern mehr Möglichkeiten und die Nutzer hatten mehr Auswahl in Sachen Tools. Schon bald wurden Rufe nach besseren Nutzererlebnissen laut.
In den einzelnen Phasen fanden zwar Usability-Aspekte Berücksichtigung, aber wie der SDLC war auch der Wasserfall-Ansatz nicht in der Lage, den Bereich UX grundsätzlich in den Prozess einzubinden.
Die Praxis, alle Gesichtspunkte eines Nutzererlebnisses in Form von Dokumenten mit detaillierten Ausarbeitungen aller Ideen festzuhalten, setzte sich durch und wurde an die Design-Phase im Wasserfall-Modell gekoppelt. Um die exakte Umsetzung der UX-Ideen in späteren Projektstadien zu gewährleisten, wurden sie extensiv dokumentiert und spezifiziert. Das Ziel bestand darin, alle Abweichungen zu eliminieren, indem man den Entwicklern genau sagte, was sie tun sollten.
Der Agile-Tornado entwurzelt die Wasserfall-UX-Methoden
Schließlich fingen die Teams an, das Chaos, das beim Wasserfall herauskam, aufzuräumen und wandten sich vielfach agilen Ansätzen zu, um die Kontrolle über die Prozesse zurückzugewinnen. Doch wie die Vorgängermodelle berücksichtigte Agile die UX-Aspekte nicht. Verschiedene agile Methoden wie Scrum und XP sehen zwar vor, dass die Nutzer während des Entwicklungsprozesses mit dem Team zusammensitzen, aber eine richtige Integration ist auch das nicht.
Wer herausgefunden hatte, wie man zu guten Ergebnissen kommt, indem man Usability-Engineering vernünftig mit dem Wasserfall-Modell verbindet, kam nun ins Schwimmen. Die agilen Prinzipien, die mehr auf Kommunikation und weniger auf "Verträge" (dazu gleich mehr) abzielen, passten nicht zum Status quo der UX-Prozesse.
Alte UX-Methoden einfach in agile Prozesse übernehmen?
Es gab viele frühe Versuche, den sehr iterativen und experimentellen agilen Prozess zu adaptieren, aber häufig wurde im Grunde nur eine Design-Phase eingeschoben, bevor der Sprint losging – quasi wieder ein Wasserfall, der so nicht funktionierte.
Zwei Aspekte trugen seinerzeit dazu bei, dass der UX-Prozess im Rahmen des Wasserfalls gut funktionierte. Erstens wusste man, dass sich die Projektziele vom Kick-off bis zum Launch nicht verändern würden. Das Modell sah vor, dass man am Anfang Dinge definierte, die dann im gesamten Entwicklungsprozess unangetastet blieben.
Zweitens drehten sich viele Aspekte darum, eine Art Vertrag zwischen UX- und Entwicklungsteam aufzusetzen. Die Entwickler erklärten sich damit einverstanden zu implementieren, was den UX-Fachleute vorschwebte. Dank der Dokumentationen und Spezifikationen wussten die Entwickler exakt, was zu tun war.
Diese beiden Aspekte sind im agilen UX-Prozess nicht wünschenswert. In der agilen Welt legen wir das Endergebnis nicht zu Beginn fest. Der agile Ansatz lebt von schnellen Iterationen, um sich einem tollen Ergebnis anzunähern. In einer Reihe von Experimenten versucht man herauszufinden, was das Beste für die Nutzer und das Unternehmen ist.
Gleichzeitig sind schwergewichtige Zwischenergebnisse wie Spezifikationen und selbst Wireframes im Rahmen kurzfristiger Iterationen hinderlich und bremsen den Prozess. Schnelle Prototypen und Teamdiskussionen erweisen sich als effektiver.
Dem agilen Modell den Wasserfall-UX-Prozess überzustülpen, war von vornherein zum Scheitern verurteilt. Es ist beschämend, dass wir es so lange versucht haben.
Lean UX: Die methodische Runderneuerung
Wenn Sie an UX und Agile als Frage denken, können Sie sich Lean UX als Antwort vorstellen. Wie ich gelernt habe, geht es der neuen Lean-UX-Bewegung prinzipiell darum, über die besten Bestandteile unserer derzeitigen UX-Praxis zu sprechen und sie spezifisch für die agile Welt umzubauen und anzupassen.
Was Lean UX beinhaltet, ist nicht wirklich interessant. Interessant ist vielmehr, was weggelassen wird. Weg ist der Grundsatz, dass die Projektziele sich nicht ändern und dass eine einzige Design-Lösung für das gesamte Projekt ausreicht. Weg ist die Notwendigkeit tonnenschwerer Dokumentationen, weil Sie mit den Entwicklern einen Übergabevertrag abschließen müssen.
Jeff Gothelf hat mir erklärt, dass Lean UX im Kern bedeutet, jede Design-Iteration als Hypothese zu verstehen:
"Du musst Deine Hypothese aus Kundenperspektive und aus Business-Sicht validieren", sagte Jeff mir. "Du willst den Zeitaufwand für das Verfolgen einer falschen Hypothese minimieren. Je mehr falsche Pfade du schnell identifizierst, desto rascher findest du den richtigen Weg."
Folgt man den Lean-UX-Prinzipien, fokussiert man sich auf das Iterieren durch Hypothesen. Sie denken am Anfang, dass Sie wissen, was die Nutzer brauchen, aber am Ende entdecken Sie, dass die User etwas ganz anderes wollen. Machen Sie sich die Vorteile der schnellen Iterationen im agilen Prozess zunutze, können Sie Ihre Hypothesen kurzfristig testen und bekommen am Ende ein großartiges Ergebnis.
Um den Verzicht auf schwergewichtige Zwischenergebnisse zu kompensieren, arbeitet Lean UX an der Teamzusammenarbeit. Die Lean-UX-Methoden binden das gesamte Team ein und fußen auf kontinuierlicher Diskussion.
Als beispielsweise das Twitter-Team die Oberfläche umgestaltet hat, wurden während der Arbeit Live-Usability-Tests an die Wand des Entwicklerbüros projiziert. Sobald im Test etwas Interessantes passierte, war der Testleiter in der Einsatzzentrale angehalten, dem Team z.B. zuzurufen: "Hey Leute, Ihr müsst Euch ansehen, was hier passiert ist!" Echtzeit-Nutzerforschung ist eine Komponente des Lean-UX-Prozesses.
Das Schöne daran: Es ist nichts Neues
Hochinteressant ist Lean UX deshalb, weil es auf bestens verstandenen Usability- und Design-Methoden basiert. Kein Lean-UX-Bestandteil ist neu.
Tatsächlich gibt es hier eine Reminiszenz zu dem, was wir in den 90er Jahren gemacht haben. Damals haben wir uns zahlreiche fortschrittliche Techniken wie Discount-Usability-Tests und Papier-Prototypen zueigen gemacht, die Ergebnisse dann aber immer für die Verträge mit den Entwicklern zusammengepackt, wie es der Wasserfall erforderte. Dieselben Techniken haben im Lean-UX-Prozess nun ein komfortables neues Heim gefunden und harmonieren wunderbar mit der agilen Praxis.
Sie können es so sehen: Lean UX ist einfach UX. Aber UX ist nicht immer Lean UX. Am Lean-UX-Knochen ist definitiv Fleisch dran. Wenn Sie sich damit bislang noch nicht beschäftigt haben, sollten Sie’s tun.
Dieser Artikel wurde im Original am 30. November 2011 unter dem Titel Is There Any Meat on This Lean UX Thing?
