Agiles UCD – Best Practices

Da die Einführung agiler Techniken massiven Einfluss auf die Art und Weise der Zusammenarbeit von Management- und Entwicklungsteams in einem Projekt zur Folge hat, werden natürlich auch die UCD-Aktivitäten und deren Anwendungsmöglichkeiten in einem agilen Projekt davon beeinflusst.
 

Die Formen der Zusammenarbeit variieren von Projekt zu Projekt, um den Bedürfnissen des jeweiligen Kunden gerecht zu werden. Von einer engen Zusammenarbeit zwischen Designern und dem Entwicklungs-Team vor Ort bis hin zu Designern, die nur bei Bedarf vom Projekt-Team hinzugezogen werden, um Wireframes oder Screen-Designs den Anforderungen entsprechend zu liefern, ist eine weite Spanne der Zusammenarbeit möglich. Die letztlich gewählte Vorgehensweise hängt stark von einigen Faktoren ab, die für jedes Projekt separat festgelegt werden müssen (z.B. Re-Design vs. Neu-Entwicklung, In-house-Expertise, Vor-Ort-Präsenz des Teams oder Verfügbarkeit von Benutzern).

 

Abbildung 1. Design- und Entwicklungs-Track arbeiten parallel zusammen
 

Der agile Entwicklungsprozess erfordert eine entsprechende Anpassung der UCD-Techniken. Sowohl die vorhandene Dokumentation im Internet [siehe Weiterführende Literatur] als auch unsere Erfahrung belegen, dass eine Vorbereitung der Iterationen von elementarer Bedeutung ist, so dass zum Start einer Iteration wenigstens ein grober GUI-Entwurf als Richtungsvorgabe verfügbar ist. Dies bringt den großen Vorteil, dass solche Entwürfe als Diskussionsgrundlage in den Teams und in Gesprächen mit dem Produkt-Verantwortlichen genutzt werden können. Selbst eine Validierung der Entwürfe – bevor auch nur eine Zeile Code geschrieben wurde – ist z.B. mittels Paper-Prototyping mit Endanwendern möglich.
 

Die Dauer dieser Vorbereitungsphase hängt vom Umfang der Gesamt-Vision ab, die zu Beginn des Projektes festgelegt wurde, da sie das UI-Design einer Iteration stark beeinflussen kann (z. B. soll das UI in einem Dialog-Fenster oder in einem In-place-Element dargestellt werden?).
 

Wir empfehlen daher nachhaltig, die „Zyklus 0-Phase“ zu Beginn eines Projektes zu nutzen, um eine visuelle Darstellung der Vision auf Wireframe-Basis zu entwickeln, die als zentrales Leitmotiv genutzt werden kann. Dieses Vorgehen wird, insbesondere, wenn Sie mit verschiedenen Teams parallel arbeiten, das Risiko mindern, dass sich zwischen den Teams Konsistenz-Probleme ergeben oder in komplett unterschiedliche Richtungen entwickelt wird. Um jedoch sicherzustellen, dass diese Vision noch den Anforderungen entspricht, muss sie regelmäßig überprüft und gegebenenfalls angepasst werden.

 

Zusammensetzung der Teams
 

Die Zusammensetzung der Teams kann, wie bereits erwähnt, sehr stark von den Begleit-Faktoren des Projekts abhängen. Am wichtigsten ist jedoch, dass jedes Team über einen GUI-Verantwortlichen verfügt.
 

Abhängig von der jeweiligen Projektphase können einige Aufgaben in Hinsicht auf Design, Analyse und Testing parallel ablaufen, wie Abbildung 1 illustriert.

 

User Research support group

 

Dies kann mithilfe einer „second-line“ User Research Support Group (siehe Abbildung 2) kompensiert werden, die Fragestellungen aus den Teams mit Endanwendern bespricht und die Ergebnisse zurückmeldet. Auf diese Weise erlangt das Support-Team einen guten Überblick über die verschiedenen UI-Projekte und kann seine Verbindungen zur User-Community nutzen, um Lightweight Usability-Tests zu organisieren.
 

Design-Scrum-of-Scrums
 

Zusätzlich hat sich ein „Design-Scrum-of-Scrums“ als sehr sinnvoll erwiesen, um die verschiedenen Design-Lösungen anderer Teams im Blick zu behalten. Das bedeutet , es sollten im Anschluss an die Stand-up-Meetings der Teams regelmäßige Meetings mit deren GUI-Verantwortlichen durchgeführt werden. Auf diesem Weg können die Designer unmittelbar über neue Komponenten, Layout-Schwierigkeiten oder Probleme mit der Gesamt-Vision informiert werden, die dann entsprechend dem Input der Teams angepasst werden kann.
 

UCD-Ergebnisse & Aufgaben, abhängig vom Projekt-Level
 

In einigen unserer bisherigen Projekte wurde ein WIKI eingesetzt, um Informationen zur Gesamt-Vision, zu verschiedenen Projekten und den gefällten Entscheidungen zu speichern. Sobald gewisse Aspekte des User Interface verankert sind (z.B. Icons, Farben, Interaktions-Pattern) kann ein WIKI ebenso dazu verwendet werden, nach und nach eine Sammlung von Richtlinien aufzubauen, die auf weitere Design-Entwürfe in anderen Releases angewandt werden können.
 

Die nachfolgenden Abschnitte werden etwas tiefer auf die vom jeweiligen Projekt-Level abhängigen UCD-Ergebnisse eingehen.
 

Projekt-Ebene
 

Obwohl viele agile Methodiken eine häufige Einbeziehung oder Konsultierung von Endanwendern vorsehen, kann es manchmal schwierig sein, täglichen Zugang zu Benutzern zu bekommen. Ebenso problematisch kann es sein, wenn ein Benutzer die Last tragen muss, die komplette User-Community zu vertreten. Dies ist häufig ebenso wenig realistisch.
 

UCD-Aktivitäten wie z.B. eine User/Task-Analyse helfen zu verstehen, wie Endanwender ihre Arbeit tatsächlich ausführen und können das Projekt-Team beim Zusammentragen der Projekt-Anforderungen unterstützen.
 

Die gesammelten Anforderungen können nun in eine initiale Wireframe-Version des neuen Tools fließen, die zur Kommunikation der Vision innerhalb des Unternehmens, aber auch zur Verifikation bestimmter UI-Konzepte mit Benutzern verwendet werden kann. Der Fokus sollte dabei auf globale Aspekte des User Interface hinsichtlich Struktur und Interaktion gelegt werden. Die in den Wireframes visualisierten Informationen können im Anschluss ebenso dazu genutzt werden, die Gesamt-Applikation stufenweise in einzelne Bereiche für die unterschiedlichen Releases und Iterationen aufzuteilen.
 

Abbildung 3
 

Release Ebene
 

Die Visionen-Wireframes können nun in einer angepassten und weiter ausgearbeiteten Form dazu genutzt werden, den korrekten Scope und die Anforderungen eines Projekts auf Release-Ebene abzustecken (z.B. „Für das erste Release hätten wir gerne eine befüllte Navigation, wobei die verfügbaren Daten im Content-Bereich angezeigt werden“).

 

Abbildung 4

 

Iterations-Ebene
 

Der Wireframe kann nun für jede Iteration eines Release in verschiedene Teilstücke zerlegt und im Detail beschrieben werden.

 

Abbildung 5

 

Auf Iterations-Ebene sollten Wireframes als eine leichtgewichtige Möglichkeit zur Dokumentation von Design-Entscheidungen gesehen werden. Es hat sich als sehr effizient herausgestellt, Screenshots auszudrucken und sie an die „Agile Wand“ des Projekt-Teams zu heften. Diese hat in vielen Projekten als sehr nützliche Anlaufstelle für Diskussionen rund um das Tool gedient.

Sobald das Design für eine Iteration finalisiert ist, kann der Designer Zeit in die Produktion der benötigten Assets wie Icons oder andere Arten von Grafiken investieren. Falls Entscheidungen getroffen werden, die Einfluss auf die Mock-ups der höheren Ebenen haben, so sollte das Design-Team darüber informiert werden und bei Bedarf die entsprechenden Mock-ups angepasst werden.

Selbstverständlich darf auch die Vorbereitung der nächsten Iterationen mit Hinblick auf User Research (siehe Abbildung 2) und Wireframes (siehe Abbildung 1) nicht vergessen werden zu erwähnen.

 

Fazit
 

Die zentrale Schlussfolgerung unserer Erfahrungen mit agilen Projekten ist die, dass es keinen einheitlichen Weg gibt, ein agiles Projekt durchzuführen. Beide Methodiken, UCD und Agile, müssen aneinander angepasst werden, um den optimalen Weg einer fruchtbaren Interaktion zu finden. Diese Anpassungen beruhen stark auf verschiedenen Faktoren, wie z.B. ob es sich um eine Produkt-Erweiterung oder eine Neu-Entwicklung handelt, ob In-House-Expertise vorhanden ist, ob Vor-Ort-Präsenz des Teams gegeben ist oder auch wie es um die Verfügbarkeit von Benutzern bestellt ist.

Aus unserer Sicht können UCD-Methoden, wie z.B. eine User/Task-Analyse mit dem Ziel zu Beginn Anforderungen zu sammeln, das Entwerfen von Wireframe-Mock-ups zur Validierung von Konzepten in sehr frühen Projekt-Phasen, sowie unsere Erfahrungen mit dem Testen von Software an verschiedenen Schritten des Projekts, der Entwicklung einfach zu bedienender Software in einem agilen Prozess einen echten Mehrwert bieten.