Was ist Usability?

Normalerweise versteht man unter Usability die einfache Benutzbarkeit von Software. Tatsächlich aber hat Usability eine genormte Definition nach DIN EN ISO 9241-11 und ist nach meinem Stand der Grad, zu dem ein Werkzeug in einem bestimmten Kontext bei bestimmten Nutzern eine bestimmte Aufgabe effektiv, effizient und zufriedenstellend erledigt. Da steckt ein bisschen mehr drin als bei der ersten Definition, die die meisten von uns im Kopf haben dürften.

Usability nach Norm

Erstens geht es dann nicht mehr nur um Software, sondern um jedes Werkzeug oder Produkt. Zweitens geht es nicht mehr um generelle Einfachheit, sondern um die Eignung in definierten Anwendungsfällen. Und drittens gibt es nach dieser Definition mit effektiv, effizient und zufriedenstellend Gradmesser der Usability, wobei damit konkret gemeint ist:

1. Effektiv kann das Werkzeug die Aufgabe überhaupt erledigen (viele Dinge hämmern)
2. Dabei ist es mehr oder weniger effizient (der Hammer hämmert besser als das Telefon)
3. Nach dem ganzen ist der Nutzer mehr oder weniger zufrieden, vielleicht sogar sehr, wenn der Hammer super effektiv und effizient war, minimalen Kraftaufwand braucht und gleichzeitig dem Handwerker Komplimente macht.

Bewaffnet mit dieser Definition gibt es gerade in Deutschland eine (kleine?) Industrie, die Fortbildungen anbietet und (normalerweise) Software auf diese Kriterien abklopft. Mein vorheriger Job war genau in dem Bereich – führte mich also vom breiteren Studium der Mensch-Computer-Interaktion (HCI) zurück zu sehr viel konkreterer angewandter Usability, genau was mich an HCI genug fasziniert hatte um es als Master zu wählen.

Hilfreicher: Grundlagen der Dialoggestaltung

Aber von wegen angewandt: Natürlich ist die Definition trotz allem reindefinierten viel zu abstrakt, um damit viel konkretes anzufangen. Um Software zu bewerten geht man daher einen Schritt weiter und schaut sich die Grundlagen der Dialoggestaltung (ISO 9241-110) an:

Aufgabenangemessenheit

Kann die Aufgabe angemessen erledigt werden? Ja, man kann mit Paint eine Doktorarbeit schreiben, aber der Aufwand ist unnötig hoch.

Selbstbeschreibungsfähigkeit

Ist der Zweck jedes Interfaceelements direkt ersichtlich? Typisches Problem hier sind Icons, deren Bedeutung unklar bleibt oder Buttons, die nicht wie Buttons aussehen (Flat-Design!).

Steuerbarkeit

Kann man (z.B. in einem Wizard) wieder zurückgehen?

Erwartungskonformität

Ist alles konsistent mit der Nutzungserwartung? Darüber schrieb ich hier im Blog schonmal bezüglich des prägenden Einflusses des ersten Kontakts mit einem Systems.

Fehlertoleranz

Verzeiht das System Falscheingaben des Nutzers und bewahrt ihn vor solchen?

Individualisierbarkeit

Beispiel Schriftgröße – kann das System an die Bedürfnisse des Nutzers angepasst werden? Hier geht es dann ganz schnell auch um Accessibility

Lernförderlichkeit

Kann der Nutzer die Software erlernen und hilft sie dabei? Markierungen für Tastenkürzel in Menüs gehen z.B. in die Richtung.

Das sind schon besser greifbare Kriterien, mit denen man Software auf der Effizienzebene bewerten kann und dann rausbekommt, welche Probleme sie hat.

Diese Grundlagen wurden übrigens vor kurzem überarbeitet. Unter anderem wurde laut Wiki Benutzerbindung – System ist einladend und motivierend hinzugefügt. Das ist Unsinn, weil es dem Prinzip hinter ihnen zuwider läuft, klar definierbare Eigenschaften von Dialogen auf der Effizienzebene abzudecken und stattdessen der schwer greifbaren Zufriedenstellung oder User-Experience entspricht (zur Abgrenzung von UX und Usability will ich später noch etwas schreiben). Du könntest also an anderen Stellen eine andere Definition finden, solltest die aber ignorieren. Die oben gezeigte ist die richtige.

Testbarkeit, Einstellungssache und Anwendbarkeitsprobleme

Mir ist wichtig etwas zu betonen, was bei den ganzen Definitionen vielleicht nicht direkt klar wird: Usability ist die Antithese zu RTFM. Dieses elitäre Gehabe, das zumindest vor Ubuntu im Linuxumfeld zu finden war und immer noch in einigen Bereichen zu finden sein wird, hat als Kern den Anspruch, dass bei Problemen der Nutzer schuld ist und er sich anpassen muss. Usability gibt dagegen ein Werkzeugset, mit dem man schauen kann wie Software so gebaut wird, dass zumindest die Zielnutzergruppe ihre Aufgabe gut erledigen kann. Was Anleitunglesen nur dann einschließt, wenn es die übliche Praxis der Zielgruppe ist.

Üblicherweise macht man diese Prüfung mit Nutzungstests. Da spielt das ganze "definierter Nutzer, Kontext und Aufgabe" der Usabilitydefinition mit rein. Natürlich kann auch ich mich vor eine Software setzen und gucken, welche Probleme mir auffallen – das ist sogar ein valides erstes Testmittel, mit einer Expertenevaluation finden sich viele typische Probleme. Aber dem Atomkraftwerksingenieur, der normalerweise vor der Software sitzt, dem werden noch ganz andere Dinge auffallen und wichtig sein. Wenn ich also ihn bei seiner Aufgabenerledigung beobachten kann wird viel wahrscheinlicher, dass die wichtigen Probleme auftreten und analysiert werden können.
Hier im Blog hatten wir das auch schonmal in einem schönen Beispiel bei der kleinen Kontroverse um Gimps Umbau des Speicherdialogs, denn dort war der springende Punkt, dass es eben darauf ankommt was die eigentlichen Nutzer während der echten Arbeit davon halten – wobei bei Gimp das eben sehr viele Nutzer mit unterschiedlichen Anforderungen sein können.

Man sieht da ein Problem: Usability nach Normdefinition eignet sich besser für kleinere Nutzergruppen, vor allem für Angestellte in Unternehmen. Wenn ich weiß, dass alle meine Techniker eine bestimmte alte Software beherrschten und grundsätzlich diese X Dinge über das verkaufte Produkt wissen, dann kann ich die Nachfolgesoftware gut mit denen testen. Wenn ich alle Menschen auf der Erde ansprechen will, geht all der definierte Kontext aus der Definition den Bach runter. Als Usability-Experte kann ich dann immer noch mit Tests arbeiten, Konsistenz herstellen und mir Zielnutzergruppen raussuchen, für die meine Software besonders gut funktionieren wird – aber da kommt man immer an die Grenze des machbaren, an der dann schon der kulturelle Unterschied zu groß ist um ihnen allen eine gute Usability zu bieten.
An ähnliche Probleme kommt man, wenn die Software eine schwierig zu definierende Aufgabe hat. Versuch mal, Facebook auf eine einzelne Aufgabenerledigung runterzubrechen.

Manchmal geht das dann schief und Software wird im Auftrag der Designer kaputtsimplifiziert. Etwas einfach zu halten kann helfen möglichst viele mögliche Nutzer nicht vor Probleme zu stellen, kann aber eben auch die Aufgabenerledigung für die anderen (im Zweifel: Die echten und bestehenden Nutzer) behindern. Windows 8 kann man so einordnen. Generell im Zweifel alles, wo Oberflächen für beschränkte Medienkonsumierungsgeräte wie Smartphones und Tablets auf PCs übertragen werden. Aber auch die misslungene Umstellung des Fedora-Installers von einem simplen linearen Wizard auf eine komplizierte Menüstruktur im Namen der vermeintlich zugänglichen modernen GUI schlägt in diese Kerbe

Mehr als eine Norm: Usability für alles

Gut, dass es wirklich nicht nur um Software geht und Usability mehr ist als nur unsympathisch hinter Zahlschranken versteckte DIN-Normen. Das Buch The Design of Everyday Things von Don Norman zeigt das besonders stark. Norman sammelt darin sehr viele Beispiele von Alltagsgegenständen, deren Usability schlecht ist. Tolles Beispiel sind Türen: Schonmal vor einer gestanden und nicht gewusst, ob man ziehen oder drücken muss? Auch das wird zu einer grundsätzlichen Einstellungsfrage: Die meisten Menschen fühlen sich blöd, wenn sie falsch lagen. Dabei ist es doch nicht ihr Fehler, wenn die Tür so gestaltet ist, dass ihre Bedienung unklar ist! Mit den Dialogprinzipien von oben würde man sagen: Die Selbstbeschreibungsfähigkeit war ungenügend.
Ich habe das Buch vor kurzem verliehen und als Fazit zurückbekommen, dass es anfangs sehr gut und überzeugend ist, aber nach eine Weile sich zu wiederholt. Das stimmt wohl, aber es hat auch viele gute Beispiele und bringt bis dahin Usability als Denkansatz gut rüber. Es geht über die Normen hinaus und gibt weitere Erklärungen, was gute Usability ausmacht und Beobachtungen, wie Nutzer Probleme angehen: Hilfreiche Dinge wie mentale Modelle und Seven stages of action.

Usability ist ein relativ weites Feld und HCI ist noch viel weiter. Aber gerade Usability ist faszinierend, weil es so wunderbar anwendbar und hilfreich ist. Und ich empfand immer eine große Anziehungskraft des Begriffs: Als jemand, der damals Software zu schreiben lernte wollte ich doch natürlich auch wissen, wie diese Software für gute Benutzbarkeit gestaltet zu sein hat. Auch heute ist das mein Anspruch.

Doch hier im Blog habe ich nur selten darüber geschrieben, selbst die fast allumfassende HCI-Kategorie ist relativ ungefüllt. Ich habe mir daher vorgenommen, noch etwas mehr über Usability zu schreiben. Vor allem, wie man dieses Konstrukt konkret nutzen kann um benutzbare Software zu gestalten.