- "Die Anwendung muss eine gute Usability haben!"
Wer hat als Requirements Engineer nicht schon so eine Anforderung gesehen? Aber wie damit umgehen? Zurück an den Stakeholder mit der Bemerkung "Das ist keine qualitativ gute Anforderung" kommt normalerweise nicht gut an - oft können Stakeholder ihre Usability-Anforderungen gar nicht richtig ausdrücken. Und obwohl schon viele Firmen die Themen Usability und User Experience richtig ernst nehmen, gib es mindestens genauso viele, die für diese Themen kein Konzept haben. Also was kann ein RE machen, um diese Anforderung so gut es geht zu erfüllen, obwohl keine Zeit und kein Geld für professionelles Usability Engineering inklusive Usability Testing vorhanden ist? Hier findet Ihr Tipps, wie man unter diesen Umständen eine ansprechende Usability erreichen kann.
Der HCD-Prozess als Grundlage für gute Usability
Um die einzelnen Schritte zu einer guten Usability zu verstehen, bietet sich als Orientierung der Prozess für Human-Centered-Design (Nutzungsorientierte Gestaltung) an. Der HCD-Prozess besteht grob gesagt neben der Planung aus den Schritten Analyse, Spezifikation, Design und Evaluation, die iterativ ausgeführt werden:
Ich werde euch zu den Schritten Tipps geben, wie man mit vertretbarem Aufwand doch schon zu sehr guten Ergebnissen kommen kann. Dabei werde ich die Schwerpunkte auf Design und Evaluation legen, da die ersten beiden Schritte sowieso zum Handwerkszeug eines REs gehören sollten.
Analyse des Nutzungskontextes
Hier ist es unglaublich wichtig, in den Nutzungskontext zu gehen. Also nicht darauf vertrauen, dass Manager, Fachspezialisten oder Nutzer euch erzählen, was sie brauchen und was nicht, sondern bitte den Nutzer an seinem Arbeitsplatz beobachten. Dazu bietet sich die Feldbeobachtung und Apprenticing an, was man ja schon im Kurs IREB CPRE Foundation Level lernt. Ich persönlich habe sehr gute Erfahrungen mit Kontextanalyse (Contextual Inquiry), also einer Mischung aus Beobachtung und Befragung, gemacht. Das lernt man z.B. im Advanced-Level-Kurs CPRE Elicitation & Consolidation. Für die Dokumentation eignen sich dann besonders Personas und Szenarien.
Spezifikation der Nutzungsanforderungen
Hierzu möchte ich nicht viel sagen – man sollte als erfahrener RE mit dem normalen Handwerkszeug schon sehr gut überleben können.
Design der Lösung
Beim Design der Lösung müsst ihr euch bewusst sein, dass jeder ein mentales Modell hat, wie etwas in seiner Umwelt funktionieren sollte – also auch die zu designende Anwendung. Es wird hauptsächlich durch Erfahrung, z.B. durch den Umgang mit anderen Anwendungen, geprägt. Also nichts designen, was den Erwartungen der Nutzer zuwiderlaufen würde. Aber wie könnt ihr das erreichen? Indem man sich beispielsweise an den Dialogprinzipien nach der ISO 9241-110 orientiert oder anerkannte Design Patterns nutzt.
Dialogprinzipien
Die Dialogprinzipien nach ISO 9241-110 sind:
- Aufgabenangemessenheit
- Selbstbeschreibungsfähigkeit
- Steuerbarkeit
- Erwartungskonformität
- Lernförderlichkeit
- Fehlertoleranz
- Individualisierbarkeit
Ich werde kurz für jedes Dialogprinzip erklären, wie ihr es beim Design eurer Anwendung einsetzen könnt.
Unter Aufgabenangemessenheit versteht man, dass mit der Anwendung alle Aufgaben, die der Benutzer erledigen muss, auch erfüllt werden können, und zwar möglichst einfach. Dazu sollte die Anwendung z.B. nur die Informationen anzeigen und abfragen, die nötig sind – nicht mehr und nicht weniger.
Eine Anwendung ist selbstbeschreibungsfähig, wenn dass der Nutzer weiss, wo er sich befindet, wo er herkommt und was er wie machen kann. Dadurch wird die Anwendung intuitiv bedienbar. Das könnt ihr z.B. erreichen durch:
Breadcrumbs
Ein hierarchisch aufgebautes Menü
Tooltips, die die Funktion von Elementen beschreiben
Feedback bei Aktionen, z.B. Statusrückmeldung bei langen Verarbeitungszeiten durch einen Fortschrittsbalken.
Steuerbarkeit bedeutet, dass der Nutzer die Abläufe selbst starten und die Richtung und eventuell auch die Geschwindigkeit beeinflussen kann. Dies kann man z.B. mit Vor-/Zurück-Buttons oder klickbaren Breadcrumbs erreichen. Ausserdem sollten bei langen Formularen oder Prozessen über mehrere Seiten Zwischenstände abspeicherbar sein, so dass man auf sie später wieder zurückgreifen kann.
Jeder Nutzer hat Erfahrungen aus seinem Fachgebiet sowie mit anderen Anwendungen oder Websites. Erwartungskonformität heisst, dass die Anwendung auf diese Erfahrungen Rücksicht nimmt. So führt ein Lupen-Symbol normalerweise auf eine Suchmaske oder wenn man das Firmenlogo links oben anklickt kommt man auf die Homepage. Weiterhin sollten die Fachbegriffe des Nutzers verwendet werden. Oder, bei einer öffentlichen Webseite, allgemeinverständliche Begriffe. Ausserdem sollten z.B. alle Seiten einer Webanwendung konsistent sein, also einen ähnlichen Aufbau haben und die gleichen Begriffe oder Symbole verwenden.
Für Webseiten, die ein Nutzer nur sehr selten braucht, kann Lernförderlichkeit durch ähnliche Massnahmen wie Erwartungskonformität erreicht werden. Bei Anwendungen, die vom Nutzer oft benutzt werden, finde ich es z.B. gut, wenn regelmässig Tipps eingeblendet werden, die der Nutzer dann wegklicken oder auch ganz abstellen kann.
Die Möglichkeit zu Fehleingaben sollte vermieden werden. So kann z.B. durch ein Kalender-Popup zur Datumsauswahl die fehlerhafte Eingabe des Datums vermieden werden. Auch ist Toleranz gefragt. Eine Uhrzeit-Eingabe „1415“ sollte toleriert werden und nicht ein Doppelpunkt zwischen Stunden und Minuten verlangt werden. Falls es dann doch zu einer Fehleingabe kommt, sollte die Fehlermeldung klar sein und es sollte markiert werden, wo der Fehler auf der Seite passiert ist.
Individualisierbarkeit spielt vor allem bei Anwendungen, die ein Nutzer oft braucht, eine Rolle. Beispiele sind die Möglichkeit, die Menübänder bei Office-Produkten an die eigenen Bedürfnisse anzupassen oder in einer Anwendung zwischen einem Einfach- und einem Expertenmodus umzuschalten.
Design Patterns
Design Patterns (Entwurfsmuster) sind Lösungen für wiederkehrende Gestaltungsprobleme, z.B. für gute Navigation oder wie Information verständlich dargestellt werden kann. Es gibt Sammlungen von Design Patterns im Internet, die ihr euch anschauen solltet, anstatt das Rad immer neu zu erfinden (z.B. https://www.welie.com).
Evaluation der Lösung
Nicht immer ist ein voller Usability-Test der Anwendung mit Endnutzern aus Zeit-, Budget- oder Verfügbarkeitsgründen möglich, was schade ist. Aber unabhängig davon solltet ihr unbedingt so früh wie möglich die Lösung evaluieren.
Prototypen und frühe Evaluation
Einen einfachen Prototypen entweder auf Papier oder mit einem einfachen Mockup-Tool (z.B. Balsamiq Mockups oder moqups) erstellen kostet nicht so viel Zeit, ist aber unheimlich hilfreich, um schon früh Feedback von Nutzern oder anderen Stakeholdern einzuholen. Fangt wirklich früh damit an und wiederholt das so oft wie möglich – Iterationen sind zentral im HCD-Prozess.
Hallway-Testing
Und wenn keine Nutzer verfügbar sind, um Feedback zu Prototypen zu geben. Dann könnt ihr euch zumindest behelfen, indem ihr irgendjemanden, der gerade durch den Gang läuft und am besten nichts mit eurem Projekt zu tun hat, bittet, an einer Usability-Evaluation teilzunehmen, also z.B. bei einem Walkthrough durch euren Prototypen. Nicht ideal – aber besser als nichts.
Wie weiter?
Die oben genannten Methoden sind einfache Ansätze, um bei wenig Mitteln die Usability einer Anwendung zu verbessern. Aber um wirklich gute Usability zu erreichen, muss man mehr tun. Also ist es zuerst wichtig, Bewusstsein zu schaffen, dass einen gute Usability nicht vom Himmel fällt, sondern Zeit, Geld und erfahrene Mitarbeiter braucht. Aber das ist ja gerade das Schwierige in Organisation, die noch nicht reif genug sind.
Literatur
Das Buch Usability Engineering kompakt von Richter/Flückiger gibt einen guten Einblick in das Handwerkszeug für Usability Engineering inklusive Beispiele aus der Praxis. Das Buch User Experience Design von Moser, das viele Aspekte von User Experience und Usability auf jeweils zwei bis drei Seiten kurz darstellt, gibt eine weitere Einführung in das Thema.