Usability Testing - Theorien, Modelle und Methoden - Institut für ...

Westfälische Wilhelms-Universität Münster
Ausarbeitung
Usability Testing - Theorien, Modelle
und Methoden der Softwareevaluation
im Rahmen des Seminars Software Management
Themensteller: Prof. Dr. Herbert Kuchen
Betreuerin: Susanne Gruttmann
Institut für Wirtschaftsinformatik
Praktische Informatik in der Wirtschaft
Andreas Simon

Inhaltsverzeichnis
1 Motivation und Überblick ............................................................................................ 3
2 Theorien und Modelle der Softwareevaluation ............................................................ 5
2.1 Ein Usability-Referenz-Modell ............................................................................. 5
2.2 Die Theorie des explorativen Lernens .................................................................. 8
3 Methoden der Softwareevaluation ............................................................................. 10
3.1 Analytische Evaluationsmethoden ...................................................................... 10
3.2 Vorbereitung eines empirischen Usability-Tests ................................................ 13
3.3 Befragungen ........................................................................................................ 14
3.4 Ausführungsmetriken .......................................................................................... 18
3.5 Verhaltensmetriken und physiologogische Metriken ......................................... 20
4 Fazit ............................................................................................................................ 25
Literaturverzeichnis ........................................................................................................ 26
II

Kapitel 1: Motivation und Überblick
1 Motivation und Überblick
Usability hat sich in den vergangenen Jahren zu einem zentralen Schlagwort bei der
Gestaltung von Anwendungen entwickelt. Häufig bieten die bestehenden Systeme
nämlich bereits die zur Aufgabenerfüllung notwendigen Funktionalitäten, sie können
jedoch nicht von den Anwendern genutzt werden, da die Funktionalitäten kompliziert
zu bedienen oder aufzufinden sind. Aus solchen Problemen können wirtschaftliche
Nachteile entstehen. Beispielsweise kann eine komplizierte Bedienung die für die
Bearbeitung einer Aufgabe notwendige Zeit sehr lang machen [TA08]. Durch eine
Usability-Verbesserung ließe sich also die Bearbeitungszeit verkürzen, was sich in
Form von Kostensenkungen für das betroffene Unternehmen auszahlt.
Usability kann sogar erfolgsentscheidend für eine Website sein. Wenn eine Seite gut
benutzbar ist, so kann sie neue Kunden überzeugen und bestehende Kunden an sich
binden. In einem stark umkämpften Markt, in denen die von den Seiten angebotenen
Dienste in zunehmenden Maße austauschbar sind, kann so die Usability zu einem
wettbewerbsentscheidenden Faktor werden. Die Einfachheit der Suche war z. B. ein
entscheidender Faktor für den Erfolg von Google.
Usability wird im Deutschen zumeist mit Gebrauchstauglichkeit wiedergegeben. Nach
der Internationalen Organisation für Standardisierung (ISO) ist Usability „das Ausmaß,
in dem ein Produkt von bestimmten Nutzern verwendet werden kann, um bestimmte
Ziele mit Effektivität, Effizienz und Zufriedenheit in einem bestimmten
Nutzungskontext zu erreichen“ [TA08, S. 4]. Nach Nielsen lässt sich Usability durch die
folgenden fünf wesentlichen Attribute beschreiben [Ni93]:
• Ease of learning: Der Nutzer soll sich schnell im System zurechtfinden, um
möglichst ohne Einarbeitung mit der Erledigung seiner Aufgaben beginnen zu
können.
• Efficiency of Use: Ein Nutzer, der das System kennt, soll es mit hohem
Produktivitätsgrad bedienen können.
• Memorability: Hat ein Nutzer das System schon einmal verwendet, so sollte er
sich nach einer Phase, in der er das System nicht genutzt hat, schnell wieder zurechtfinden.
3

Kapitel 1: Motivation und Überblick
• Errors: Das System sollte so gestaltet sein, dass der Nutzer möglichst wenig
Fehler begeht. Beim Auftreten eines Bedienungsfehlers müssen adäquate
Bewältigungsroutinen vorhanden sein. Schwere Fehler sollten nicht auftreten.
• Satisfaction: Das System sollte angenehm zu nutzen sein, so dass der Nutzer die
Verwendung des Systems als subjektiv angenehm empfindet und gerne mit dem
System arbeitet.
Gemeinsam ist beiden Definitionen die Interaktion zwischen Nutzer und System bzw.
Produkt. Bei dem Produkt / System handelt es sich im Rahmen dieser Arbeit
grundsätzlich um Software, wobei unter Software die Programme eines EDV-Systems
verstanden werden. Beispiele sind unternehmensspezifische Anwendungen oder auch
dynamische Webanwendungen wie Online-Shops.
Zunächst soll in Kapitel 2 auf theoretische Grundlagen eingegangen werden, um ein
Hintergrundwissen über das Thema Usability und die kognitiven Prozesse des Nutzers
bei der Bedienung von Software aufzubauen.
Um die Usability eines Produktes zielgerichtet verbessern zu können, sind die
Problembereiche der Software zu identifizieren. Zu diesem Zweck wird in Kapitel 3
eine Vielzahl von Evaluationsmethoden dargestellt. An dieser Stelle sei darauf
hingewiesen, dass ein Usability-Test in verschiedenen Entwicklungsstadien einer
Software angewendet werden kann. Beginnend mit einer Evaluation von Prototypen
über das Testen einer Betaversion, die Evaluation des fertigen Produktes bis hin zu
Feldtests mit den tatsächlichen Anwendern in einer realen Anwendungssituation. Im
Folgenden soll jedoch immer von der Evaluation des fertigen Produktes ausgegangen
werden, um die Komplexität der Untersuchungen zu begrenzen und den Rahmen der
Arbeit nicht zu sprengen.
In Kapitel 4 wird eine abschließende Bewertung der vorgestellten Verfahren
vorgenommen.
4

Kapitel 2: Theorien und Modelle der Softwareevaluation
2 Theorien und Modelle der Softwareevaluation
Im Folgenden sollen ausgewählte Theorien und Modelle zur Usability und zum
Umgang von Menschen mit technischen Schnittstellen präsentiert werden. Sie sollen ein
Grundverständnis zum Thema Usability legen und bilden so die Grundlage für die
erfolgreiche Evaluation von Nutzerschnittstellen. Modelle als zweckorientierte,
abstrahierende Abbildungen der Realität liefern dabei einen besonders wertvollen
Beitrag zum Verständnis.
2.1 Ein Usability-Referenz-Modell
Winter, Wagner und Deissenboeck haben ein Usability-Modell auf Basis eines
definierten Metamodells entwickelt. Ihr Modell umfasst zwei Dimensionen. Auf der
einen Achse werden die Merkmale der (logischen) Nutzerschnittstelle des
Softwaresystems abgetragen, auf der anderen Achse die Aktivitäten des Nutzers. Durch
diese Aufteilung wollen die Autoren eine Vermischung von System- und
Nutzereigenschaften vermeiden, die ihrer Ansicht nach häufig bei etablierten Usability-
Modellen auftreten. Jede Achse wird als Baum aus sog. Fakten bzw. Aktivitäten
aufgebaut, bis die einzelnen Fakten so feingranular wie möglich sind. Jedem Fakt
werden daraufhin Attribute zugewiesen. Schließlich werden die Einflüsse der Attribute
des Systems auf die Attribute der Nutzeraktivität modelliert. Durch diese
Systematisierung erreichen die Autoren eine Explikation der Beziehungen zwischen
Systemeigenschaften und den Eigenschaften der Nutzerinteraktion. Die
Nutzerinteraktionen werden als Usability erlebt. Durch diese explizite Modellierung
kann ein gemeinsames Systemverständnis innerhalb eines Teams entwickelt werden und
die Stellschrauben zur Verbesserung einzelner Aspekte der Nutzerinteraktion werden
besser verstanden.
5

Kapitel 2: Theorien und Modelle der Softwareevaluation
Die logische Nutzerschnittstelle als sichtbarer Teil der Software wird wie folgt
aufgebrochen:
Eingabekanäle
Ausgabekanäle
Logische Nutzerschnittstelle
Dialogmanagement
Eingabedaten
Ausgabedaten
Abbildung 1: Untergliederung der logischen Nutzerschnittstelle
Die Teilfakten besitzen wiederum folgende Attribute [WWD07]:
• Existenz: Das grundlegendste Attribut ist, ob ein Fakt überhaupt existiert oder
nicht. Bereits die Existenz eines Fakts kann positiven oder negativen Einfluss
auf bestimmte Aktivitäten haben.
• Relevanz: Ein Fakt ist relevant, wenn er angemessen und wichtig in konkreten
Anwendungskontext ist.
• Eindeutigkeit: Ein eindeutiger Fakt ist präzise und klar. Eindeutigkeit ist häufig
für Informationen oder Steuerelemente wichtig, die korrekt interpretiert werden
müssen.
• Einfachheit: Für viele Fakten ist es wichtig, dass sie in einem bestimmten
Kontext einfach sind, d. h. klein und geradlinig.
• Konformität. Es gibt zwei Arten von Konformität: Konformität zu
existierenden Standards und Richtlinien, und Konformität zu den Erwartungen
des Nutzers. In beiden Fällen respektiert und folgt der Fakt bestehenden Regeln
oder Modellen.
• Konsistenz: Es gibt zwei Arten von Konsistenz: interne und externe Konsistenz.
Interne Konsistenz bedeutet, dass das gesamte Produkt einheitlichen Regeln
folgt. Externe Konsistenz zielt dagegen auf die Korrespondenz mit externen
Fakten wie z. Β. Analogien oder dem Sachverständnis des Nutzers ab.
• Beherrschbarkeit: Das Verhalten eines beherrschbaren Faktes kann durch die
Aktionen eines Nutzers stark beeinflusst werden
6

Kapitel 2: Theorien und Modelle der Softwareevaluation
• Anpassbarkeit: Ein anpassbarer Fakt kann ebenso wie ein beherrschbarer Fakt
vom Nutzer beeinflusst werden, jedoch kann ein anpassbarer Fakt eine
Voreinstellung besitzen gemäß den Bedürfnissen und Präferenzen des Nutzers
dauerhaft festgelegt werden.
• Geschütztheit: Im Gegensatz zu beherrschbaren und anpassbaren Fakten kann
ein geschützter Fakt nicht durch den Nutzer verändert werden, was bei
kritischen Systemteilen erwünscht sein kann.
• Anpassungsfähigkeit: Ein anpassungsfähiger Fakt passt sich an die Nutzerbedürfnisse
oder den Kontext an. Im Gegensatz zu anpassbaren Fakten arbeitet
ein anpassungsfähiger Fakt dabei ohne explizite Nutzereingaben.
Die Nutzeraktivitäten lassen sich folgendermaßen strukturieren:
Zielbildung
Willensbildung
Interaktion mit dem Produkt
Ausführung Auswertung
Festlegen
der Aktion
Ausführung
der Aktion
Wahrnehmung
des Umweltzustands
Interpretation
des Umweltzustands
Abbildung 2: Untergliederung der Interaktion mit dem Produkt [WWD07]
Jedem der unteren Fakten lassen sich nun die folgenden Attribute zuordnen:
• Häufigkeit: Die Anzahl des Auftretens einer Aufgabe
• Dauer: Die Zeitspanne, die eine Aufgabe benötigt
Evaluation
des
Ergebnisses
• Physischer Stress: Die Summe aller physischen Anstrengungen, die zur
Erfüllung einer Aufgabe nötig sind
• Kognitive Belastung: Die Summe aller mentalen Anstrengungen, die eine
Aufgabe erfordert.
7

Kapitel 2: Theorien und Modelle der Softwareevaluation
• Wahrscheinlichkeit eines Fehlers: Die relative Häufigkeit von fehlerhaften
Ausführungen einer Aufgabe.
Auf Basis der soeben vorgestellten Attribute können nun die Beziehungen modelliert
werden. Um beispielsweise auszudrücken, dass die interne Konsistenz des
Dialogmanagements die Wahrscheinlichkeit eines Fehlers bei der Interpretation (der
Informationen) reduziert, kann folgende Regel formuliert werden:
[Dialogmanagement | INTERNE KONSISTENZ]
� –[Interpretation | FEHLERWAHRSCHEINLICHKEIT]
Allgemein haben die Regeln immer die Form:
[Fakt f | ATTRIBUT A1] � +/–[Aktivität a | ATTRIBUT A2]
Hierdurch wird ausgedrückt, dass das Attribut A1 des Faktes f einen positiven (oder
negativen) Einfluss auf das Attribut A2 von Aktivität a besitzt.
Das so entwickelte Usability-Modell muss nun noch für bestimmte Einsatzzwecke
konkretisiert werden. Die Regeln werden dabei unter Berücksichtigung der
Produkteigenschaften formuliert. Je nach dem Einsatzkontext kann Usability z. B. als
besonders effiziente Arbeit oder als besonders sichere Arbeit verstanden werden.
Entsprechend verlagert sich das Gewicht z. B. zwischen der Dauer und der
Fehlerwahrscheinlichkeit bei der Aufgabenerfüllung.
2.2 Die Theorie des explorativen Lernens
Die Theorie des explorativen Lernens formuliert ein Modell über die kognitiven
Prozesse, die ein Nutzer anwendet, um mithilfe einer Schnittstelle eine gegebene
Aufgabe zu lösen [PLRW92]. Prinzipiell handelt es sich hier um ein zyklisches Modell.
Ausgehend von Startziel entwickelt der Nutzer einen Plan für eine Aktion, führt diese
Aktion aus, evaluiert die Rückmeldungen des Systems, überdenkt seine Ziele und
beginnt dann von neuem.
Die Ziele des Nutzers sind im Modell hierarchisch angeordnet. Ein Oberziel besteht aus
mehreren Zwischenzielen, die wiederum aus Unterzielen aufgebaut sind. Die einfachste
Form eines Ziels stellt eine Aktion dar, die autonom vom Nutzer ausgeführt werden
kann. Ziele sind auch mit Aussagen über das vorhandene Hintergrundwissen des
Nutzers und über seine Umweltbeobachtungen verbunden. Wenn eine solche Aussage
8

Kapitel 2: Theorien und Modelle der Softwareevaluation
wahr wird (z. B. durch Beobachtung), so wird die Verbindung zwischen der Aussage
und den Zielen aktiviert. Wenn alle eingehenden Verbindungen einer Aktion aktiviert
sind, so wird sie ausgeführt. Durch Rückmeldungen des Systems werden Ziele vom
Nutzer deaktiviert, sofern sie als erledigt wahrgenommen werden. Durch die Erledigung
aller Teilziele wiederum werden die entsprechenden Oberziele erledigt. Dieser Prozess
pflanzt sich bis zur Wurzel der Zielhierarchie fort.
Um den Unterschied zwischen ausstehenden Zielen und erfüllten Zielen modellieren zu
können, besteht jedes Ziel aus zwei Knoten (vgl. Abbildung 3), einem Will-Knoten, der
ein noch nicht erfülltes Ziel ausdrückt, und einem Erledigt-Knoten, der ein erfülltes Ziel
repräsentiert.
Sofern mehrere Ziele in einer bestimmten Reihenfolge erfüllt werden müssen, lässt sich
dies durch den Und-dann-Knoten modellieren. Er wird durch das Oberziel und die
vorausgehende Aktion aktiviert und ermöglicht so die Ausführung des nachfolgenden
Ziels erst nach der Ausführung des vorhergehenden.
Legende
Aktivierungsverbindung
Hemmende Verbindung
erledigt
will
Tippe den
Benutzernamen ein
Gib dem System meinen
Benutzernamen
erledigt
unddann
erledigt
will
Drücke die
EINGABE-Taste
Abbildung 3: Beispielhafte Zielstruktur mit Und-dann-Sequenz [PLRW92]
will
9

Kapitel 3: Methoden der Softwareevaluation
3 Methoden der Softwareevaluation
Im Folgenden sollen verschiedene Methoden der Softwareevaluation dargestellt werden.
Unter Methode wird dabei ein bestimmtes Vorgehen zur Gewinnung von Erkenntnissen
über die Usability einer Software verstanden.
3.1 Analytische Evaluationsmethoden
Analytische Evaluationsmethoden werden im Gegensatz zu den unten vorgestellten
empirischen Methoden nicht mit Hilfe von Testnutzern, sondern von Usability-Experten
oder von den Entwicklern der Software durchgeführt. Üblicherweise sind diese
Experten jedoch durch ihr Vorwissen über die Software bei der Evaluation nicht
objektiv. Um dennoch zu brauchbaren Aussagen über die Usability zu kommen, wurden
in der Literatur verschiedene Methoden entwickelt, die den Experten bei der Bewertung
helfen sollen.
Heuristische Evaluation
Der naheliegendste Evaluationsansatz liegt darin, Probleme, die aus der Vergangenheit
mit anderer Software bekannt sind, in Form von Prinzipien zu generalisieren. Diese
Prinzipien, die oft auch als Guidelines bezeichnet werden, können dann an der zu
evaluierenden Software überprüft werden [Ni92]. Nielsen schlägt dafür allerdings kein
konkretes Vorgehensmodell vor, sondern betont, dass aufgrund der geringeren
Formalität die heuristische Evaluation gleichsam eine „Discount-Methode“ mit sehr
geringen Kosten ist.
Nielsen legt allerdings großen Wert darauf, dass die Evaluation von Usability-Experten
durchgeführt wird. Besonders erfolgreich sind nach seinen Erfahrungen die sog.
„Doppelexperten“, die sich sowohl mit den Usability-Regeln, als auch mit dem
getesteten Programm sehr gut auskennen. Außerdem empfiehlt er den Einsatz von
Expertengruppen mit drei bis fünf Mitgliedern, da sie bessere Ergebnisse liefern würden
als einzelne Experten.
Cognitive Walkthrough
Der Cognitive Walkthrough evaluiert eine Benutzerschnittstelle auf der Basis
kognitionspsychologischer Erkenntnisse, insbesondere unter Berücksichtigung der
Theorie des explorativen Lernens (vgl. Kapitel 2.2). Mit Hilfe des Cognitive
10

Kapitel 3: Methoden der Softwareevaluation
Walkthrough können vor allem sog. Walk-up-and-use-Systeme (d. h. Systeme, die ohne
Benutzerschulung bedient werden können sollen) dahingehend evaluiert werden, ob ein
Nutzer ein gegebenes Ziel ohne weitere Anleitung mit der Software umsetzen kann. Zur
Zielerfüllung sind in der Regel mehrere Teilschritte auszuführen. Der Cognitive
Walkthrough untersucht, ob der Nutzer selbstständig diese Teilschritte mit den durch
die Nutzerschnittstelle gegebenen Informationen bilden kann und ob er diese
Teilschritte erfolgreich ausführen kann. Um auch Analysten ohne umfangreiches
Wissen über Kognitionspsychologie die Nutzung der Methode zu erlauben, wird der
Analyst mit Hilfe von Formularen durch den Prozess begleitet.
Zunächst soll die Terminologie der Methode im Überblick dargestellt werden, um ein
Verständnis für die Begrifflichkeiten zu erarbeiten.
Aufgabe Eine Aktivität, die ein Nutzer mit dem untersuchten System
durchführen möchte, z. B.
• „Überprüfe die Rechtschreibung von Datei ‚foo‘“
• „Melde dich am Computer an“
Ziel Etwas, das der Benutzer erreichen möchte. Höhere Ziele können mit
Aufgaben identisch sein, während es sich bei niederen Zielen um
Aktionen handeln kann, z. B.
• ÜBERPRÜFE DIE SCHREIBWEISE VON DATEI „FOO“
• STARTE DAS TEXTVERARBEITUNGSPROGRAMM
• DRÜCKE DIE ENTER-TASTE
Aktion Eine physische Aktivität, die der Nutzer ausführen kann. Es kann
sich dabei um eine einfache, „atomare“ Aktion oder um eine gut
geübte Sequenz von atomaren Aktionen handeln, z. B.
• Drücke die „S“-Taste
• Wähle „Drucken“ aus dem Datei“-Menü
Zielstruktur Eine Hierarchie von verbundenen Zielen. Unter jedem
übergeordneten Ziel können die Teilziele mit Hilfe von „und-dann“
in eine bestimmte Reihenfolge gebracht werden oder aber
ungeordnet sein, z. B.
• MELDE DICH AM COMPUTER AN
GIB DEN BENUTZERNAMEN EIN
und-dann GIB DAS PASSWORT EIN
• LÖSCHE DIE DATEIEN ‚FOO‘ UND ‚BAR‘
LÖSCHE ‚FOO‘
LÖSCHE ‚BAR‘
Und-dann Eine Zielstruktur, in der zwei oder mehr Unterziele in einer
bestimmten Reihenfolge ausgeführt werden müssen (vgl. Beispiel
oben).
Schritt Die Analyseeinheit beim Cognitive Walkthrough. Bei jedem Schritt
berücksichtigen sind zu jeder Aktion drei Fragen zu beantworten:
• Welche Ziele sollte der Nutzer unmittelbar vor der Action
haben?
• Werden diese Ziele beim aktuellen Zustand der Schnittstelle
11

Kapitel 3: Methoden der Softwareevaluation
den Nutzer dazu anregen, die korrekte Aktion auszuwählen
und auszuführen?
• Wie beeinflusst die Änderung der Nutzerschnittstelle nach
der richtigen Aktion die Ziele des Nutzers?
Tabelle 1: Die Terminologie des Cognitive Walkthrough
Im Vorfeld der Evaluation müssen einige Vorbereitungen getroffen werden. Zunächst
müssen Aufgaben ausgewählt werden, die analysiert werden sollen. Dabei sollten nicht
nur einfache, atomare, sondern vor allem komplexere Aufgaben ausgewählt werden, die
eine Kombination mehrerer Aktionen erforderlich machen. Denn der Übergang
zwischen Teilschritten bereitet den Benutzern in der Praxis häufig Probleme und der
Cognitive Walkthrough zielt insbesondere auf die Aufdeckung von solchen Problemen
beim Übergang zwischen Teilschritten ab [PLRW92]. Im Anschluss müssen die
ausgewählten Aufgaben beschrieben werden, wobei darauf Wert gelegt werden sollte,
die Beschreibung nicht systemspezifisch, sondern möglichst allgemeinverständlich
vorzunehmen. Auch Annahmen über den Systemzustand bei Beginn des Tests und über
das Hintergrundwissen der Nutzerpopulation müssen hier explizit formuliert werden.
Anschließend wird eine korrekte Aktionssequenz definiert, mit der die gestellte
Aufgabe gelöst werden kann. Dabei sollte es sich um die beste durch die Schnittstelle
angebotene Sequenz handeln, um relevante Aussagen über die Systemqualität zu
erhalten. Wird eine suboptimale Sequenz analysiert, so besitzen die Ergebnisse keinen
Aussagewert über die Usability des Systems. Es ist für die Ergebnisse entscheidend, die
richtige Granularitätsstufe für die einzelnen Schritte zu wählen, um bestimmte Probleme
finden zu können. Besteht zwischen einem Oberziel und einem seiner Unterziele zu
große Ähnlichkeit aus Sicht des Nutzers, so kann es passieren, dass nach der
erfolgreichen Ausführung des Unterziels auch das Oberziel als abgeschlossen
angesehen wird (Supergoal-Kill-Off-Problem). Die Autoren schlagen daher vor, mit
einer möglichst feingranularen Modellierung zu beginnen und die Teilziele nur dann
zusammenzufassen, wenn sichergestellt ist, dass sich ein über- und ein untergeordnetes
Ziel nicht zu ähnlich sind.
Um die Entscheidungen des Analysten über das Verhalten der Nutzer zu fundieren,
sollte anschließend die erwartete Nutzerpopulation beschrieben werden. Dabei sind
insbesondere die Erfahrungen mit vergleichbaren Systemen und Nutzerschnittstellen
von Interesse, die ein Hintergrundwissen über das evaluierte System begründen.
12

Kapitel 3: Methoden der Softwareevaluation
Abschließend werden die anfänglichen Ziele des Nutzers beschrieben, die sich aus der
Aufgabenstellung und dem Hintergrundwissen des Nutzers ableiten. Sollten mehrere
Zielstrukturen denkbar sein, so sollten sämtliche dieser Strukturen dargestellt werden
und jeweils mit einer geschätzten Wahrscheinlichkeit für ihr Auftreten versehen
werden.
Im Anschluss an diese vorbereitenden Maßnahmen wird jede Aktion evaluiert. Dabei
werden die folgenden drei Schritte durchgeführt
1. Vergleich zwischen den tatsächlichen und den erwünschten Zielen eines Nutzers
2. Probleme bei der Auswahl einer Aktion mit den gegebenen Zielen
3. Die Auswirkungen der Systemantwort auf die Zielstrukturen des Nutzers
Zunächst werden vom Entwickler die erwünschten Ziele des Nutzers zu Beginn der
Aktion definiert. Anschließend werden diese Ziele basierend auf dem vorangegangenen
Schritt bzw. auf der Vorbereitung mit den wahrscheinlichen Zielstrukturen der Benutzer
verglichen. Dabei können sich Abweichungen ergeben, die zu Problemen beim Umgang
mit der Nutzerschnittstelle führen.
Anschließend wird auf Basis der Zielstruktur anhand einiger Fragen evaluiert, ob der
Benutzer die korrekte Aktion ausführen kann. Damit ein Benutzer die korrekte Aktion
ausführen kann, muss sie z. B. verfügbar und einleuchtend beschriftet sein. Ist dies nicht
gegeben, so liegt ein Aktionskonflikt vor, da der Nutzer nicht die richtige Aktion
ausführen kann, obwohl er das richtige Ziel erfüllen will.
Schließlich wird der Einfluss der Systemrückmeldung auf die Zielstrukturen des
Benutzers untersucht. Die Systemrückmeldung sollte einen Fortschritt melden, sollte
korrekt erfüllte Ziele als solche erscheinen lassen, andererseits aber auch nicht erfüllte
Ziele nicht fälschlicherweise als erfüllt erscheinen lassen. Außerdem können durch
entsprechende Rückmeldungen neue Ziele vom Nutzer gebildet werden. Diese Ziele
bilden die Grundlage für den nächsten Evaluationsschritt, in dem wiederum zunächst
Zielkonflikte und dann Aktionskonflikte analysiert werden.
3.2 Vorbereitung eines empirischen Usability-Tests
Im Gegensatz zu den oben dargestellten analytischen Methoden wird ein Großteil der
Usability-Tests empirisch durchgeführt, d. h. eine Gruppe von Testpersonen benutzt die
13

Kapitel 3: Methoden der Softwareevaluation
Software und wird dabei beobachtet. Aus dem Verhalten der Probanden werden
Rückschlüsse auf die Usability der Software gezogen. Um eine solche empirische
Studie durchführen zu können, sind im Vorfeld einige Schritte der Vorbereitung
durchzuführen.
Zunächst einmal müssen die Versuchspersonen ausgewählt werden. Dabei sind
insbesondere die Anzahl und die Art der Personen entscheidend. Grundsätzlich werden
die Aussagen bei steigender Zahl an Probanden immer präziser. Tullis und Albert
weisen jedoch darauf hin, dass nach ihren Erkenntnissen bereits mit sechs bis acht
Teilnehmern qualitativ gute Erkenntnisse bei geringen Kosten erzielt werden können.
Bei abschließenden Evaluationen empfehlen sie dagegen 50 bis 100 Probanden [TA08,
S. 59]. Die Probanden sollten von ihren Fähigkeiten und ihrem Hintergrundwissen
möglichst nah an den Personen liegen, die die Software später nutzen werden. Ein Test,
bei dem die Entwickler als Versuchspersonen eingesetzt werden ist in der Regel nicht
repräsentativ, da die Entwickler das System aufgrund ihres allgemeinen technischen
Sachverstands und ihrer Produktkenntnis im Besonderen die Software wesentlich
effizienter bedienen können als die Endnutzer.
Danach sind Aufgaben festzulegen, die die Probanden im Rahmen des Usability-Tests
erfüllen sollen. Die Bearbeitung der Aufgaben bildet den Bezugsrahmen zur Messung
vieler Usability-Parameter. Zudem kann überprüft werden, ob der Proband die
Aufgaben (korrekt) lösen konnte. Dies gibt Aufschluss darüber, ob der Proband reale
Aufgaben mit der Software bewältigen könnte.
3.3 Befragungen
Ein naheliegendes Mittel, um von den Probanden Erkenntnisse über die Usability der
Software zu erhalten, ist die Probanden zu befragen. Durch Befragungen können
insbesondere Erkenntnisse über die Zufriedenheit der Nutzer gewonnen werden. Dies ist
mit anderen Methoden in der Regel nicht möglich. Wenn also die Nutzerzufriedenheit
für die zu testende Software erfolgskritisch ist (z. B. bei Websites), so sind Befragungen
die zu bevorzugende Evaluationsmethode. Bei der Gestaltung einer solchen Befragung
sind jedoch gewisse Hinweise zu beachten, um ein optimales Ergebnis zu erzielen.
14

Kapitel 3: Methoden der Softwareevaluation
Fragebogendesign
Zunächst soll an dieser Stelle auf die Gestaltung von Fragen im Rahmen von
Fragebögen eingegangen werden. Im Zusammenhang der Usability-Evaluation haben
sich vor allem die Likert-Skala und Polaritätsprofile bewährt. Mithilfe der Likert-Skala
werden in der Regel vorgegebene Aussagen über das Produkt bewertet, z. B. „Ich fand
die Navigation verwirrend“. Zur Bewertung der Aussage dient dem Probanden eine
Skala in der folgenden Form [Fri90, S. 175]:
1. Ich lehne es stark ab
2. Ich lehne es ab
3. Ich weiß nicht, neutral
4. Ich stimme zu
5. Ich stimme stark zu
Es ist auch möglich, sieben statt fünf Kategorien zu verwenden, um eine feinere
Einteilung zu nutzen. Nachteilig ist dann allerdings, dass die Beschriftung für die
Zwischenschritte schwieriger wird, was auch nicht dazu verleiten sollte, Adverbien wie
„extrem“ oder „absolut“ bei der Beschriftung zu verwenden, da so die
Wahrscheinlichkeit für eine starke Zustimmung oder Ablehnung verringert. Schließlich
besteht noch die Möglichkeit, eine gerade Anzahl an Optionen zu verwenden. Da es in
diesem Fall keine Mitte, bzw. keine neutrale Position gibt, ist der Proband gezwungen,
sich zumindest tendenziell für Zustimmung oder Ablehnung zu entscheiden. Die
einzelnen Antworten werden in der Regel mit Zahlen kodiert (bei der Standard-Skala
z. B. 0 bis 4).
Mithilfe von Polaritätsprofilen wird ein Objekt in ein Raster von Gegensatzpaaren
eingeordnet. Beispiele hierfür sind:
schwach ○ ○ ○ ○ ○ ○ ○ stark
schön ○ ○ ○ ○ ○ ○ ○ hässlich
heiß ○ ○ ○ ○ ○ ○ ○ kalt
hell ○ ○ ○ ○ ○ ○ ○ dunkel
Auch diese Skala wird mit Zahlen kodiert. Man geht dabei implizit davon aus, dass die
Abstände zwischen den einzelnen Kategorien gleich groß sind.
Es gilt zu beachten, dass die Ergebnisse bei Umfragen durch die Anwesenheit des
Moderators verzerrt werden können. Probanden werden versuchen, dem Moderator
15

Kapitel 3: Methoden der Softwareevaluation
diejenigen Antworten zu geben, die er erhofft. Der Proband wird in Gegenwart eines
Moderators also eine positivere Einschätzung abgeben, als er es in einer anonymen
Befragungssituation, z. B. einer Online-Befragung, tun würde. Man spricht in diesem
Zusammenhang von der „sozialen Erwünschtheit“ [TA08, S. 126] bestimmter
Antworten. Diesem Problem kann der Moderator begegnen, indem er den Probanden
beim Ausfüllen des Fragebogens nicht beobachtet. Noch besser ist es, wenn der
Moderator den Raum verlässt, während der Proband den Fragebogen ausfüllt.
Befragung nach der Aufgabe
Im Anschluss an jede ausgeführte Aufgabe kann der Proband über die empfundene
Komplexität der Aufgabe befragt werden. Im einfachsten Fall muss er z. B. die Aussage
„Diese Aufgabe war einfach zu lösen“ auf einer Likert-Skala bewerten („Ich lehne es
stark ab“ vs. „Ich stimme stark zu“).
Eine etwas differenziertere Aussage lässt sich mit Hilfe des After Scenario
Questionnaire (ASQ) von Jim Lewis treffen. Dabei werden im Anschluss an eine
Aufgabe die folgenden drei Aussagen auf einer Likert-Skala mit sieben Kategorien
bewertet [TA08, S. 129]:
1. „Ich bin damit zufrieden, wie einfach ich die Aufgaben erledigen konnte.“
2. „Ich bin mit dem Zeitaufwand zufrieden, mit dem ich die Aufgaben erledigen
konnte“
3. „Ich bin mit den unterstützenden Informationen (Online-Hilfe, Nachrichten.
Dokumentation) bei der Erfüllung der Aufgaben zufrieden.
Durch diese drei Aussagen werden gleichzeitig die Effektivität (Frage 1), die Effizienz
(Frage 2) und die Zufriedenheit (alle drei Fragen) des Nutzers erhoben.
Mit den so erhobenen Nutzereindrücken können einerseits solche Aufgaben identifiziert
werden, die besonders schwierig oder aufwändig zu lösen waren, und die somit
Kandidaten für eine Usability-Optimierung sind. Außerdem kann durch eine
Mittelwertbildung über alle einzelnen Aufgabenevaluationen die Gesamtusability des
Systems erhoben werden.
Bewertungen nach der Sitzung
Nach dem Abschluss des eigentlichen Usability-Tests kann mithilfe eines
umfangreichen Fragebogens der Gesamteindruck der Testperson erhoben werden. Im
16

Kapitel 3: Methoden der Softwareevaluation
Gegensatz zur Mittelwertbildung aus der Bewertung einzelner Aufgaben wir hier jedoch
der Proband insbesondere seinen letzten Eindruck über die Software zum Ausdruck
bringen, der nicht notwendigerweise mit dem Mittelwert übereinstimmt.
Nichtsdestotrotz handelt es sich hier um den prägenden Eindruck für den Probanden,
der seine zukünftige Einstellung gegenüber dem Produkt nachhaltig beeinflussen kann.
Für solche abschließenden Fragebögen gibt es in der Literatur eine Reihe von
Vorschlägen, die teilweise nur den Gesamteindruck über die Usability messen, teilweise
jedoch auch in Kategorien unterteilt sind, um Teilaspekte der Usability bewerten zu
können. Aus Platzgründen kann hier nicht auf alle diese Fragebögen eingegangen
werden. Vergleichsstudien [TA08, S. 146] haben gezeigt, dass mit dem System
Usability Scale (SUS) ein Fragebogen existiert, der schon bei kleinen Testgruppen sehr
konsistente Ergebnisse liefert. Der SUS besteht aus zehn jeweils leicht abgewandelten
Aussagen über die Usability, von denen jeweils fünf positiv bzw. fünf negativ
formuliert sind [TA08, S. 138]:
1. Ich denke, dass ich dieses System gerne häufig nutzen würde.
2. Ich fand das System unnötig komplex.
3. Ich denke, das System war einfach zu benutzen.
4. Ich denke, ich würde die Hilfe eines Technikers benötigen, um das System
benutzen zu können.
5. Ich halte die verschiedenen Funktionen des Systems für gut integriert.
6. Ich halte das System für zu inkonsistent.
7. Ich kann mir vorstellen, dass die meisten Leute sehr schnell lernen würden, mit
dem System umzugehen.
8. Ich fand das System sehr mühsam zu benutzen.
9. Ich fühlte mich bei der Nutzung des Systems sehr sicher.
10. Ich musste viele Dinge lernen, bevor ich das System nutzen konnte.
Die Zustimmung bzw. Ablehnung zu allen Aussagen wird auf einer Likert-Skala mit
fünf Optionen bewertet und mit Werten von 0 bis 4 kodiert. Die Kodierung aller
negativen Aussagen wird von vier abgezogen. Daraufhin wird die Summe dieser Werte
gebildet, wodurch ein Wert zwischen 0 und 40 ermittelt wird. Durch Multiplikation mit
2,5 wird dann der sog. SUS-Score ermittelt, der als Prozentwert interpretiert werden
17

Kapitel 3: Methoden der Softwareevaluation
kann, wobei 100 % einem perfekten System entsprechen. Werte unter 60 % sind nach
Tullis und Albert ein Indiz für gewichtige Usability-Probleme, Werte über 80 % können
dagegen als gut angesehen werden [TA, S. 149].
3.4 Ausführungsmetriken
Aus wirtschaftlicher Sicht ist bei vielen Anwendungen vor allem die Bewertung des
Handelns der Probanden entscheidend.
Bearbeitungserfolg
Die einfachste Form, den Bearbeitungserfolg zu messen, ist eine binäre Entscheidung
(Bearbeitung erfolgreich / Bearbeitung nicht erfolgreich). Dabei bezieht sich die
Aussage immer auf eine konkrete Aufgabenstellung, die der Proband erfüllen soll. Das
Ergebnis wird in Form von Binärvariablen für jeden Probanden und jede Aufgabe
kodiert:
Wert Bedeutung
0 Bearbeitung erfolgreich
1 Bearbeitung nicht erfolgreich
Tabelle 2: Binäre Kodierung des Bearbeitungserfolgs
Zur Analyse der Daten sollte zunächst für jede gestellte Aufgabe der Mittelwert über
alle Probanden berechnet werden. Diese Erfolgsraten der Aufgaben können dann –
angereichert mit Streumaßen wie z. B. Konfidenzintervallen – in einem
Balkendiagramm dargestellt werden, um zwischen den einzelnen Aufgaben einen
Vergleich zu ziehen und diejenigen Aufgaben mit besonders auffälligen Problemen zu
identifizieren.
Es ist jedoch nicht immer sinnvoll, den Erfolg des Probanden rein binär zu kodieren.
Häufig ergeben sich auch Zwischenzustände, die in der Analyse entsprechend
berücksichtigt werden sollten. Denkbar ist hier z. B. eine Gewichtung der Ergebnisse:
Bewertung Interpretation
1,0 Vollständiger Erfolg (ohne Hilfestellung)
0,5 Teilweiser Erfolg
0,0 Aufgabe oder falsche Antwort
Tabelle 3: Gewichtung des Bearbeitungserfolges [TA08, S. 71]
18

Kapitel 3: Methoden der Softwareevaluation
Anlog zur Erfolgsrate kann durch Mittelwertberechnung hier eine „Erfolgspunktzahl“
berechnet werden. Alternativ kann der Erfolg auch anhand einer geordneten Skala
festgestellt werden, die der Erfahrung des Nutzers entspricht:
Kodierung Bedeutung
1 Kein Problem. Der Proband hat die Aufgabe erfolgreich ohne
Schwierigkeiten oder Ineffizienzen gelöst.
2 Kleinere Probleme. Der Proband hat die Aufgabe gelöst, jedoch einen
kleinen Umweg genommen. Er hat ein oder zwei kleine Fehler gemacht,
die er jedoch schnell beheben und so die Aufgabe erfolgreich lösen
konnte.
3 Größere Probleme. Der Proband hat die Aufgabe erfolgreich gelöst,
jedoch mit größeren Problemen. Er musste sich abmühen und hat einen
größeren Umweg gemacht, schließlich jedoch die Aufgabe erfolgreich
gelöst.
4 Fehlschlag / Aufgabe: Der Proband hat die falsche Antwort gegeben oder
vor Erledigung der Aufgabe aufgegeben, oder der Moderator ist zur
nächsten Aufgabe übergegangen vor dem erfolgreichen Abschluss.
Tabelle 4: Ordinale Kodierung des Bearbeitungserfolges
Da es sich hier um ordinale Daten handelt, darf nun allerdings kein Mittelwert gebildet
werden. Stattdessen sollte eine relative Häufigkeitsverteilung der Kategorien für jede
Aufgabe erstellt werden.
Bearbeitungsdauer
Für viele Anwendungen ist die Bearbeitungsdauer von entscheidender Relevanz. Hier
handelt es sich auch um eine wirtschaftlich relevante Kennzahl. Je kürzer die
Bearbeitungszeit pro Fall ist, z. B. bei der Reisebuchung per Telefon, umso mehr Fälle
können pro Zeit abgearbeitet werden, was höhere Abfertigungsraten und somit
Kostenersparnisse nach sich zieht.
In der Praxis gestaltet sich die Messung der Bearbeitungsdauer jedoch relativ schwierig.
Zum Einen müssen der Start- und der Endzeitpunkt der Bearbeitung festgestellt werden
können. Dazu kann der Proband dazu aufgefordert werden, die Aufgabenstellung laut
vorzulesen, sodass nach dem Lesen eine Stoppuhr gestartet werden kann. Den
Endzeitpunkt markiert die Antwort des Probanden. Zum anderen soll die
Bearbeitungsdauer durch die Zeitmessung nicht beeinflusst werden. Wenn der Proband
die Zeitmessung wahrnimmt, kann er in Leistungsdruck geraten, der seine Leistung
negativ beeinflusst. Wenn der Proband andererseits gänzlich ohne Zeitdruck arbeitet,
kann er die Aufgabe evtl. ineffizient lösen, da er eine kleine „Besichtigung“ der
Software durchführt, ohne konkret auf das Ziel hinzuarbeiten. Daher sollte der Proband
19

Kapitel 3: Methoden der Softwareevaluation
dazu aufgefordert werden, die Aufgaben „so schnell wie möglich“ zu bearbeiten, ohne
ihn explizit auf die Zeitmessung hinzuweisen. Nach erfolgter Zeitmessung sollten die
Messdaten noch um Ausreißer bereinigt werden. Wird der Proband während des Tests
nicht kontrolliert, so kann er entweder die Ausführung einer Aufgabe für die
Mittagspause unterbrechen, was zu ungewöhnlich langen Bearbeitungszeiten führt. Auf
der anderen Seite können Probanden dazu neigen, die Aufgaben nicht sorgfältig zu
bearbeiten, was zu extrem kurzen Bearbeitungszeiten führt. Solche Ausreißer können
mithilfe statistischer Verfahren identifiziert und aussortiert werden.
Zur Analyse der Messdaten kann wiederum für jede gestellte Aufgabe der Mittelwert
der Bearbeitungszeit berechnet werden. Darüber hinaus kann die Bearbeitungszeit in
Intervalle unterteilt werden und es wird die Anzahl bzw. der Anteil an Probanden
dargestellt, die in das entsprechende Intervall fallen. Schließlich ist häufig nur
entscheidend, dass der Nutzer die gestellte Aufgabe innerhalb eines bestimmten
Zeitlimits (z. B. eine Minute) lösen kann. In solchen Fällen ist der Anteil an Probanden,
der diese Grenze nicht überschritten hat, von besonderem Interesse.
Bearbeitungseffizienz
Die Bearbeitungseffizienz kann zwar aus der Bearbeitungsdauer abgeleitet werden, es
ist jedoch vorteilhaft, direkt den Aufwand bestimmen zu können, die zu Lösung der
Aufgabe notwendig ist. Dies ist in den meisten Fällen ebenfalls relativ einfach möglich.
Aufwand besteht für den Nutzer in kognitivem Aufwand einerseits und physischem
Aufwand andererseits. Kognitiver Aufwand kann darin bestehen, den richtigen Link auf
einer Website zu finden oder die nächste notwendige Aktion festzulegen. Physischer
Aufwand besteht z. B. in Mausklicks oder Tastatureingaben. Im einfachsten Fall wird
die Anzahl solcher Aktionen (mithilfe darauf spezialisierter Software) gezählt und
anschließend werden wiederum die Mittelwerte für jede Aufgabe bestimmt. Ein
Vergleich zwischen Aufgaben mit ähnlicher Komplexität kann dabei zu interessanten
Beobachtungen führen.
3.5 Verhaltensmetriken und physiologogische Metriken
Während eines Usability-Tests erfüllt ein Proband in der Regel nicht ausschließlich
seine Aufgaben. Vielmehr gibt er eine Reihe großteils unbewusster Signale von sich,
die für die Usability-Bewertung von großem Interesse sein können. Auf die
20

Kapitel 3: Methoden der Softwareevaluation
Beobachtungs- und Analysemöglichkeiten solcher Signale soll im Folgenden
eingegangen werden.
Verbale Verhaltensweisen
Probanden geben während eines Usability-Tests meist beiläufig Kommentare über ihre
Empfindungen über die Software ab. Grundsätzlich lassen sich diese Kommentare in
die Kategorien positiv, negativ und neutral einordnen. Indem die Kommentare
aufgezeichnet und gezählt werden, kann anschließend für jede Aufgabe eine
Häufigkeitsverteilung der Klassen erstellt werden. Anhand der Häufigkeitsverteilung
lassen sich dann die einzelnen Aufgaben untereinander vergleichen oder es lassen sich
die Ergebnisse ähnlicher Aufgaben bei unterschiedlichen untersuchten Programmen
oder unterschiedlichen Designvorschlägen vergleichen. Aufgaben bzw. Software mit
einem hohen Anteil an negativen Bewertungen müssen demnach bei einer Verbesserung
besonders berücksichtigt werden.
Nichtverbale Verhaltensweisen
Zu den nichtverbalen Verhaltensweisen zählen z. B. Gesichtsausdrücke, Gesten oder
nervöses Fingerklopfen. Solche Ausdrücke wechseln jedoch unter Umständen sehr
schnell, so dass hier eine Videoaufzeichnung zur nachgelagerten Analyse sinnvoll sein
kann. Mit entsprechend vorbereiteten Bögen können solche Ausdrücke außerdem recht
schnell dokumentiert werden.
Um aus den gesammelten Verhaltensweisen eine Metrik abzuleiten, werden die Anzahl
positiver und negativer Ausdrücke zusammengezählt und für jede Aufgabe dargestellt.
Tullis und Albert führen als sinnvolles Einsatzbeispiel einen MP3-Player an, auf dem
eine nur schwer leserliche Seriennummer aufgedruckt ist [TA08, S. 171]. Diese
Seriennummer muss bei der Installation der zugehörigen Software eingetragen werden.
Wenn der Proband das Gerät hin und her dreht, es in besserem Licht zu betrachten
versucht oder einen jüngeren Menschen um Unterstützung bittet, so sind dies klare
Indizien für ein Usability-Problem.
Eye-Tracking
Bei Eye-Tracking handelt es sich um eine sehr fortgeschrittene Technologie, die es
erlaubt, die Blickrichtung und die Verweildauer auf bestimmten Punkten der
Nutzeroberfläche zu dokumentieren. Früher waren zum Eye-Tracking recht komplexe
Versuchsaufbauten mit mehreren Kameras notwendig, doch mit den letzten
21

Kapitel 3: Methoden der Softwareevaluation
Entwicklungen kann Eye-Tracking nun relativ einfach und ohne Belastungen für den
Probanden durchgeführt werden.
Die Messdaten können z. B. in Form von „Hitzebildern“ ausgegeben werden. Je höher
die angezeigte „Temperatur“ ist (signalisiert durch die rote Farbgebung), desto länger
hat der Proband auf die entsprechende Stelle geschaut (vgl. Abbildung 4). Basierend auf
diesen Rohdaten können dann Einblicke in die Entstehung bestimmter Usability-
Probleme gewonnen werden.
Ein Ansatz besteht hier in der Analyse von kritischen Steuerungselementen. Gibt es auf
einer Website beispielsweise einen Link, der direkt die Erledigung einer gestellten
Aufgabe ermöglicht und wird beobachtet, dass die Probanden diesen Link nie benutzen,
kann mithilfe des Eye-Tracking analysiert werden, ob die Probanden den Link
überhaupt wahrnehmen [TA08, S. 176]. Dazu wird ein rechteckiger Bereich um den
Link festgelegt. Nun wird bei jedem Probanden – basierend auf den Tracking-Daten –
die Zeit bestimmt, während der er diesen Bereich fixiert. Anschließend kann die
durchschnittliche Fixierungsdauer über alle Probanden ermittelt werden. Alternativ
wird eine Zeitschranke definiert, die notwendig ist, um die Beschriftung zu lesen und es
wird der Anteil an Probanden gemessen, die mindestens so lange diesen Bereich fixiert
haben. Wenn nun die durchschnittliche Fixierungsdauer bzw. der Anteil an Probanden
mit ausreichender Fixierungsdauer sehr gering ist, so wurde das Element offensichtlich
nicht wahrgenommen und daher nicht benutzt. Wurde das Element allerdings lange
genug fixiert, so liegt wahrscheinlich ein Problem mit der Beschriftung des Elementes
vor, da die Probanden den Link nicht mit der ihnen gestellten Aufgabe in Verbindung
gebracht haben.
22

Kapitel 3: Methoden der Softwareevaluation
Abbildung 4: „Hitzebild“ einer Eye-Tracking-Untersuchung [TA08]
Hautwiderstand und Pulsfrequenz
Wenn ein Proband unter Stress gerät, so zeigt sich dies auch an physiologischen
Veränderungen. Durch vermehrtes Schwitzen verringert sich der elektrische
Hautwiderstand und der Puls beschleunigt sich. Stress entsteht bei Usability-Tests z. B.
durch schlecht gestaltete Nutzerschnittstellen, häufig auftretende und irritierende
Fehlermeldungen oder lange Wartezeiten. Studien konnten belegen, dass durch solche
Stressfaktoren der Puls tatsächlich beschleunigt wird, und der Hautwiderstand
23

Kapitel 3: Methoden der Softwareevaluation
herabgesetzt ist [TA08, S. 183 ff.]. Bei gut gestalteten Nutzerschnittstellen tritt meist
sogar ein gegenteiliger Effekt ein, der Puls sinkt also unter das Normalniveau ab.
Durch entsprechende Messinstrumente lassen sich diese Signale heute schon
aufzeichnen. Leider sind die Instrumente allerdings noch relativ unbequem und störend,
sodass sie selbst zu einem Stressfaktor werden können. Technische Entwicklungen
begründen jedoch ebenso wie beim Eye-Tracking die Hoffnung, dass zukünftig solche
Messungen mit weniger Eingriffen möglich sein werden [TA08, S. 185 f.].
Beispielsweise wurde bereits ein Bürostuhl vorgestellt, der die Pulsfrequenz einer
darauf sitzenden Person messen kann. Mithilfe dieser physiologischen Daten lassen sich
nämlich sehr interessante Einblicke in die unbewussten Wirkungen der
Schnittstellengestaltung gewinnen. Schnittstellen mit hohen Stresswerten werden vom
Nutzer mit hoher Wahrscheinlichkeit abgelehnt.
24

Kapitel 4: Fazit
4 Fazit
Die Arbeit hat eine breite Palette an Evaluationsmethoden dargestellt. Einerseits handelt
es sich um analytische Methoden, die direkt von Usability-Experten mit einem tiefen
Sachverständnis angewendet werden. Die permanente Verfügbarkeit von Experten
vorausgesetzt, können diese Methoden begleitend zur Produktentwicklung angewendete
werden. Sie erfordern keine langfristige Vorausplanung oder Analyse von Messdaten.
Dafür sind diese Verfahren gleichzeitig sehr von der Qualität der Experten abhängig
und durch das Hintergrundwissen der Experten können die Ergebnisse gegenüber
Durchschnittsnutzern abweichen.
Daher sollte auf die empirischen Methoden keineswegs bei der Evaluation verzichtet
werden. Nur echte Nutzer mit einem realistischen Hintergrundwissen können
beweiskräftige Aussagen über die Usability liefern. Zudem können hier tatsächlich
Messwerte erhoben werden, die einen Vergleich zwischen unterschiedlichen Produkten,
Produktvarianten oder auch im Zeitablauf ermöglichen. Am effektivsten ist sicherlich
die Kombination mehrerer Verfahren. So können die bestehenden Probleme im Rahmen
von empirischen Usability-Tests identifiziert und anschließend von Usability-Experten
auf ihre Ursache hin analysiert werden
In diesem Zusammenhang soll noch darauf hingewiesen werden, dass es noch einige
weitere Methoden gibt, die im Rahmen dieser Arbeit nicht mehr dargestellt werden
konnten. Insbesondere sind hier aggregierte Metriken zu nennen, die eine Aussage über
die Usability eines gesamten Produktes ermöglichen. Auf Basis dieser Kennzahlen sind
direkte Vergleiche zwischen unterschiedlichen Varianten einfach möglich. Es wurde
auch nicht dargestellt, wie auf Basis von Usability-Kennzahlen wirtschaftliche
Kennzahlen wie der Return on Investment (ROI) berechnet werden können, die den
Nutzen von Usability-Verbesserungen quantifizieren.
Mit der zunehmenden Wichtigkeit von Usability als Wettbewerbsfaktor sollte kein
Unternehmen auf Usability-Tests verzichten. Nur so lassen sich nachvollziehbare
Entscheidungen über konkrete Maßnahmen zur Verbesserung der Usability fällen.
25

Literaturverzeichnis
[Fr90] Jürgen Friedrichs: Methoden empirischer Sozialforschung, Westdeutscher
Verlag, 1990.
[Ha86] Winfried Hacker: Allgemeine Arbeits- und Ingenieurpsychologie: Verlag
Hans Huber, 1986.
[HZ90] Carl Graf Hoyos, Bernhard Zimolong: Ingenieurpsychologie, Verlag für
Psychologie, 1990.
[Ni92] Jakob Nielsen: Finding Usability Problems Through Heuristic Evaluation,
Proceedings of the SIGCHI conference on Human factors in computing
systems, S. 373-380, ACM, 1992.
[Ni93] Jakob Nielsen.: Usability Engineering, AP Professional. 1993.
[PLRW92] Peter G. Polson, Clayton Lewis, John Rieman, Cathleen Wharton: Cognitive
Walkthroughs: A Method for Theory-Based Evaluation of User Interfaces,
International Journal of Man-Machine Studies 36(5), S. 741-773, Academic
Press, 1992.
[TA08] Tom Tullis, Bill Albert: Measuring the User Experience, Collecting,
Analyzing and Presenting Usability Metrics, Morgan Kaufmann, 2008.
[WWD07] Sebastian Winter, Stefan Wagner, Florian Deissenboeck: A Comprehensive
Model of Usability, http://wwwbroy.in.tum.de/~deissenb/publications/
2007_winters_usability.pdf, 2007.