Interdisziplinarität nutzen
Think, Check, Make and Repeat
Kontinuierliches Lernen
Agile Entwicklungsmethoden wie Scrum werden immer beliebter. So ist es schließlich möglich, flexibel und schnell auf Marktänderungen und Änderungswünsche seitens der Nutzer*innen zu reagieren. Der typische UX- und Designprozess ist allerdings nicht auf Agilität ausgelegt. Um UX und agile Entwicklungsmethoden zu verbinden, bedienen wir uns an Grundsätzen von Lean Production und Lean Management. Auf UX gemünzt nennt sich dies Lean UX und hilft Unternehmen dabei, schneller und günstiger bessere Anwendungen zu entwickeln, ohne dabei einem hohen Risiko oder Marktveränderungen wehrlos ausgesetzt zu sein.
Der Begriff "Lean" findet seinen Ursprung, wenn auch nicht unter dieser Bezeichnung, in Japan. Nach dem 2. Weltkrieg konnte die japanische Wirtschaft nicht mit dem Westen mithalten. Der Fahrzeughersteller Toyota entwickelte mit seinem "Toyota-Produktionssystem" eines der effizientesten Fertigungssysteme. Während die Massenproduktion im Westen hauptsächlich den Fokus auf die Aufteilung des Fertigungsprozesses in viele kleine Arbeitsschritte legte und auf größere Fertigungslagen setzte, um niedrige Stückkosten zu erreichen, orientierte man sich bei Toyota auf die Optimierung des Produktionsprozesses und den Warenströmungen. Es fehlte schlichtweg das Geld und der Platz in der Nachkriegszeit. Neben dem "Just-in-Time"-Prinzip, wurde auch aktives Fehlermanagement betrieben. Fehler wurden schnell erkannt und gelöst. Unnötige Prozesse wurden eliminiert. Durch diese und andere Unternehmungen schaffte es Toyota, effizienter als westliche Automobilhersteller zu produzieren und sich damit einen Vorteil zu verschaffen.
„Wir betrachten lediglich die Zeitspanne vom Moment, in dem der Kunden seine Bestellung einreicht, bis zu dem Zeitpunkt, an dem wir die Bezahlung erhalten. Und wir verkleinern diese Zeitspanne, indem wir alle nicht wertschöpfenden Verschwendungen eliminieren.“
(Taiichi Ohno, damals Produktionsleiter der Toyota Motor Corporation)
Ein Ausflug in die 60er und 70er Jahre des 20. Jahrhunderts: Die ersten Großrechner kamen auf und wurden für Unternehmen interessant. Viele Prozesse und Funktionen konnten von den Wundermaschinen übernommen werden. Durch stetige Entwicklung wurden Großrechner immer kleiner und leistungsfähiger.
Fast jede Branche fand Lösungen, um von der neuen Technologie zu profitieren. Durch die weitere Verbreitung der Computer in den 80er Jahren wurden immer mehr Anwendungsmöglichkeiten entdeckt. Durch neue Funktionen und auch Anforderungen der Nutzer*innen wurde es für Unternehmen immer schwieriger, sauberen und funktionierenden Code in einem vernünftigen Budget zu entwickeln. Ein einheitlicher Entwicklungsprozess existierte schlichtweg nicht.
Für die Weiterentwicklung im Software-Bereich sorgte die Management-Methode "Software Development Live Cycle" (SDLC). Der SDLC standardisierte den Entwicklungsprozess und ermöglichte so die Entwicklung großer Anwendungen durch das Zerlegen des Prozesses in einzelne Phasen. Mit steigender Verbreitung der Computer offenbarte der SDLC eine große Schwäche: Der SDLC berücksichtigt nicht die Anforderungen und Bedürfnisse tatsächlicher Nutzer*innen. Nutzer*innen mussten die Software lernen und nutzen. Alternativen hatte er nicht.
Spätestens mit der kometenhaften Verbreitung der Computer und auch mit der Einführung der Smartphones war der SDLC endgültig am Ende und wurde durch den sogenannten Wasserfallprozess abgelöst. Dieser übernahm die Phasen des SDLC und ergänzte diese um eine initiale Anforderungsdefinition. Diese Anforderungen kamen von Business-Analysten und Fachexpert*innen. Nun werden Nutzer*innen erstmalig berücksichtigt. Allerdings geschieht dies nur in der initialen Anforderungsdefinition. Während des weiteren Entwicklungsprozesses werden Nutzer*innen nicht mehr hinzugezogen.
In den 2010er Jahren wuchs der Druck auf Unternehmen. Branchengiganten wie Nokia, Blackberry oder auch Yahoo verschwanden fast vom Bildschirm. Die Traffic-stärksten Internetseiten hießen nun Facebook und Google. Zwei Unternehmen, die praktisch im Studentenwohnheim entstanden sind. Doch wie konnten diese Unternehmen sich gegen Branchenschwergewichte behaupten? Die Antwort lag in dem Wort. Durch die Größe und die Strukturen wurden die Unternehmen schwerfällig. Google und Facebook konnten in unglaublich kurzen Intervallen die Software anpassen und auf Nutzer*innen und Marktbedürfnisse reagieren. Der Weg ging weg von starren Entwicklungsprozessen hin zu agilen Methoden. Eine der bekanntesten agilen Methoden, Scrum, sorgte für kurze Iterationen und ermöglichte einen schnellen Wandel.
Als in den 80er und 90er Jahren die Arbeit des Industrie-, Produkt-, und Printdesigners Einzug in die Softwareprozesse hielt, nutzten Designer*innen erst einmal die bewährten und alten Arbeitsmethoden, die auch bei anderen "Werkstoffen" verwendet wurden. Sowohl im Print- und Industriebereich als auch im Produktdesign entstand am Ende ein fertiges Werk, das produziert wurde. Ein Fehler wird sehr schnell teuer. Auch in der Softwareentwicklung wurde am Ende ein fertiges Werk auf runde silberne Scheiben geschrieben. Die Älteren unter uns kennen diese noch als CD. Ein Fehler sorgte für eine teure Neuproduktion.
Doch diese Zeiten sind mittlerweile vorbei. Software funktioniert entweder direkt im Browser, oder wird rein online vertrieben. Gebrannte CDs und DVDs sind selten geworden. Neben dem schnelleren und einfacheren Vertriebsweg wurde ein weiterer zentraler Vorteil geschaffen: Software konnte jederzeit verbessert und aktualisiert werden.
Heutzutage sieht der typische Design-Prozess wie folgt aus:
Zunächst wird basierend auf Nutzerbefragungen oder Stakeholder-Interviews ein Konzept erarbeitet. Dieses unterläuft meist eine interne Validierung durch den Chef, einem Projektmanager, oder einem Product-Owner. Anschließend wird aus dem Konzept ein Design erstellt. Dieses wird meist in Form eines Prototypen umgesetzt und anschließend von Nutzer*innen getestet. Die Erkenntnisse des Nutzertests werden gesammelt und zusammengetragen. Anschließend beginnt der Prozess von vorne. Viele Sachen sind gut gemacht worden, so werden Nutzer*innen in den Entwicklungsprozess einbezogen. Allerdings geschieht das zu einem sehr späten Zeitpunkt. Weiterhin werden die einzelnen Prozessschritte von der jeweiligen Abteilung übernommen. In diesem Prozess werden viele unnötige Schritte unternommen und damit künstliche Blockaden geschaffen.
Nachdem wir uns nun den Entwicklungs- und Designprozess angeschaut und die Probleme rausgearbeitet haben, geht es an die Lösung. Diese Lösung nennt sich Lean UX und sorgt für kürzere Iterationen mit interdisziplinären Teams zur Entwicklung besserer Produkte. Klingt toll, oder? Doch wie genau funktioniert dieses Lean UX?
Wie an dem Begriff "Lean" erkennbar ist, handelt es sich bei Lean UX um einen schlanken Designprozess, in dem ausführliche Dokumentationen und unnötige Schritte vermieden werden. Im Endeffekt picken wir uns die besten Bestandteile des Designprozesses heraus und nutzen diese in Kombination mit einigen anderen Verbesserungen.
So setzt Lean UX konsequent auf Interdisziplinarität und eine Zusammenarbeit zwischen allen an dem Projekt beteiligten Abteilungen. Wenn wir wirklich effizient sein wollen, müssen wir tagtäglich mit dem gesamten Team in Kontakt stehen. Dieses kontinuierliche Engagement gestattet es uns, aufgeblähte Deliverables zu Gunsten eines gemeinsamen Verständnisses los zu werden.
Statt über Funktionen und Dokumentationen zu sprechen, reden wir nun darüber, was funktioniert und wie Nutzer*innen davon profitieren. Durch häufige und kurze Nutzertests erhalten wir schnell Feedback und können flexibel auf Marktänderungen reagieren.
Die Vorteile von Lean UX sind mannigfaltig! Einer der Grundpfeiler von "Lean" ist die Müllvermeidung. Dabei reden wir natürlich nicht von Papier- und Restmüll, sondern von unnötigen und aufgeblähten Dokumentationen. Werden diese durch für alle verständliche Designartefakte ersetzt, wird nicht nur ein besseres Verständnis geschaffen, sondern gleichzeitig effizienter gearbeitet.
Wir sind schon bei dem Thema gemeinsames Verständnis. In die gleiche Kerbe schlägt auch der nächste Vorteil: Kollaboration. Durch das gemeinsame Arbeiten mehrerer verschiedener Abteilungen werden diverse Betrachtungswinkel eingenommen. Da jede Abteilung eigene Erfahrungen einbringt, existiert automatisch der Blick über den Tellerrand.
Doch selbst wenn eine falsche Entscheidung getroffen wurde: Lean UX basiert auf dem Credo: "Think, Make, Check and Repeat". Durch die schnelle Einbeziehung echter Nutzer*innen können Funktionen und Ideen schnell evaluiert und optimiert, oder verworfen werden. Das gesamte Team lernt durch diesen Prozess stetig hinzu. Die Marketingabteilung weiß, dass ein bestimmtes Feature von den Nutzer*innen besonders begeistert empfangen wurde und kann entsprechende Kampagnen planen. Durch die schnelle Iteration ist ein Fehler keine teure Fehlentwicklung, sondern ein Lernprozess.
Einer der letzten, aber vielleicht auch einer der entscheidenden Vorteile von Lean UX ist: Nutzerzentrierung! Es mag für viele Menschen wie eine Revolution wirken, aber die aktive Einbeziehung von echten Nutzer*innen macht die Software besser. Am Ende sind es die Nutzer*innen, die die Anwendung, vielleicht sogar tagtäglich, nutzen werden. Ein Produkt mit einer besseren User Experience setzt sich gegenüber der Konkurrenz durch.
Credo: Think, Make, Check and Repeat
Wie vorhin schon angedeutet, lautet das Credo von Lean UX: “Think Make, Check and Repeat”. Doch was genau verbirgt sich hinter den einzelnen Punkten?
In dem "Think"-Prozess dreht sich alles um die effektive Problemlösung. Hier werden Methoden aus dem Design Thinking verwendet. In einer Brainstorming-Sitzung setzt sich das multidisziplinäre Team zusammen und versucht Problemlösungen zu finden. Damit dies bewerkstelligt werden kann, muss zunächst einmal das Problem verstanden werden. Welche Aufgaben möchten Nutzer*innen lösen, können es aber nicht zufriedenstellend? Welche Hindernisse stehen im Weg? Anschließend wird beobachtet, wie Nutzer*innen mit einem Problem umgehen. Dafür kann entweder eine Nutzerbeobachtung durchgeführt oder mit Stakeholdern gesprochen werden. Am Ende dieses Schrittes wird eine gemeinsame Sichtweise definiert und eine Annahme getroffen. Diese Annahmen sind Statements über die Nutzer*innen, die in den Augen des Teams wahr sind. Aus dieser Annahme bzw. Hypothese wird eine Persona erstellt. Diese Persona zwingt jedes Teammitglied dazu, sich mit der Zielgruppe zu beschäftigen und Nutzer*innen in den Fokus zu rücken. Bei Diskussionen zur Problemlösung wird sich immer gefragt: Würde die Persona A damit zurechtkommen? Am Ende des "Think"-Prozesses steht eine konkrete Problembeschreibung.
In dem "Make"-Prozess geht es um die Erarbeitung und Umsetzung des Lösungsvorschlages basierend auf der Problemstellung. UX- und UI-Designer*innen schaffen Lösungen auf Basis der Vorarbeit des "Think"-Prozesses. Diese Lösungen müssen nicht zwangsweise vollständig ausdesignt und pixelperfekt erstellt werden. Sogenannte Low-Fidelity-Prototypen in Form von Wireframes oder Papierprototypen liefern oftmals eine gute Ausgangsbasis um einen Lösungsvorschlag evaluieren zu können. Teilweise werden aber auch sogenannte High-Fidelity-Prototypen benötigt. Ein High-Fidelity-Prototyp kann in Form eines klickbaren Screen Designs, oder auch als tatsächlich funktionierende Anwendung erstellt werden.
Welche Umsetzungsart gewählt wird hängt in erster Linie von dem Lösungsvorschlag ab. In jedem Fall sollte die schnellste und passendste Umsetzungsart gewählt werden. Solange am Ende des "Make"-Prozesses Nutzer*innen die Lösung verwenden, oder zumindest verstehen können, ist die Art des Prototypen irrelevant.
Der von uns erstellte Lösungsvorschlag muss nun evaluiert werden. Ganz im Sinne von Lean, wird auf überdimensionierte Nutzertests verzichtet. Statt fünf verschiedene Nutzertests mit einem Umfang von einer Stunde, werden kurze Nutzertests, die maximal zehn Minuten dauern, durchgeführt. Dabei wird im ersten Schritt der Nutzungskontext analysiert. Durch die richtige Fragestellung können wir unsere Annahmen im "Think"-Prozess evaluieren. Im zweiten Schritt wird der Lösungsvorschlag getestet. Kommen Nutzer*innen damit zurecht? Welches Feedback bekommen wir? Wie reagieren Nutzer*innen? Optimalerweise werden diese Interviews auf Video aufgenommen. Dadurch können den anderen Mitgliedern bei Bedarf bestimmte Szenen gezeigt werden. Die Erkenntnisse aus den Nutzertests fassen wir auf einem DIN A4 Zettel zusammen und verwenden diese Erkenntnisse, um den Lösungsvorschlag abzusegnen oder zu optimieren.
Am Ende des "Check"-Prozesses erhalten wir konkrete Nutzerreaktionen zum eingebrachten Lösungsvorschlag. Diese Ergebnisse werden umgesetzt und wir starten wieder mit dem "Think"-Prozess und iterieren durch. Am Ende jeder Iteration haben wir die Problemstellung erkannt, einen Lösungsvorschlag erarbeitet und diesen anschließend evaluiert. Damit sind wir dem Ziel, eine Anwendung zu entwickeln, die von Nutzer*innen nicht nur einfach und effizient genutzt werden kann, sondern gleichzeitig auch Spaß mach, einen Schritt näher gekommen.
Das Minimum Viable Product (MVP) stellt eine der Kernmethoden von Lean UX dar. Bei dem MVP wird sich auf das Wesentliche konzentriert und somit eine kleinstmögliche erste Version eines Produktes erstellt. Dieser MVP wird evaluiert und schrittweise erweitert.
Ein MVP muss nicht jede Funktion des fertigen Produktes enthalten. Eine erste einfache Version die Nutzer*innen einen Mehrwert bietet, reicht völlig aus um schnell und kostengünstig Annahmen zu überprüfen.
Leider wird von den meisten Unternehmen ein entscheidender Fehler begangen: Es wird nur der Querschnitt des Funktionsumfangs abgebildet. Allerdings spielt der reine Funktionsumfang für Nutzer*innen mittlerweile nicht mehr die entscheidende, oder gar einzige, Rolle. Themen wie Zuverlässigkeit, Gebrauchstauglichkeit und auch emotionales Design spielen eine große Rolle. Daher sollte der Querschnitt des MVP alle Bereiche abdecken. Der MVP sollte funktional, zuverlässig sowie gebrauchstauglich sein und in der Bedienung Spaß machen.
Interdisziplinäre Teams
Lean UX ist aufgrund der Interdisziplinarität so effizient und erfolgreich. Manche Unternehmen denken, dass ein interdisziplinäres Team aus verschiedenen Entwicklern und Business-Analysten besteht. Dabei sollten alle beteiligten Bereiche der Produktentwicklung mit einbezogen werden. Dazu gehören Entwickler*innen, Business-Analyst*innen, Vertriebler*innen, Marketer, Designer*innen, Usability-Engineers, Produktmanager*innen etc.
Ganz im Sinne von Lean, sollte man hier aber nicht übertreiben und Meetings mit 50 verschiedenen Mitarbeiter*innen aufstellen. Die Teamgröße sollte 8-12 Stakeholder nicht überschreiten. Dadurch ist jede Abteilung durch Stellvertreter*innen vertreten, während die Teamgröße gleichzeitig die Kommunikation fördert, statt diese zu behindern.
Durch interdisziplinäre Teams werden so zwei wichtige Dinge sichergestellt: Zum einen sind alle betroffenen Sichtweisen auf das eigene Produkt in den Teams vertreten. Zum anderen wird der typische Informationsverlust im Vergleich zu herkömmlichen Übergaben von Dokumentationen oder Tickets vermieden. Alle beteiligten Abteilungen lernen im Laufe des Entwicklungsprozess.
Die Minimierung von Verschwendung ist der zentrale Aspekt von Lean. Schon Toyota hat nach dem zweiten Weltkrieg alle nicht-wertschöpfenden Prozesse eliminiert. Beispiel hierfür: Durch das Just-In-Time-Prinzip wurden massiv Lagekosten eingespart.
In der Softwareentwicklung ist der Grundgedanke identisch. Ressourcen eines Teams sind begrenzt. Sei es durch finanzielle, räumliche oder zeitliche Limitationen. Daher sollten die vorhanden Ressourcen auf das für den Erfolg Wesentliche konzentriert werden. Je weniger unnötige Arbeiten, Dokumentationen oder Meetings anfallen, desto effektiver und effizienter arbeitet das Team. Alles, was nicht zwingend benötigt wird, fällt weg.
Um die Verschwendung während der Produktion minimieren zu können, sind kleine Arbeitspakete nötig. Werden diese zu groß gewählt, so führt dies meist zu zwei einschlägigen Problemen: Erstens erhöhen zu große Arbeitspakete die für die eigentliche Arbeit benötigte Planungszeit. Zweitens erhöhen sie das Risiko, unnötige Features zu planen und dann umzusetzen, da sich das wichtige Feedback der Kund*innen erst lange nach der großen Vorbereitung einholen lässt.
Überträgt man dies auf die Softwareentwicklung so ergibt sich daraus die Handlungsmaxime, nur so viel zu planen, wie man auch tatsächlich in absehbarer Zeit umgesetzt bekommt. Eine große Vision für das spätere Endprodukt ist natürlich von Nöten, jedoch ist ein Vorlauf weniger Sprints für die konkrete Planung und das Design im Normalfall ausreichend. Außerdem lässt sich so das Feedback der Nutzer*innen im Laufe des Entwicklungsprozesses kontinuierlich nutzen.
Der Fokus der bisher beschriebenen Prinzipien liegt auf einer kurzfristigen und flexiblen Planung. Ein Prinzip von Lean UX, das sich hieraus beinahe automatisch ergibt, ist die Betonung des ständigen Lernens. Wenn bei der Planung der nächsten Schritte, die bisher in vergangenen Iterationen gemachten Erfahrungen – besonders hinsichtlich des Geschäftserfolgs einzelner Features – berücksichtigt werden, hat ein kontinuierlicher Lernprozess eingesetzt.
Allerdings geht die Idee bei Lean UX noch einen Schritt weiter. Statt nur auf die Resonanz des Markts in Form von Geschäftserfolg und Support-Anfragen zu warten, wird auf eine aktive Nutzerforschung gesetzt. Hierbei spielen sowohl objektive Messungen (z. B. "Wie viele Klicks?") als auch subjektive Wahrnehmungen (bspw. "Warum haben Nutzer*innen geklickt?") eine wichtige Rolle. Maßgebend ist hierbei vor allem, dass diese Forschung regelmäßig durchgeführt wird und dass das gesamte Team involviert ist.
Das mehrfach erwähnte beständige Lernen ist gemäß Lean UX gerade zu Beginn deutlich wichtiger als Wachstum. Denn es ist immer mit einem Risiko behaftet, wenn eine Idee skaliert wird, obwohl sie noch keine Bestätigung durch den Markt und dessen Nutzer erfahren hat. Um dieses Risiko zu minimieren und einer möglichen Verschwendung von Ressourcen vorzubeugen, sollte Wachstum erst eine Rolle spielen, wenn man seine Idee bereits validiert hat.
Bei so vielen Hypothesen, Experimenten und dem ständigen Lernen werden Misserfolge voraussichtlich nicht ausbleiben. Wichtig ist jedoch auch mit diesen effizient umzugehen, da man nur aus Misserfolgen Lehren für die Zukunft ziehen kann. Wer hingegen nur diskutiert und nichts probiert, hat einen weitaus geringeren Lernerfolg und bleibt beim gleichen Wissensstand wie zuvor.
An diesem Punkt spielt die Fokussierung auf überschaubare Planungszeiträume und kleine Arbeitspakete eine wichtige Rolle. Denn nur so kann man sich auch Misserfolge erlauben. Diese Kultur des Experimentierens ist manchmal nicht ganz einfach durchzusetzen, bringt auf lange Sicht aber die Gewissheit, auf experimentell bestätigtem Wissen aufzubauen.
Bei Lean UX kommt dem "Machen" eine weitaus größere Bedeutung zu als dem "Analysieren". Kernidee ist hierbei, dass echte Nutzer*innen zu Rate gezogen werden und sich nicht ein Team in komplizierten und langwierigen Diskussionen verliert. Voraussetzung hierfür ist jedoch eine nutz- und testbare Version des eigenen Produktes oder der eigenen Idee.
Dementsprechend ist es deutlich sinnvoller, eine erste, einfach Version umzusetzen, statt sich in einer perfektionistischen Planung zu verlieren. Nur eine nutzbare Version ermöglicht es nämlich, direktes Feedback von Nutzer*innen sowie vom Markt zu bekommen. Dieser Rückmeldung - egal ob objektiv oder subjektiv - ist darum immer der Vorzug zu geben.
Lean UX hilft Unternehmen dabei, unnötigen Balast zu eliminieren und effizienter und nutzerzentrierter Produkte zu entwickeln. Dabei profitieren Unternehmen durch kurze Iterationen, interdisziplinäre Teams und ständigem Nutzerfeedback.
Möchten Sie Lean UX in Ihrem Unternehmen einführen? Dann kontaktieren Sie uns und wir stehen Ihnen unterstützend zur Seite!
Sie haben Fragen?
Wir beraten Sie gerne!