User Experience-Projekte mit agilen Methoden
Agile Software-Projekte sind noch nicht völlig nutzergesteuert, aber neue Forschungen zeigen, dass die Entwickler grundlegende Nutzererlebnis-Belange tatsächlich optimistischer einschätzen als UX-Experten.
by Jakob Nielsen (deutsche Übersetzung) - 04.11.2009
Letztes Jahr haben wir eine Studie durchgeführt, in der es um die optimale Vorgehensweise beim Integrieren von Usability-Methoden in agile Entwicklungsprojekte ging.
Normalerweise lohnt es sich nicht, das gleiche Problem bereits ein Jahr später erneut zu untersuchen, da sich das Nutzerverhalten nicht sehr verändert. Dieses spezielle Projekt bezog sich jedoch nicht auf das Nutzerverhalten, sondern eher auf die beste Art und Weise, agile Projekte durchzuführen, um Usability sicher zu stellen.
Da dies noch ein neues Gebiet ist, haben wir beschlossen, die Untersuchungen aus dem letzten Jahr mit einer neuen Runde von detaillierteren Studien zu ergänzen, die sich auf zusätzliche Organisationen konzentrieren, die mehr Zeit hatten, bessere Wege für die agile User Experience (UX)-Entwicklung zu finden.
User Experience: Die Rolle des Wächters
Die zwei Hauptempfehlungen für gute Usability in agilen Projekten bleiben die gleichen wie in unserer ersten Forschungsreihe:
- Trennen Sie Design und Entwicklung, und sorgen Sie dafür, dass das Nutzeroberflächen-Team dem Umsetzungsteam immer einen Schritt voraus ist. Dann ist immer alles schon entworfen und getestet, wenn es Zeit wird, etwas zu programmieren. (Ja, man kann beides in ein oder zwei Wochen schaffen, indem man Papierprototypen und Discount-Nutzerstudien verwendet.)
- Halten Sie an einer einheitlichen Vorstellung der Nutzeroberflächen-Architektur fest. Entwerfen Sie ganz am Anfang eine erste Vorstellung - bevor irgendetwas umgesetzt wurde - und behalten Sie sie in den jährlichen (oder halbjährlichen) Treffen der Design-Visionäre bei. Man kann nicht einfach einzelne Anwendungen für sich entwerfen; sie müssen sich zu einem einheitlichen Ganzen zusammenfügen - einem Ganzen, das ebenfalls gestaltet werden muss. Von unten nach oben gestaltetes Nutzeroberflächen-Design bedeutet letztendlich ein konfuses Nutzererlebnis (das Linux-Syndrom).
In beiden Forschungsrunden erwiesen sich diese beiden Grundsätze bei vielen der Firmen, die wir untersucht hatten, als nützlich. Eine Modifizierung ergab sich im zweiten Durchlauf, angeregt durch die PayPal-Fallstudie: Es ist wichtig, einen "Wächter" zu bestimmen, der die Erfordernisse im Blick behält und die Kommunikation zwischen dem UX-Team und den anderen Projektteams verfolgt, damit alle auf dem richtigen Weg bleiben (selbst wenn diese Wege parallel verlaufen).
Circle D Design wandte eine Variation hiervon an, indem sie eine "Ankerperson" für die UX-Kommunikation eines jeden Projekts bestimmten. Wenn für ein Projekt neue UX-Spezialisten gebraucht werden, werden sie der Ankerperson zugewiesen. Das Ankerprinzip fördert auch die langfristige Kommunikation unter den Teams, da die Ankerpersonen regelmässig gewechselt werden.
Zentralisierte UX-Abteilungen auf dem Rückzug
Die Debatte darum, wie Usability, Interaktionsdesign, technische Redaktion, und beliebige weitere, spezialisierte Disziplinen im Organisationsbild positioniert werden sollen, ist endlos. Es gibt zwei grundlegende Möglichkeiten:
- Zentralisierte Strukturen lassen ein einzelnes Team entstehen, das seine Disziplinen "besitzt" und sie den Entwicklungsteams für verschiedene Projekte innerhalb der Organisation zur Verfügung stellt. Eine zentrale Usability-Gruppe würde zum Beispiel alle Nutzertests und andere Nutzerforschungen durchführen; ein zentrales Designteam würde alle Interaktionsdesigns und visuelle Entwürfe bereitstellen; während ein zentrales UX-Team alle Entwürfe und Untersuchungen liefern würde. Einzelne Projektteams würden dann den Entwurf oder die Untersuchung des zentralen Teams nutzen und daraus ein reales Produkt machen.
- Verteilte Strukturen verzichten auf Zentralisierung und beauftragen stattdessen spezialisierte Mitarbeiter, direkt in einzelnen Projektteams mitzuarbeiten. Innerhalb dieser Struktur hat jedes Projektteam seinen eigenen Usability-Experten, Interaktionsdesigner, visuellen Designer, Informationsarchitekten, technischen Redakteur und so weiter für alle Disziplinen des Nutzererlebnisses. Genau genommen beinhalten grosse Projekte manchmal mehrere solcher Spezialisten in einem Team.
Ein offensichtlicher Nachteil einer verteilten Struktur ist, dass die Firmen eventuell nicht genug UX-Spezialisten haben, um jedem Team einen Spezialisten aus einem Bereich zuweisen zu können. Demnach würden einige Teams sich also Spezialisten teilen müssen, oder aber manche stünden ganz ohne da.
Die zentralisierte Struktur bietet ihren spezialisierten Mitarbeitern ein "Zuhause", da diese es oft schätzen, Kollegen ihres eigenen Bereichs nah bei sich zu haben. Das macht es auch einfacher, solche Fachkräfte zu leiten und zu fördern. Der Leiter einer zentralisierten Usability-Gruppe ist zum Beispiel für gewöhnlich ein Senior-Usability-Spezialist, während der Leiter einer zentralisierten Design-Gruppe ein Senior-Designer ist, und der Leiter der UX-Entwicklung wiederum ist ein noch ranghöherer Designer oder Usability-Experte. Solche Leiter verstehen die Aufgaben und Bedürfnisse ihrer Mitarbeiter. (Im Gegensatz hierzu wird ein Usability-Spezialist, der einem Entwicklungsleiter gegenüber Bericht erstattet, oft die Erfahrung machen, dass dieser Leiter keine Ahnung davon hat, ob eine Studie nun gut oder schlecht durchgeführt wurde.)
Eine zentralisierte Abteilung kann auch strategische Initiativen unterstützen, die sich mit einzelnen Entwicklungsprojekten überschneiden. Beispiele hierfür sind das Aufstellen und Überwachen von Standards und Richtlinien, der Aufbau eines Usability-Labors, das Sammeln von komparativen und Längsschnitt-Kennwerten des Nutzererlebnisses, und das Verbessern der Organisationsreife - zum Beispiel, indem strategische UX-Anliegen der oberen Führungsebene mitgeteilt werden und diese hoffentlich davon überzeugt werden kann, mehr in Usability zu investieren.
All dies ist schön und gut, wird aber problematisch, wenn es darum geht, Usability und ein gutes Nutzererlebnis mit agilen Entwicklungsteams zusammenzubringen. Alle Ergebnisse aus unseren Fallstudien deuten darauf hin, dass UX-Experten unbedingt mit Entwicklern und anderen Projekt-Teammitgliedern zusammengebracht werden müssen. Tatsächlich sollte die UX-Abteilung als Teil des Projektteams angesehen werden und eben nicht als eine externe Abteilung.
Das Aufteilen Ihrer UX-Mitarbeiter bedeutet nicht, dass sie jetzt alle Vorteile einer zentralen, spezialisierten Gruppe aufgeben müssen. Eine Matrix-Struktur bietet oft einen guten Kompromiss, da sie die UX-Profis tageweise den einzelnen Projekten zuordnet, aber dennoch eine gewisse unternehmensweite Koordination ermöglicht.
Agile UX ist gut, kann aber noch besser werden
Dieses Jahr haben wir die Studienteilnehmer gefragt, inwieweit der UX-Bereich in ihre Projekte integriert war und wie zufrieden sie waren, wenn sie mit einer bestimmten Entwicklungsmethodik an einem Projekt gearbeitet haben. Sie gaben ihre Antworten auf einer Skala von 1 bis 5, wobei 5 die höchste Stufe der Integration oder Zufriedenheit anzeigte:
Projektmethodik | Integration des Nutzererlebnisses | Zufriedenheit mit der Methode |
Wasserfall | 2.5 | 2.9 |
Agil | 3.1 | 3.7 |
Iterativ | 3.2 | 3.8 |
Ohne Frage sind agile Methoden bei weitem besser als die alten Wasserfall-Methoden. Gut, dass wir die los sind. Trotzdem fanden die Experten in unserer neuen Studie immer noch, dass iteratives Design geringfügig besser ist als agiles; es muss daran gearbeitet werden, agile Projekte noch nutzergesteuerter zu machen.
Die gute Nachricht ist, dass die neuesten Ergebnisse uns Belege dafür liefern, dass wir das Stadium des "Die da und wir hier" hinter uns lassen - insgesamt waren die Entwickler bei einigen grundlegenden UX-Meinungswerten optimistischer als die UX-Leute.
Die Entwickler stuften den Einfluss der UX auf die Qualität des Ergebnisses bei 4,3 ein, während die Nutzererlebnis-Experten es bei 4,0 einordneten (wieder auf einer Skala von 1-5, wobei 5 das Beste ist).Die Entwickler sagten, dass sich die Produktivität durch Einbeziehung des UX-Bereichs etwas erhöht habe (3,3), wohingegen die Nutzererlebnis-Spezialisten dies mit 3,4 nur geringfügig höher einschätzten.
Sowohl die Entwickler als auch die UX-Experten drückten den grossen Wunsch nach einer verstärkten Beteiligung des UX-Bereichs in dem Projekt aus. In den Firmen, die sich die Mühe machen, Usability und agile Methoden zusammenzuführen, sind die Dinge auch noch nicht perfekt, aber sie laufen schon ziemlich gut.
© Deutsche Version von Jakob Nielsens Alertbox. Institut für Software-Ergonomie und Usability AG. Alle Rechte vorbehalten.
Kommentare auf diesen Beitrag