Nutzereinbezug ist im Usability Engineering im Sinne der nutzerzentrierten Entwicklung zwingend erforderlich. Nur so können wir verstehen, was für Anforderungen Nutzer tatsächlich haben und an welchen Stellen bei der Interaktion mit Produkten Probleme auftreten. Dieser Grundsastz ist in der DIN EN ISO 9241 fest verankert. Usability Tests sind daher eine notwendige Methode im Softwareentwicklungsprozess, um reale Usability Probleme einer Anwendung aufdecken zu können. Wer jedoch bereits einen Usability Test durchgeführt hat, der weiß, dass dieser eine gewisse Zeit für Vorbereitung, Durchführung und Auswertung einnimmt. Grundsätzlich ist das kein – schwieriger wird es aber im Rahmen der agilen Softwareentwicklung.
Agile Softwareentwicklungsprojekte sind in kurze Entwicklungsperioden unterteilt, innerhalb derer User Stories konzipiert, implementiert und auch getestet werden sollen. Das heißt, man benötigt in vielen Fällen bereits nach zwei Wochen ein Produkt, das releasefähig ist. Das stellt das Usability Engineering vor eine große Herausforderung, denn es bedeutet, dass auch innerhalb dieser zwei Wochen Anforderungen erhoben, Prototypen umgesetzt und diese getestet werden müssen – wenn wir Usability Engineering richtig betreiben wollen. Als Konsequenz heißt das, dass die Methoden möglichst schnell durchführbar sein müssen, die Ergebnisse dabei aber nicht an Qualität verlieren dürfen.
Optimierungspotential gibt es zum Beispiels beim Usability Testing. Usability Tests sollen eigentlich mit 3-5 Nutzern – pro Nutzergruppe wohlgemerkt! – durchgeführt werden. Bei einer komplexen Anwendung, bei der z. B. 7 Nutzergruppen identifiziert wurden, würde das bedeuten, dass wir in zwei Wochen 35 Nutzertests durchführen müssten. Ein Ding der Unmöglichkeit, da auch die anderen Tätigkeiten im Prozess nicht zu vernachlässigen sind.
Wir haben hier positive Erfahrung mit der RITE-Methode ("Rapid Iterative Testing and Evaluation") gemacht. Bei dieser Methode wird eine Anwendung solange mit Nutzern getestet, bis eine gewisse Anzahl wichtiger Usability-Probleme identifiziert werden konnten. Das kann z. T. schon nach zwei Nutzern der Fall sein. Die Probleme werden herausgearbeitet und darauf aufbauend direkt Verbesserungsvorschläge erarbeitet und in der Anwendung realisiert. Mit der verbesserten Version werden dann die nächsten Tests durchgeführt. Dies hat den wesentlichen Vorteil, dass weniger Zeitaufwand in der Durchführung notwendig ist und schneller auf identifizierte Aspekte reagiert werden kann. Die Anwendung unterliegt somit einem stetigen Verbesserungsprozess. Im Hinblick auf die Optimierung des Usability Testings ist das jedoch noch nicht alles.
Zeitersparnis kann auch bei der Auswertung erreicht werden. Bei klassischen Wasserfall-Projekten wird meistens viel dokumentiert. Es entstehen längere Testberichte, die an den Kunden geschickt werden. Deren Erstellung nimmt viel Zeit in Anspruch, die wir in der Regel jedoch nicht zur Verfügung haben. Außerdem ist das Ganze meist mit einer Ergebnispräsentation verbunden, da gerade das Management nicht viel Zeit mit dem Lesen solcher Berichte verbringen will. Wir gehen daher mittlerweile so vor, dass wir die Kunden zu den Usability Tests einladen. Diese können in einem separaten Raum entweder hinter einer Spiegelscheibe oder per Videoübertragung den Usability Test beobachten. Im besten Fall sind dabei sowohl Entwickler anwesend, als auch Vertreter aus dem Management. Während ein Usability Engineer im Testraum den Versuch mit dem Probanden durchführt, kann ein zweiter Usability Engineer im Nebenraum die Situation moderieren. Bewährt hat es sich, dass alle Screens, mit denen der Nutzer während des Tests in Kontakt kommt, auf Stellwänden aufgehängt werden. Mittels Post-Its können die Personen im Nebenraum dann alle Usability Probleme festhalten und an die Screens schreiben.
Dieses Vorgehen hat insofern Vorteile, dass die Personen, die mit der Entwicklung der Anwendung betraut sind, direkt erfahren können, an welchen Stellen Probleme auftreten. Dies schafft zum einen eine höhere Akzeptanz für das Usability Engineering, zum anderen müssen die Probleme anschließend nicht mehr ausführlich beschrieben und vorgestellt werden, da sich die Beteiligten selbst an diese erinnern können. Die Ergebnisberichte können daher schlanker gestaltet werden.
Es gibt bei diesem Vorgehen jedoch einige Probleme: Die teilnehmenden Personen wissen nicht immer, was tatsächlich Usability Probleme sind. Sagt ein Nutzer etwa im Think Aloud, er habe etwas nicht schnell gefunden, wird dies oftmals direkt als Usability-Problem aufgeschrieben. Objektiv beurteilt hat der Nutzer jedoch vielleicht nur drei Sekunden gebraucht, um das Element zu finden, was einer angemessenen Zeit entspricht. Hier liegt also nicht zwingend ein Usability-Problem vor. Auch bei der Bewertung des Schweregrads und der dadurch erfolgenden Priorisierung gehen die Meinungen zum Teil auseinander.
Es ist daher sehr wichtig, im Vorfeld Trainings mit den Entwicklern und anderen Projektbeteiligten durchzuführen, die lehren, auf was sie achten sollten. Das ist insbesondere dann sinnvoll, wenn man über einen längeren Zeitraum in einem Projekt mit den gleichen Personen zusammen arbeitet. So kann sich über die Zeit ein eingespieltes Team ergeben. Dass unser Vorgehen zur Auswertung auch anderweitig ähnlich gelebt wird, hat sich auch durch einen Vortrag auf der Usability Professional Konferenz von usability.de gezeigt, die ihre Vorgehensweise beschrieben haben. Wir können daher nur empfehlen, es auszuprobieren, wenn ihr in agilen Projekten unterwegs seid.