Usability Testing - Theorien, Modelle und Methoden der Softwareevaluation

Transkript

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

2 Inhaltsverzeichnis 1 Motivation und Überblick Theorien und Modelle der Softwareevaluation Ein Usability-Referenz-Modell Die Theorie des explorativen Lernens Methoden der Softwareevaluation Analytische Evaluationsmethoden Vorbereitung eines empirischen Usability-Tests Befragungen Ausführungsmetriken Verhaltensmetriken und physiologogische Metriken Fazit Literaturverzeichnis II

3 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

4 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

5 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

6 Kapitel 2: Theorien und Modelle der Softwareevaluation Die logische Nutzerschnittstelle als sichtbarer Teil der Software wird wie folgt aufgebrochen: Logische Nutzerschnittstelle Eingabekanäle Ausgabekanäle 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

7 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: Interaktion mit dem Produkt Ausführung Auswertung Zielbildung Willensbildung Festlegen der Aktion Ausführung der Aktion Wahrnehmung des Umweltzustands Interpretation des Umweltzustands Evaluation des Ergebnisses 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 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

8 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 A 1 ] +/ [Aktivität a ATTRIBUT A 2 ] Hierdurch wird ausgedrückt, dass das Attribut A 1 des Faktes f einen positiven (oder negativen) Einfluss auf das Attribut A 2 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

9 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. Gib dem System meinen Benutzernamen Legende Aktivierungsverbindung erledigt will Hemmende Verbindung unddann erledigt will erledigt will Tippe den Benutzernamen ein Drücke die EINGABE-Taste Abbildung 3: Beispielhafte Zielstruktur mit Und-dann-Sequenz [PLRW92] 9

10 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

11 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 Ziel Aktion 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 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 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 Schritt Eine Zielstruktur, in der zwei oder mehr Unterziele in einer bestimmten Reihenfolge ausgeführt werden müssen (vgl. Beispiel oben). 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23 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

24 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

25 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

26 Literaturverzeichnis [Fr90] [Ha86] [HZ90] [Ni92] Jürgen Friedrichs: Methoden empirischer Sozialforschung, Westdeutscher Verlag, Winfried Hacker: Allgemeine Arbeits- und Ingenieurpsychologie: Verlag Hans Huber, Carl Graf Hoyos, Bernhard Zimolong: Ingenieurpsychologie, Verlag für Psychologie, Jakob Nielsen: Finding Usability Problems Through Heuristic Evaluation, Proceedings of the SIGCHI conference on Human factors in computing systems, S , ACM, [Ni93] Jakob Nielsen.: Usability Engineering, AP Professional [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 , Academic Press, [TA08] Tom Tullis, Bill Albert: Measuring the User Experience, Collecting, Analyzing and Presenting Usability Metrics, Morgan Kaufmann, [WWD07] Sebastian Winter, Stefan Wagner, Florian Deissenboeck: A Comprehensive Model of Usability, _winters_usability.pdf, 2007.