User Centered bitte!
Als ich mich vor einiger Zeit mit dem Thema agile Softwareentwicklung beschäftigt habe, fiel mir auf, wie oft versucht wird, die Konzepte des “Agilen” und des “User Centered Designs” zusammenzubringen.
Ich war etwas verwundert, denn für mich stellen beide Ansätze keine Gegensätze dar. Gerade nämlich, wenn es um komplexe Software geht, kommt der Nutzer gerne etwas zu kurz, wahrscheinlich, weil die Nutzungsszenarien nicht ausreichend analysiert werden. User Centered als die Theorie, die in der Praxis anders aussieht?
Nähme man das Beste aus beidem, so müsste man eigentlich zu einer gelungenen Mischung kommen, die zum einen den Erstellungsprozess an den Anwendern und Entscheidern festmacht als auch zu einem benutzerfreundlichen Produkt führt. Inzwischen bin ich etwas eines Besseren belehrt worden.
Der User - die unbekannte Spezies
Wer Websites macht, kennt die User Thematik unter dem Stichwort Zielgruppe und etwas mehr im Detail unter dem Stichwort Persona. Wer eine Intranetseite oder eine spezialisierte Software für eine bekannte Gruppe von Personen entwickelt, ist in gewisser Weise von Vorteil, denn hier werden aus Konzepten ganz reale Menschen, die in den Entwicklungsprozess mit einbezogen werden können. Grundsätzlich ähnliche Aspekte mit dem Unterschied, dass für die Usability Tests einmal Testpersonen rekrutiert werden müssen, im anderen Fall (unter anderem) die späteren Nutzer diesen “Job” übernehmen können.
An dieser Stelle - die Variante Intranet… - wird es spannend mit dem User Centered, denn es gibt meistens eine in der Praxis ziemlich klare Trennung zwishen Entscheider und Nutzer. Die Schnittmenge jener Gruppen ist ziemlich gering. Der Entscheider kennt zwar die funktionalen Anforderungen, nicht aber den ganz normalen Arbeitsablauf. Dass vielleicht das ein oder andere mit einer neuen Lösung schneller erledigt werden könnte, sehen alle Beteiligten. Dass es aber nicht unbedingt an den überlangen Kaffeepausen sondern an jahrelang erarbeiteten, gehassliebten Workarounds liegt, das ist vielleicht nicht bekannt. Und vielleicht sehen das nicht mal mehr die Anwender selbst?
This may lead to a product that has lots of features that the users do not really have use for, and that lacks features that the users would actually need, which may force the users to change their ways of doing things in order to be able to use the software
habe ich in einem interessanten Paper von gelesen.
Das Stichwort “User Centered Design” auch praktisch und nicht nur theoretisch zum Thema zu machen, scheitert gerne schon mal .Vielleicht scheitert es an der Bereitschaft manch eines Entscheiders, sich über die Anwender eingehend Gedanken zu machen, am Kompetenzgerangel und an der mangelnden Bereitschaft oder fehlenden Organisation, auch den “ganz normalen Anwender” in Entscheidungsprozesse zu integrieren?
benutzerzentriert, iterativer, agiler
Genau hier sollte dann die Überlegung ansetzen, sich eben nicht so strikt an theorielastigen Prozessen zu orientieren. Und genau hier passen agil, interaktiv und benutzerzentriert dann auch gut zusammen.
Ich hatte es schon geschrieben und ich bin überzeugt davon, dass insbesondere eine “agile Note” ein Benefit für das ein oder andere Projekt sein kann. Insbesondere gilt dies für den iterativen Aspekt. Um es kurz zu machen, halte ich es deshalb für so wertvoll, weil es den Entscheidern und Anwendern leichter fällt, sich um kleine Teilaspekte zu kümmern, als immer das Große ganze zu sehen und dies auch noch auf einen Schlag (Planungsphase) überreißen zu müssen.
So sieht es in der Realität ja dann auch oft aus… Die Komplexität eines Problems wird weder ausreichend kommuniziert noch ausreichend analysiert. Gerade die Nutzer selbst könnten an dieser Stelle wesentlich dazu beitragen.
Sehr gut gefallen hat mir in diesem Zusammenhang eine kleine , die folgende Punkte besonders herausstellt:
- Umfassendes und kontinuierliches Feedback der Benutzer
- Iteration, Iteration, Iteration
- Verständnis für die Zielgruppe, die Nutzergruppe
- User Interface Prototyping
Es gibt ein paar Probleme, die “reine” agile Software Entwicklung (prototypisch XP) und die reine Lehre des User Centered Designs zusammenzubringen, neben oben genannter Schere zwischen Funktionalität-Haben und Funktionalität-Brauchen, dann auch noch:
In XP user stories are used to capture requirements. However, as such user stories do not fit into expressing usability requirements. Thereby, usability requirements are typically dismissed in XP projects.
schreibt beispielsweise und weiter
In general, XP does not pay attention to the usability issues and it may be that in its original form it works best in applications that are not heavily GUI intensive (Armitage, 2004).
Das spricht ganz klar gegen einen agilen Ansatz beispielsweise im Webdesign - und ich muss zugeben, genau das hatte ich nicht beachtet. Reduziert man aber nun das “Agile” ein wenig oder modifiziert ihn, indem man klar einen Fokus auf User Interface Prototyping setzt, wie es die IBM vorschlägt, dann kann genau dieser Punkt überwunden werden.
Mehr Durchblick zu jeder Zeit
Ich erwarte mir von einer agilen, user-zentrierten Methodik mit extrem iterativer Vorgehensweise ganz klar einen Mehrwert, der allerdings nur dann erreicht werden kann, wenn dem User Interface Prototyping entsprechend hohe Priorität eingeräumt wird.
Dies ist wichtig, um den Benutzern die nötige “Fassbarkeit” bieten zu können - den “Ah, so funktioniert das also…” Effekt, der auf bessere Testszenarien und gezieltere Fragestellungen hinsichtlich der “Aufgabenangemessenheit” hin abzielt, - idealerweise mit einem Feedback, das auch auf unvollständige Arbeitsabläufe hinweist, falls vorhanden.
Agil übrigens oder nennen wir es abgeflachter und falsch nur “iterativ” - und das muss vor allem dem Entscheider klar sein, ist nicht zu verwechseln mit “ach das passt dann schon so”. Und auch iterativ sollte nicht automatisch dazu führen, dass in jeder Runde umfangreiche Änderungen die Regel werden und damit schnell mal den Test ersetzen.
