SNEK4: Usability-Problems (Claudia Oster)

Diesen Artikel habe ich schon vor einem halben Jahr geschrieben, dann aber leider vergessen zu bloggen. Das will ich hiermit nachholen. Dass ich solche Berichte stets in der Gegenwart schreibe, hat mit der Situation vor Ort zu tun und soll nicht bedeuten, dass die Konferenz gerade stattfände. Werfen wir also unseren Fluxkompensator an und machen eine kleine Zeitreise …

„Usability“ ist ein schönes Schlagwort, aber was verbirgt sich dahinter? In kurzen Worten ist das die Frage, was notwendig ist, um eine gute Benutzeroberfläche zu designen. Claudia Oster gibt zunächst einen Überblick über mögliche Testformen. Dazu gehören Expertentests ebenso wie Endbenutzertests. Natürlich testen beide Gruppen nicht das selbe, jeder hat seine spezifische Sichtweise.

Der Experte testet anhand von Checklisten und Styleguides, ob die grundsätzlichen Anforderungen an die Oberfläche umgesetzt wurden. Dazu gehören auch so Selbstverständlichkeiten wie Elemente und Verfahrensweisen nicht neu zu erfinden, die ein Benutzer bereits aus anderen ähnlichen Systemen kennt. Das betrifft die Größe der Schrift oder von Buttons auf Mobilgeräten ebenso wie die Bedientechnik „Zurück“. So kann das erreicht werden, was man gemeinhin „intuitive Bedienung“ nennt. Es gibt bereits einige Checklisten im Web, aus denen man sich bei Bedarf eigene erstellen kann. In diesem Zusammenhang ist vielleicht auch Googles automatischer Check bezüglich der Verwendbarkeit von Websites für mobile Geräte interessant.

Sinnvolle Default-Werte, richtige TAB-Reihenfolge, Bedienbarkeit ohne Maus, das alles sind allgemeine Regeln, die wohl jeder Entwickler schon einmal gehört hat. Das Proble besteht vielleicht darin, sich im Laufe der Entwicklung stets daran zu halten. Daher ist ein Test wichtig, der diese Details systematisch überprüft.

Bei dem Cognitive Walkthrough tut ein Tester so, als ob er der Benutzer wäre und analysiert einige konkrete vorgegebene Handlungsabläufe. Der „Weg des geringsten Widerstands“ ist dabei ein guter Ratgeber für die Frage, was ein Anwender in einer bestimmten Situation tun würde. Naheliegenderweise ist gerade dieses Verfahren besonders schwierig, wenn es um die eigene Applikation geht. Denn gerade hierbei ist das Vorwissen darüber hinderlich, um alle Fehler zu finden.

Bei der Heuristischen Evaluierung (nach Rolf Molich und Jakob Nielsen) werden die Ziele des Tests nur allgemein formuliert, wobei das Wording nicht auf die Applikation angepasst ist. Die Testpersonen suchen sich daraufhin selbst einen „Weg“ durch die Applikation und berichten darüber, was sie erfahren haben und wie einfach oder schwierig es war. Heuristiken sind dabei eher allgemeine Regeln oder Prinzipien, keine streng vorgegebenen Abläufe.

Es folgen einige lustige Beispiele aus der realen Welt wie die Message-Box „Wollen Sie wirklich abbrechen?“, die mit den Buttons OK und ABBRECHEN daherkommt. Das Szenario, das Abbrechen abzubrechen, ist nicht so ganz einfach in den Kopf zu bekommen. Auch die Erwartungshaltung, dass dieselben Begriffe auch immer dieselben Funktionen beschreiben, erscheint trivial, wird jedoch leider nicht immer durchgehalten. Empfehlungen, wie ein Benutzer eine problematische Situation zum Guten wenden kann, sollten ebenfalls in Fehlermeldungen vorkommen. Fehlerhafte Eingaben sollten sofort erfolgen und vor allem direkt neben dem Feld, in dem die falsche Eingabe gerade getätigt wurde. Dadurch erhält der Anwender ein sofortiges direktes Feedback, was auch in der Erziehung empfohlen ist.

Das Hallway Testing ist dabei eher eine „Guerilla-Methode“: Nimm den erstbesten Anwender und setze ihn vor das Programm. Mach das mit 5 Personen und du findest 95 % deiner Probleme. Sinnvoll ist, dass die Personen aus der gleichen Personengruppe stammen sollten. Einzige Regel für den Testbeobachter dabei: „Bleib ruhig“. Eine Videoaufzeichnung kann sehr hilfreich sein. Denn es geht darum, Probleme zu finden, nicht, sie direkt vor Ort zu lösen. Und schon gar nicht geht es darum, dem Benutzer eine Schulung zu geben!

Im Gegensatz zu Insidern haben Endbenuzter, die einzigen Probanden bei Endbenutzertests, einen anderen Zugang zu dem Problemkreis und damit zu dem Programm. Die Testperson soll alle Beobachtungen und Gedanken „laut denken“ (think aloud). Eine Aufzeichnung (Video und Audio) kann zusätzlich sehr hilfreich sein, wenn sie sowohl den Benutzer, als auch die Bildschirmsituation beinhaltet. Dann sind nachträgliche Analysen einfacher. Solche Tests können auch mit Skizzen der GUI gemacht werden (z.B. Balsamiq Mockups). So lassen sich bereits in dieser frühen Phase ablauftechnische Fehler erkennen, die dann gar nicht ausprogrammiert werden.


SmallInvoice Logo

Ähnliche Artikel:

AuthorChristoph Jüngling

Selbständiger Softwareentwickler und Seminarleiter

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

10 + 11 =