UX Konferenz London – Tag 5: Lean UX und Agilität

Lean UX und Agilität

Am heutigen Tag habe ich den Kurs Lean UX und Agilität bei Rachel Krause belegt. Am Anfang ging es erst einmal um das grundlegende Verständnis von Agilität. Anschließend hat Rachel die Probleme der Disziplin UX im agilen Umfeld, vor allem in SCRUM, beschrieben:

• UX ist in Unterzahl gegenüber Entwicklern vertreten
• Oft wird UX nicht genügend Zeit eingeräumt
• Der Prozess ist in Sprints oft sehr eingeschränkt, um eine größere Vision zu entwickeln
• UX wird oft als Flaschenhals gesehen
• UX soll lieber Visuelles sehr genau aufbereiten, als Arbeit zu dokumentieren.

Rachel präferiert folgendes Modell für agile Teams:

Als Richtlinie für UX gilt: UX muss im agilen Umfeld früh, viel und nicht allzu detailliert kommunizieren. Mit „nicht allzu detailliert“ meint sie, dass wir nicht darüber diskutieren sollten ob Radio Buttons oder Dropdowns für eine Auswahl verwendet werden sollen, sondern dass eine Auswahl stattzufinden hat.

Design Sprint

Von SCRUM Mastern und vielen „Agile- Anhängern“ sehr unbeliebt: Der sogenannte Sprint 0. In diesem Sprint, der vor der eigentlichen Entwicklung stattfindet, hat ein UXler die Möglichkeit einen Sprint, wie ihn auch Jake Knapp in seinem Buch Sprint beschreibt, durchzuführen.

Tag 1: Das Problem identifizieren und verstehen.

Tag 2: Problemlösungen und Ideen entwickeln, um das Problem zu lösen.

Tag 3: Entscheiden welche Lösung verwendet wird. Erarbeiten eines Plans, wie dies prototypisch umgesetzt werden kann.

Tag 4: Prototypen bauen.

Tag 5: Den Prototypen am wirklichen Nutzer validieren.

LEAN UX

Im weiteren Verlauf ging Rachel auf die Vorteile von LEAN UX ein und darauf, dass dadurch Risiken minimieren kann.

 

Diese Risikominimierung gilt an dieser Stelle nicht nur für UX, sondern für das gesamte agile Vorgehen. Rachel spricht sich dafür aus, einen regelmäßige User Research im Unternehmen zu etablieren. Als Beispiel könnte man jeden 2. Mittwoch oder den letzten Donnerstag des Monats dafür verwenden. Wichtig ist vor allem eine planbare Regelmäßigkeit.

Story Mapping

Im nächsten Schritt wurde der Kurs wesentlich praktischer. In kleinen Gruppen sollten wir im Zuge einer kleinen Aufgabe eine Story Map erstellen. Diese Story Map wurde komplett aus Nutzersicht kreiert. Zuerst werden die Aktivitäten, die der Nutzer machen muss, sehr grob dargestellt. Daraufhin wird es etwas konkreter (auf Epic-Ebene), um dann anschließend auf Story-Ebene herunterzugehen.

Nach der Mittagspause sollten wir aus den bisherigen Ergebnissen einen MVP erstellen. Ein MVP ist ein Minimum Viable Product. Dies bedeutet nicht nur ein funktionales Produkt. Ein MVP ist mehr als das. Ein MVP muss verkäuflich, benutzbar, wünschenswert (für den Nutzer) und realisierbar sein.

User Stories

Rachel ging auch auf User Stories und deren Probleme mit UX ein. Eine gute User Story aus Entwicklersicht reicht für UX nicht aus. Stories beziehen sich nicht auf eine Vision. Für UX muss diese aber deutlich sein. Wenn ein UXer nur nach den Kriterien von einzelnen User Stories arbeiten würde, dann läuft es auf folgendes Sprichwort hinaus: „Viele Köche verderben den Brei.“

Lean UX in SCRUM

UX im SCRUM sollte normalerweise vor der eigentlichen Entwicklung stattfinden. Falls UX parallel zur Entwicklung arbeiten soll, dann geht das nur mit sehr viel Kommunikation und bei sehr kleinen spezifischen Problemen. Allerdings muss auch UX im SCRUM einen bestimmten Rhythmus einhalten. So sagt Rachel, dass auch UX nicht mehr als 3 Sprints voraus arbeiten soll. Die folgende Abbildung erklärt, was der UXer in einem Sprint zu tun hat.

 

Kanban Board

Als Best Practice empfiehlt Rachel UX auf ein eigenes Kanban Board zu bringen. Diese hätte den Vorteil, dass alle im Team sehen können woran UX gerade arbeitet. Des Weiteren würde so auch der Fortschritt von UX gemessen werden können. Wobei Rachel ganz klar sagt, dass UX keine Velocity hat wie ein SCRUM Team, sondern daran gemessen werden soll, dass das Entwicklungsteam nicht auf UX warten muss.

The only measure of UX velocity that matters is whether or not you’re holding up the development team.” Erik L., UX Consultant and Designer

Der Design Prozess

Rachel empfiehlt, dass im eigentlichen Design Prozess in Unternehmen vor allem zwei Dinge dem UXer im SCRUM Team helfen können. Ein übergeordneter Styleguide hilft dabei, dass sich der Team UX nicht mehr um die Details der Visualisierung kümmern muss.

Zudem sei es sehr praktisch das gesamte Team in die Ideengenerierung miteinzubeziehen. Dabei stellt sie die 6-up, 1-up Methode vor. Dabei wird ein bestimmtes Problem vom Team bestimmt, welches anschließend gelöst werden soll. Jedes Teammitglied erhält ein DINA4 Blatt. Dieses wird in 6 gleich große Teile gefaltet. Nun hat das Team insgesamt 5 Minuten Zeit, jeder für sich, 6 Ideen zur Problemlösung auf das Blatt zu zeichnen. Danach stellt jedes Teammitglied den anderen Mitgliedern seine gezeichnete Idee vor. Anschließend hat wieder jeder 5 Minuten auf der Rückseite des Blatts Zeit, eine weiterentwickelte Idee detailliert zu zeichnen. Dabei ist es egal, ob dies eine der eigenen Ideen ist oder die eines anderen Mitglieds. Vielleicht ist es auch eine Hybrididee. Der UXer des Teams sammelt anschließend alle Ideen ein und sollte diese nach Möglichkeit mit in die Problemlösung einbeziehen.

Fazit

Viele Ansätze, die Rachel präsentiert hat, beschreiben auch meine Erfahrung mit UX im agilen Umfeld. Die Ansätze zur Lösung der Probleme sind sehr praktisch und können sicherlich über einen mittelfristigen Zeitraum in den Unternehmen integriert werden. Einige der Methoden, die Rachel aufgezeigt hat, können direkt im SCRUM Alltag weiterhelfen.