UX und Agile? Passt!

Sprint Zero für das agile User-Experience-Design
Kommentare

User Experience und agiles Arbeiten sind auf den ersten Blick gut miteinander vereinbar. Immerhin steht die Frage, wie der Nutzer künftig mit dem Produkt interagieren wird, im Zentrum der agilen Planung. Schlussendlich ist es aber doch nicht so einfach. UX-Experten und Designer arbeiten nämlich ganz anders als Entwickler und ihre Vorgehensweisen sind nicht ohne Weiteres mit den typischen agilen Methoden kompatibel.

Zum Designprozess eines guten User Interface gehören viele komplexe Arbeitsabläufe. Zuerst entsteht eine Idee, die dann zu einem digitalen Entwurf wird. Dieser wird dann getestet, geändert, getestet und irgendwann, am Ende des Prozesses, liegt dann ein fertiges, benutzbares Design vor. Das braucht allerdings seine Zeit, immerhin werden dabei echte (zukünftige) Nutzer befragt und die Ergebnisse ausgewertet.

Natürlich ist die dazu notwendige Zeit auch vom Projekt abhängig; in auf zwei Wochen angelegten Sprints lässt sich der Prozess aber nur schwer unterteilen. Übergreifende Userinteressen gehen ohne eine langfristige Planung schnell unter – wer weiß heute schon, was die Nutzer bei der Verwendung von Feature x möchten, wenn das erst in einem halben Jahr entwickelt wird?

Sprints vs UX

Sprints und kurzfristige Planungsintervalle stellen aber das Herzstück jeder agilen Softwareentwicklung dar. Ohne kurze Iterationen, an deren Ende eine benutzbare, auslieferbare Version eines Features steht, ist ein agiles Arbeiten kaum möglich. So bleibt der Kunde immer auf dem neusten Stand und kann ständig Feedback zum Produkt geben. Entscheidungen werden immer basierend auf diesen Rückmeldungen getroffen, langfristige Pläne werden nur sehr rudimentär entworfen.

Alles, was mehr als vier Wochen entfernt ist, hat noch zwei Wochen Zeit, so könnte man das agile Arbeiten wohl zusammenfassen. Das funktioniert aber nicht, wenn Interviews mit echten Nutzern geplant werden müssen – oder das übernächste Feature eben doch ganz andere UX-Anforderungen stellt, als gedacht.

Stellen Sie Ihre Fragen zu diesen oder anderen Themen unseren entwickler.de-Lesern oder beantworten Sie Fragen der anderen Leser.

Natürlich können die Methoden des UX-Designs und -Testings auf die agile Arbeitsweise angepasst werden. Dazu bedarf es allerdings einiger Veränderungen, die sowohl die agilen Konzepte als auch die grundlegenden Überzeugungen der UX-Profis betreffen.

Maßstäbe anpassen

Der klassische UX-Entwurf ist aufwändig zu erstellen. Auf eine Zeichnung folgt ein digitaler Entwurf, auf welchem dann die ersten Tests beruhen um dann erneut mit einer Zeichnung zu beginnen und darauf aufzubauen. Dieser Vorgang lässt sich schlanker, schneller gestalten. Unter dem Titel „Discount Usability“ hat Jakob Nielsen bereits im Jahr 1989 ein Konzept des UX-Testings vorgestellt, das in Zeiten der agilen Arbeitsweise immer absolut wichtig ist.

Er schlägt vor, statt großer Studien mit vielen Nutzern nur drei, maximal aber fünf User zum Produktdesign zu befragen. Die meisten massiven Fehler lassen sich so nämlich auch finden; der Vorteil größer angelegter Tests überwiegt allerdings im Verhältnis zum erhöhten Aufwand nicht. Auch schlägt er vor, mit Papier-Prototypen zu arbeiten, statt jeden Entwurf aufwändig in ein digitales Design zu übertragen, nur um ihm zu verwerfen.

UX-Design-Strukturen anpassen

Dadurch lässt sich viel Zeit im Usability-Testing einsparen. Im Weiteren kann außerdem eine analoge Struktur zu der des agilen Arbeitens aufgebaut werden. So könnte es feste Test-Tage geben, die jede oder jede zweite Woche durchgeführt werden. Zwei bis drei Nutzer können auch regelmäßig befragt werden; dazu braucht es nicht einmal immer fertige Layouts. Entwürfe eignen sich genauso gut zur Diskusion!

Das daraus entstehende regelmäßige Feedback kann dann genutzt werden, um stetig im Kontakt mit anderen Projektbeteiligten zu bleiben. Wer selbst nichts zu berichten hat, mag das unnötig finden – wer aber das neuste User-Feedback zur Debatte stellen möchte, nimmt auch gern an Sitzungen dazu teil. Agiles arbeiten bedeutet Kontakt und so wird das UX-Design-Team zum Teil der agilen Mannschaft.

Der Sprint Zero

Aber das Geschilderte betrifft ja erst einmal nur das UX-Team, nicht die Entwickler. Zwar verbessert sich die Zusammenarbeit so auch. Ausreichend ist das aber nicht, um zu gewährleisten, dass das UX-Design nicht hinter anderen Interessen der agilen Entwicklerschaft zurückstecken muss. An dieser Stelle kann ein so genannter Sprint Zero dabei helfen, das User-Experience-Design zum zentralen Element des gesamten Entwicklungsprozesses zu machen.

Der sogenannte Sprint Zero ist ein eher umstrittenes Konzept in der agilen Arbeitsweise. Er ist kein offizieller Bestandteil der gängigen Frameworks, sondern eine Addition einzelner agiler Coaches und Unternehmen. Er ist dazu da, bereits vor Projektstart einige grundlegende Dinge zu klären.

Mancher mag nun einwenden, dass alles, was vor Beginn des Projekts stattfindet, gar nicht zum Projekt gehört. So könnte ja auch die Rekrutierung von Mitarbeitern plötzlich zu einem Sprint ernannt werden oder die Erstellung des Auftrags seitens des Kunden. Natürlich ist diese Kritik nicht unbegründet – immerhin ist der Sprint Zero ja eine Iteration ohne funktionstüchtiges, greifbares Ergebnis für den Kunden und erfüllt somit eigentlich nicht die Kriterien, denen ein Sprint im agilen Arbeiten genügen muss.

Epische Designmaßstäbe

Im Designprozess kann es aber sehr sinnvoll sein, einen Sprint Zero zu nutzen. Wie Danny Bluestone erklärt, handelt es sich dabei um eine Arbeitsphase der Designer des Projekts, die stattfindet, bevor alle anderen Beteiligten ihre Arbeit aufnehmen. Das Design-Team legt nun eine Art Richtlinie fest, an der sich alle Entscheidungen bezüglich der User Experience im Projektverlauf orientieren sollen. Abweichungen von diesen Vorstellungen müssen immer mit den Designern besprochen werden.

Ein Kernbestandteil dieser Richtlinien sind die sogenannten Epics. Das sind die Ziele, die im UX-Design erreicht werden sollen, die persönlich auf die einzelnen Nutzergruppen zugeschnitten werden. Es handelt sich um ausformulierte Vorstellungen davon, wie das Projekt am Ende benutzbar sein soll – insofern sind sie eine tolle Grundlage für und Ergänzung zur Product Story und bestens zur Integration ins agile Arbeiten geeignet.

Kooperation

Multifunktionale Teams können auch eine gute Möglichkeit darstellen, um die Relevanz des Design-Prozesses im agilen Arbeiten nicht aus den Augen zu verlieren. Wenn Designer zum Entwicklerteam gehören, spielt ihre Aufgabe eine ganz andere Rolle als wenn sie ein eigenes Team bilden. Die Zusammenarbeit über Fachgrenzen hinweg wird von der agilen Methodik unterstützt, diese Chance sollte wo möglich genutzt werden. Trotzdem müssen Designer aber auch dann die Freiheit behalten, lang- und nicht kurzfristig zu planen.

Alternativ kann das Projekt aber auch abwechselnd bearbeitet werden. Auf einen Sprint der Entwickler könnte jeweils ein Sprint der Designer folgen, die ihre in der Zwischenzeit entworfenen Layout-Entwürfe nun mit den neusten Ergebnissen der Entwickler in Einklang bringen können. Zurück bekommen die Entwickler dann ein Produkt, das mit den UX-Standards übereinstimmt und mit dem sich weiterarbeiten lässt. Auch so werden große, späte Veränderungen vermieden und die Zusammenarbeit wird gestärkt. Immerhin möchte ja niemand alle zwei Wochen erneut von vorne anfangen und das retten, was die Kollegen eigenmächtig verändert haben.

Alternativ: Eine gute Basis wählen

Soll das Design aber dennoch schnell gehen und mit wenig Einfluss der Design-Experten durch das Entwickler-Team im Rahmen von Sprints erstellt werden, kann man außerdem auf gängige Standards zurückgreifen. Ein gutes Beispiel dafür ist das Material Design, das auf eine optimale Usability ausgelegt ist. Wer nicht viel in UX-Testing und Co. investieren will, kann gut damit beraten sein, auf ein derartiges Framework zurückzugreifen und nur in der eigenen Farbgestaltung davon abzuweichen. So werden große Fauxpas bereits von Anfang an vermieden.

Am Ende sind Design-Interessen und die agile Arbeitsweise aber auch nicht unvereinbar. Es mag ein wenig Aufwand mit sich bringen, einen klassischen UX-Design-Prozess auf agile Arbeitsweisen anzupassen, aber es lohnt sich durchaus. Immerhin ist regelmäßiges Feedback und ein konstanter Austausch etwas, wovon nicht nur die Entwickler, sondern auch die Designer eines Projekts profitieren können.

 

Aufmacherbild: Numbers on running track – added vignette lets you focus on the numbers via Shutterstock / Urheberrecht: Peter Bernik

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -