UX Design im agilen Umfeld

Als ich zum ersten Mal selbst Teil eines agilen „Scrumban“ Teams wurde, fühlte sich das so an, als wäre ich in eine Waschmaschine geworfen worden, die im Schleudergang läuft: ich fühlte mich völlig orientierungslos.

„Agil“ hat mich von diesem Moment an fasziniert und furchtbar genervt. Genervt, weil der Versuch agil zu sein, in meinen Erlebnissen auch oft zu Stillstand statt zum Flow geführt hat, weil die äußere Realität oft so viel anders aussah als die teaminterne, und die agilen Spielregeln per Definition „easy to understand, difficult to master“ sind (vgl. Scrum Guide). Aber ich habe auch viele positive Erfahrungen gemacht, mich selbst agil weiterentwickelt und viele inspirierende Agilisten kennengelernt. Gerne möchte ich meine Transformation als User Experience Designerin im agilen Umfeld mit Ihnen teilen.

Stufe 1: Du bist was du wirst

In meinem Studium sah agile Projektarbeit ungefähr so aus: Das Semester über überschlugen wir uns mit Ideen, experimentierten, sammelten alles Mögliche an Informationen, Tools, Wissen und als die Abgabe dann gefährlich nah kam, sprinteten wir in wenigen Tagen (und Nächten) durch die Umsetzung. Ich habe mein Studium geliebt und die Freiheit, die wir hatten. Aber wir waren auch ziemlich unter uns, Designer unter Designern. In unseren Projekten haben wir häufig die ganze Entwicklungskette abgedeckt, es gab den Freiraum, die Dinge zu lernen, die wir brauchten, um unsere gemeinsame Vision umzusetzen, und auf diese Weise konnten wir Berge versetzen.

Mit meinen ersten Arbeitserfahrungen platzte diese Blase. Hier hatte ich häufig das Gefühl nur noch eins zu sein: Lieferant. Die Designlieferung hatte stets pünktlich („vorgestern“) und innovativ zu sein. Kommunikation mit der Entwicklung bestand meistens darin, dass von dort weitere Anforderungen an das Design diktiert wurden. Dass dies kein funktionierender Prozess war, zeigte sich damals ganz schmerzlich, als wir ein halbes Jahr an einem neuen Produkt gearbeitet hatten, für das es nie einen echten Kunden gab. Es war an der Zeit umzudenken und meine eigene Rolle neu zu definieren.

Der Designer als Lieferant innovativer Ideen

Memo: Auch wenn jeder seinen Hintergrund hat, es gibt am Ende mehr Dinge die Softwareentwickler und Designer (und Product Owner, Produktmanager, Sales Verantwortliche, Support Mitarbeiter…) verbindet, als sie voneinander trennen – alle haben das Ziel ein gutes Produkt zu erschaffen, dass sich verkaufen lässt und auf dem Markt bestehen kann.

Stufe 2: Wenn man im reißenden Fluss schwimmt …

…. ist es gar nicht so leicht dem Wasserfall zu entkommen. Wir spulen ein paar Jahre nach vorne: In einem Projekt, bei dem es grob um die Möglichkeit einer manuellen Dateneingabe ging, hatte unser UX Team mittels Design Thinking viel Aufwand betrieben, um Nutzerbedürfnisse zu identifizieren und daraus Ideen und Prototypen zu entwickeln und zu validieren. Die letztendliche User Story wurde vom Product Owner beschrieben: Es sollte erst einmal ein MVF (Minimal Viable Feature) umgesetzt werden, um zu schauen, welche Auswirkungen das Feature hat und wie die Nutzer es tatsächlich verwenden. Am Ende wurde ein CSV Upload umgesetzt. Bei den Nutzern angekommen war der Upload auf Grund der geforderten Datenformatierung nicht nutzbar. Also wurden im UX Team Fehlermeldungen und Validierungsschritte designed, um den Nutzer bei der richtigen Formatierung zu unterstützen. Mit einem großen Mehraufwand seitens der Entwicklung und aus Nutzersicht eher eine Krücke als eine zufrieden stellende Lösung. Frustriert waren am Ende alle.

Wer bei dieser kleinen Geschichte vor dem geistigen Auge einen Wasserfall die Klippe hinabrauschen sieht, hat das Szenario ganz gut beobachtet. Man könnte diesem Erlebnis auch den Titel geben: „Design Thinking vs. Requirements Engineering vs. agile Entwicklung“. Die Nutzeranforderung wandert von Silo zu Silo und veränderte sich und wenn das Feature endlich beim Kunden ankommt, ist es nicht mehr das was er erwartet hat. Und um es gleich klar zu stellen: zu diesem Ergebnis trägt jeder seinen Teil bei.

Gar nicht so leicht dem Wasserfall zu entkommen, vor allem wenn man es sich darunter schon bequem gemacht hat

Memo: Scrum ist kein Prozess – ebenso wenig wie Design Thinking, Lean UX oder Design Sprint. Es gibt viele Leerstellen in den Beschreibungen, Verbindungsteile sind nicht immer vorgeben oder unspezifisch, die Haltung oder das Mindset kann man sich nicht anlesen. Dieser Freiraum bedeutet, dass wir die Möglichkeit haben, Zusammenarbeit zu gestalten, es bedeutet aber auch, dass wir es tun müssen, denn von alleine passiert es nicht. In diesem Sinne: Auf ein Neues, zurück zu Stufe 1, die nächste Iteration beginnt.

Stufe 3: Better together

Im Internet finden sich viele lustige Grafiken zum Thema „UX in Agile integrieren“. Bei den meisten wird mir jedoch schon beim Betrachten schwindelig, angesichts der vielen Loopings und Kreisverkehre. Und auch die strikte Trennung nach Frameworks und Methoden birgt für mich nach wie vor die Gefahr von Silostrukturen: Wie stellen wir sicher, dass bereits Gelerntes auch wieder in den Prozess zurückfließt, anstatt dass sich die Katze immer wieder in den eigenen Schwanz beißt?

Lange Zeit habe ich als UXler in verschiedenen Projekten versucht, vor allem durch Argumentieren die Nutzerbedürfnisse zum Thema zu machen. In einem Meeting ging es zum Beispiel darum, welche zusätzlichen KPIs wir auf dem Dashboard anzeigen können. Als selbsternannter „Anwalt der Nutzer“ argumentierte ich, dass einige der vorhandenen Visualisierungen bereits nicht ausreichend die Fragen der Nutzer beantworteten und ob wir diese nicht aussagekräftiger machen können, bevor wir weitere Komplexität erzeugen. Daraufhin entbrannte eine Diskussion, ob denn heute wirklich alles schlichtes „Apple-Design“ sein muss. Und wir entfernten uns meilenweit vom eigentlichen Thema. Die Erkenntnis: Meinungs-Diskussionen führen selten bis gar nicht zu Lösungen. Meine neue Strategie bestand nun darin, meine gefühlte Verantwortung für den Nutzer nach und nach abzugeben, frei nach dem Motto: „User Experience fängt im Backend an und hört beim User Interface noch lange nicht auf.“

Seither hat sich meine Rolle ziemlich geändert. Anstatt Lieferant oder UX-Prediger bin ich heute gerne Coach, Moderator und Methodenkoffer. Ich setze Workshops auf, die dem aktuellen Projektbedarf entsprechen und beteilige unterschiedliche Disziplinen am Designprozess. Ab und an beschleicht mich das Gefühl, ob ich mich auf diese Weise nicht irgendwann überflüssig mache. Als Designerin bin und bleibe ich jedoch Expertin dafür, Dinge zu visualisieren und (be-)greifbar zu machen.

Better together – im Sandkasten wird auch mal gezankt, aber gemeinsam schafft man es viel besser, aus dem losen Sand tolle Dinge zu formen

Memo: Die Methoden und Frameworks einfach ineinander zu basteln und ideologisch zu verfolgen, macht die Dinge nicht weniger kompliziert und das Endergebnis nicht besser. Aber wie schafft man es dann tatsächlich Brücken zwischen den Inseln zu bauen und agil zu arbeiten? Im Grunde liefert das agile Manifest hierfür aus meiner Sicht eine wunderbare Antwort: Individuen und Interaktionen mehr als Prozesse und Werkzeuge. Also, setzt euch zusammen und findet heraus was euch verbindet.

Stufe 4: Wer schon agil ist, kann nicht agil sein

Diese schöne Überschrift habe ich vor ein paar Wochen beim Agilen Stammtisch Karlsruhe gehört. Und in der Tat bin ich immer skeptisch, wenn ein Unternehmen sagt „es sei agil“, weil im Agilen letztendlich immer der Mechanismus einer kontinuierlichen Veränderung steckt. Ebenso wenig glaube ich daran, dass Design Thinking oder andere Formen der nutzerzentrierten Gestaltung alle großen Probleme automatisch lösen. Denn am Ende stehen meistens Ideen, aber noch keine Umsetzung.

Die Methoden und Frameworks helfen dabei eine gute Basis zu schaffen, um Lösungsräume zu öffnen und Nährboden für Innovationen zu schaffen oder aber die Umsetzung anzustoßen und zu takten. Die Methoden in einem Prozess einfach hintereinander oder ineinander zu schalten, reicht aber nicht aus. Es braucht einen Dialog und Reflexion, um ein agiles Umfeld zu schaffen – an diesem wirken letztendlich alle Beteiligten mit.

Statt sich in der agilen Waschmaschine herum schleudern zu lassen, kann man sie auch mal von außen betrachten, um von Umdrehung zu Umdrehung weiter dazu zu lernen

Memo: Agil heißt für mich „Reagieren können auf Unsicherheit und Veränderung“. Da ich nicht weiß, was mich in Zukunft erwartet, hört auch mein persönlicher Transformations-Prozess selbstverständlich nicht auf. In diesem Sinne: Auf ein Neues, zurück zu Stufe 1, die nächste Iteration beginnt.

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Diesen Beitrag finden Sie auch im kostenlosen Blogpaper User Experience – Fünf Perspektiven auf User Experience.

Anna Zinsser hat im t2informatik Blog weitere Beiträge veröffentlicht, u. a.

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.