Wild Card

Nicht verzagen, Nutzer fragen

Uhr | Aktualisiert
von Christof Zogg

Um die Benutzerfreundlichkeit von Software stand es lange Zeit nicht zum Besten. Die Funktion stand im Vordergrund, und die Benutzer hatten sich gefälligst anzupassen. Mittlerweile ist benutzerzentrierte Softwareentwicklung der Standard. Und es gibt bereits Anzeichen, dass gelegentlich übers Ziel hinausgeschossen wird.

Christof Zogg, Director Digital Business bei den SBB und Jurypräsident der Kategorie "Young & Wild". (Quelle: Microsoft)
Christof Zogg, Director Digital Business bei den SBB und Jurypräsident der Kategorie "Young & Wild". (Quelle: Microsoft)

Jahrzehntelang scheinen Softwareentwickler an alle Stake­holder-Gruppen gedacht zu haben ausser an eine: die Endnutzer. Davon zeugen heute noch vereinzelt ERP-nahe Lösungen im Grossfirmenumfeld. Da erwarten einen etwa beim Genehmigen von Rechnungen Softwarelösungen, die so ziemlich alle Usability-Verbrechen auf sich vereinigen – angefangen von der grafischen Gestaltung der Marke Augenkrebs über quälend langsame Lade- und Reaktionszeiten bis hin zu nicht selbsterklärenden, inkonsistenten Steuer­elementen. Solche kapitalen Usability-Unfälle sind aber zum Glück seltener geworden. Denn seit rund einem Jahrzehnt beginnt sich die Erkenntnis durchzusetzen, dass User-Feedback direkt in den Entwicklungsprozess einbezogen werden muss. Deshalb werden Software-Teams heute kräftig mit Interaction-Designern, Usability-Profis und Ergonomie-Experten aufgestockt, sodass einen mittlerweile das Gefühl beschleicht, dass nach zu wenig schon bald einmal zu viel Benutzerzentrierung vorherrschen könnte.

Probieren (lassen) geht über Studieren

In der Tat gibt es problematische Aspekte von dogmatischer Benutzerzentrierung und den praktizierten Erhebungsmethoden. Dabei unterscheiden wir zunächst einmal die beiden grundsätzlichen Methoden, nämlich Usability-Tests mit einer kleinen Stichprobe vor und den Methoden unmittelbar nach einem Software-Launch wie A/B-Testing oder Telemetrie, die jeweils die gesamte Nutzerschaft abdecken.

In ersterem Fall erhalten Probanden etwa klickbare Prototypen oder Papier-Mockups zu Gesicht. Damit müssen unter Beobachtung des Usability-Experten oder ausgerüstet mit einer Eye-Tracking-Brille bestimmte Aufgaben erledigt werden ("Suchen und kaufen Sie ein Flohhalsband und legen Sie es in den Warenkorb."). In zweiterem Fall werden die exemplarische E-Commerce-Applikation öffentlich released und alle Aspekte der Nutzung aufgezeichnet. Anschliessend kann mit zwei unterschiedlich gestalteten Warenkorb-Interfaces experimentiert und datenbasiert festgestellt werden, mit welcher Variante das Flohhalsband mit höherer Wahrscheinlichkeit gefunden und gekauft wird.

Was die User sagen und was sie verschweigen

Gerade einfache Usability-Tests werden dabei aber auch schon überstrapaziert ("Lasst uns nicht mehr weiterdiskutieren, sondern die User fragen!"). Denn zunächst einmal können die befragten Anwender zwar demonstrieren oder artikulieren, was nicht funktioniert. Sie können aber nur indirekte Hinweise geben, wie eine bessere Lösung aussähe. Kritisch ist der Einsatz von einfachen Tests auch bei der Überprüfung von wirklich neuartigen und innovativen UI-Konzepten. Veränderungen wie die Einführung des kontextabhängigen Menübandes (aka Ribbon), das nach 2007 die Menüleiste in Microsoft Office ablöste, stossen anfänglich bei den Usern auf Skepsis, etablieren sich aber rasch als Standard und sind später nicht mehr wegzudenken. Fazit: Usability Tests sind gut, aber kein Ersatz für UI-Erfahrung. Denn User sagen nicht, wie’s geht, sondern nur, wie’s nicht geht. Es besteht die Gefahr, dass neuartige Benutzererlebnisse auf dem Altar der Usability-Tests geopfert werden. Deshalb wird die objektiverte, telemetrische Vermessung des Benutzerverhaltens immer wichtiger werden.

Tags
Webcode
5006