Internetökonomie und Hybridität

Transkript

1 Prof. Dr. Dieter Ahlert, PD Dr. Detlef Aufderheide, Prof. Dr. Klaus Backhaus, Prof. Dr. Jörg Becker, Prof. Dr. Heinz Lothar Grob, Prof. Dr. Karl-Hans Hartwig, Prof. Dr. Thomas Hoeren, Prof. Dr. Heinz Holling, Prof. Dr. Bernd Holznagel, Prof. Dr. Stefan Klein, Prof. Dr. Thomas Langer, Prof. Dr. Andreas Pfingsten. Internetökonomie und Hybridität Nr. 41 HEINZ HOLLING, PHILIPP ALEXANDER FREUND, JÖRG TOBIAS KUHN, MARTIN SALASCHECK Benutzbarkeit von Software: Wie usable sind Evaluations-Verfahren?

2 European Research Center for Information Systems Gefördert durch: Förderkennzeichen: 01 AK 704 Projektträger: Koordination Internetökonomie und Hybridität Dr. Jan vom Brocke

3 Inhalt 1. Einleitung Zugrunde liegende Methoden und Definitionen Terminologie Usability Grundlegende Formen der Evaluation Evaluationskriterien Methoden der Usability-Evaluation Design-Guidelines Formal-analytische Verfahren Inspektionsmethoden Usability-Tests Fragebogen-Verfahren Vergleich ausgewählter Fragebogenmethoden ISONORM IsoMetrics SUMI und WAMMI QUIS EU-CON II Besonderheiten in unterschiedlichen Kontexten Websites versus lokal installierte Programme Wissensmanagementsysteme Usability-Kriterien von Wissensmanagementsystemen Nutzungsintensität und Vorerfahrung Abschließende Kritik an den Verfahren und Ausblick Empirische Vergleiche von Evaluationsmethoden Kriterien zur Beurteilung von Evaluationsmethoden Evaluationsmodelle für Wissensmanagementsysteme Literaturverzeichnis Arbeitsberichte des Kompetenzzentrums Internetökonomie und Hybridität... 49

4 1. Einleitung Seit über zwei Jahrzehnten findet die Frage nach der Benutzbarkeit bei der Entwicklung von Software immer mehr Beachtung. Während zu Beginn des Computerzeitalters Hardware und Software stets nur auf einen sehr geringen Nutzerkreis ausgerichtet war, der ohnehin speziell geschult wurde, verlangte die immer stärkere Ausrichtung des Computers auf breite Benutzerschichten seit Mitte der 90er Jahre nach immer intuitiveren Systemen, damit auch unerfahrene Anwender als Nutzerschicht erschlossen werden konnten. Zur Bewertung solcher Programme gibt es mittlerweile eine Vielzahl an Theorien, Methoden und Evaluationsverfahren, die im Folgenden besprochen werden. Doch können längst nicht auf alle Computerprogramme dieselben Regeln der Benutzbarkeit angewendet werden. Durch den Einzug des Computers in sämtliche Branchen hat sich auch eine unüberschaubare Vielfalt an Spezialprogrammen entwickelt, die nach wie vor nur für einen eingeschränkten Nutzerkreis gedacht sind. Als Beispiel seien hier Abrechnungsprogramme für Ärzte genannt, bei denen der Benutzer die Fachterminologie beherrschen muss um eine detaillierte Rechnung erstellen zu können. Ein anderes Beispiel sind Videobearbeitungsprogramme, die für Experten auf diesem Gebiet in der Fernsehindustrie programmiert wurden. Die überwältigende Mehrzahl der benutzten Software zielt allerdings auf den Durchschnittsnutzer ab, der die Anwendung ohne Schulung häufig gar ohne Handbuchstudium benutzen können soll. Generell muss bei der Usability- Evaluation also darauf geachtet werden, welchen Zweck das zu bewertende Programm hat, und wer es in welchem Kontext nutzt. Dieser Bericht erläutert zunächst einige den Evaluations-Verfahren zugrunde liegende Methoden, stellt diverse Verfahren einzeln vor und geht dann auf verschiedene Nutzungskontexte ein, insbesondere auf Websites im Allgemeinen und die Domäne der Wissensmanagementplattformen im Speziellen.

5 2. Zugrunde liegende Methoden und Definitionen 2.1. Terminologie Usability Seit 1997 gibt die DIN EN ISO 9241 Richtlinien zur ergonomischen Gestaltung des Arbeitsplatzes. Uns interessieren als Grundlage für diesen Bericht vor allem die sieben Grundsätze der Dialoggestaltung aus Teil 10 sowie die Definition der Gebrauchstauglichkeit aus Teil 11 der ISO 9241: Aufgabenangemessenheit: Ein Dialog ist aufgabenangemessen, wenn er den Nutzer unterstützt, seine Arbeitsaufgabe effektiv und effizient zu erledigen. Selbstbeschreibungsfähigkeit: Ein Dialog ist selbstbeschreibungsfähig, wenn jeder einzelne Dialogschritt durch Rückmeldung des Dialogsystems unmittelbar verständlich ist oder dem Benutzer auf Anfrage erklärt wird. Erwartungskonformität: Ein Dialog ist erwartungskonform, wenn er konsistent ist und den Merkmalen des Benutzers entspricht, z.b. seinen Kenntnissen aus dem Arbeitsgebiet und seiner Erfahrung sowie den allgemein anerkannten Konventionen. Steuerbarkeit: Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist. Individualisierbarkeit: Ein Dialog ist individualisierbar, wenn das Dialogsystem Anpassungen an die Erfordernisse der Arbeitsaufgabe sowie an die individuellen Fähigkeiten des Benutzers zulässt. Lernförderlichkeit: Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen des Dialogsystems unterstützt und anleitet. Fehlertoleranz: Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbarer fehlerhafter Eingaben entweder mit keinem oder minimalem Korrekturaufwand seitens des Benutzers erreicht werden kann.

6 Gebrauchstauglichkeit: Das Ausmaß, in dem ein Produkt durch bestimmte Benutzer in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufrieden stellend zu erreichen o Effektivität: Genauigkeit und Vollständigkeit, mit der ein bestimmtes Ziel erreicht werden kann o Effizienz: Relation von notwendigem Aufwand mit Genauigkeit und Vollständigkeit der Zielerreichung o Zufriedenstellung: Freiheit von Beeinträchtigungen und allgemein positive Einstellung gegenüber dem System Grundlegende Formen der Evaluation Sarodnick und Brau (2006) definieren Evaluation als systematische und möglichst objektive Bewertung eines geplanten, laufenden oder abgeschlossenen Projekts, die Hinweise zur Verbesserung des Projekts ergibt. Im Computerbereich werden meist Kriterien wie Effizienz und Effektivität herangezogen, und eine Evaluation kann sowohl recht generelle Gestaltungsregeln zum Ergebnis haben, als auch spezifische Änderungsvorschläge eines bestimmten Teilaspekts der Software. Unterschieden wird im Allgemeinen zunächst zwischen empirischen und analytischen Evaluationsmethoden: Bei empirischen Methoden sind es tatsächliche Benutzer, die die zu interpretierenden Daten erzeugen, etwa durch Befragungen oder Verhaltens-Beobachtung. Die so gewonnenen Daten müssen analysiert werden um Verbesserungsvorschläge zu generieren: Wie lässt sich ein gefundenes Problem lösen, und ist es überhaupt wichtig? Bei der analytischen Evaluation erzeugen Usability-Experten Bewertungen. Sie bewerten die Software, indem sie sich in die Anwender-Situation hineinversetzen. Dabei ist nicht nur ihr Usability-Wissen unerlässlich, sondern auch Erfahrung in der Anwendungsdomäne von Bedeutung. Durch analytische Methoden gewonnene Daten können dabei helfen Fragen zu beantworten, die bei einer empirischen Evaluation

7 gestellt wurden. Sie haben vor allem in frühen Phasen der Entwicklung Vorteile, da keine funktionsfähigen Prototypen vorliegen müssen. Des Weiteren wird zwischen summativer und formativer Evaluation unterschieden: Eine summative Evaluation wird zu einem späten Stadium der Entwicklung angewendet um ein fertiges oder fast fertiges Produkt zu bewerten. Dabei steht oft eine Gesamtbewertung im Vordergrund, die angibt, wie gut das Produkt im aktuellen Zustand ist. Einzelne Anhaltspunkte zur Verbesserung des Produkts werden hingegen meist nicht geboten; Die Überarbeitung gravierender Design-Fehler ist in dieser Projektphase ohnehin meist nicht ohne erheblichen finanziellen Aufwand möglich. Formative Evaluation findet hingegen vorwiegend enwicklungsbegleitend statt und wird erstmalig in früheren Entwicklungsphasen angewendet. Ihr Ziel ist es konkrete Hinweise zur Verbesserung zu geben (Scriven, 1967) Evaluationskriterien Evaluationskriterien (auch: Evaluationsziele) sind Bewertungsmaßstäbe, an denen das zu evaluierende Programm gemessen wird. An ihnen lassen sich gefundene Ergebnisse sinnvoll interpretieren. Die Maßstäbe sollten dabei im Vorfeld der Evaluation anhand von Aufgabenund Anforderungsanalyse sowie domänenspezifischen Aspekten festgelegt werden. Gediga und Hamborg (2002) nennen folgende Kriterien und Fragestellungen: Which is better? zum Vergleich zweier oder mehrerer Programme, die ähnliche Funktionen haben How good? bewertet werden bestimmte Systemeigenschaften, meist gegen Ende der Entwicklung. Es werden Bewertungskriterien benötigt. Why bad? Diese für die formative Evaluation übliche Fragestellung sucht nach konkreten Verbesserungsvorschlägen.

8 2.2. Methoden der Usability-Evaluation Zur Usability-Evaluation von Software existiert bereits eine Vielzahl etablierter Methoden. Neben solchen, die ausschließlich für fest auf dem Computer installierte Software gedacht sind, gibt es seit einigen Jahren auch eine Reihe von Verfahren; die sich anbieten, wenn es um die Evaluation von Websites geht. Bei der Evaluation von Wissensmanagement-Plattformen im Internet schließlich müssen einige Besonderheiten berücksichtigt werden Im Folgenden wird ein Überblick über eine Reihe von Verfahren zur Evaluation der Gebrauchstauglichkeit gegeben Design-Guidelines Design-Guidelines (dt.: Gestaltungs-Richtlinien) stellen mit ihrem Ursprung in den 70er Jahren (z.b. Ramsey, Atwood & Kirshbaum, 1978) die Wurzeln der heutigen Usability- Evaluation dar. Sie sind eine Liste von Prinzipien, die bei der Gestaltung von Software zu befolgen sind. Dabei unterscheiden sich verschiedene Richtlinien stark in ihrer Breite (z.b. Verstehe und erfülle Nutzererwartungen! und Der Fortschrittsbalken ist in der Farbe Navy zu gestalten, mit einer Abmessung von 30x200 Pixeln. ) Bastien und Scapin (1995) sowie Vanderdonckt (1999) unterscheiden 5 Kategorien von Richtlinien: 1. Gestaltungsregeln: Lose, unstrukturierte Ansammlungen detaillierter Anweisungen (z.b. Menüs sollten einen optischen Eindruck über die Struktur einer Website geben ) 2. Ergonomische Algorithmen: Gestaltungsanforderungen in systematischer Prozedur: z.b. Beschreibung, wie in wissenschaftlichen Veröffentlichungen Texte zu zitieren sind 3. Styleguides: Sehr konkrete Richtlinien/Spezifikationen zur Vereinheitlichung von Systemen eines bestimmten Typs oder Herstellers. (z.b. Hauptüberschriften sind immer in der Schriftart Arial, Punkt 16, Fett zu gestalten. Der Abstand vom linken Bildrand beträgt 120 Punkte) 4. Standards: Anforderungen der Normen, z.b. DIN EN ISO (1997)

9 5. Richtlinien-Sammlungen ( Guidelines ): in inhaltliche Kategorien gebündelte Gestaltungsanforderungen, die für viele Formen von Benutzungsschnittstellen geeignet sind Zwei prominente Beispiele für Guidelines stammen von Smith und Mosier (1986) sowie von Koyani et al. (2001). Die frühe Richtliniensammlung von Smith und Mosier umfasst 944 analytisch entwickelte Guidelines, die in sechs funktionelle Gruppen unterteilt sind (Dateneingabe, Datendarstellung, Kontrolle der Befehlsabfolgen, Nutzerführung, Datenübertragung und Datensicherheit). Trotz ihres Alters können sie zu weiten Teilen noch als aktuell bezeichnet werden (z.b. Feedback über die Komplettierung von Dateneingaben, einfache Satzstrukturen ) Koyanis Research-based Webdesign- und Usability-Guidelines vom National Cancer Institute USA veröffentlicht bestehen aus 185 Items in 17 Kapiteln. Neben Richtlinien zur konkreten Gestaltung finden sich dort auch Hinweise zu Gestaltungsprozessen und zur behindertengerechten Darstellung von Webseiten (z.b. Eliminiere horizontales Scrollen, Stelle zusammenhängende Items in Listen dar ). Durch ihre einfache und kostengünstige Anwendbarkeit finden Guidelines recht häufigen Gebrauch. Obwohl sie durchaus nützlich sind, gibt es eine Reihe an Kritikpunkten zu beachten: Da ein Ziel der Guidelines eine breite Allgemeingültigkeit ist, können sie nicht auf den Nutzungskontext und die Zielgruppe der Anwendung eingehen. Da diese Faktoren jedoch entscheidend für die Gebrauchstauglichkeit sind, sind viele der Richtlinien für die Evaluation von solcher Software schlecht geeignet, die für einen speziellen Anwenderkreis gedacht ist. Die Qualität der Richtlinien stellt eine weitere Hürde dar: Da sich im Internet eine Fülle von Guidelines findet, stellt sich ebenso vermehrt die Frage nach ihrem Ursprung. Selten finden sich Angaben zu theoretischem Hintergrund oder zu gängigen Gütekriterien. Generelle Vorsicht ist bei Guidelines geboten, die nur aus wenigen dutzend Items bestehen.

10 Formal-analytische Verfahren Formal-analytische Methoden (auch formale oder analytische Methoden genannt) können grob unterteilt werden in aufgabenanalytische Verfahren und Expertenleitfäden. Bei diesen Methoden analysieren Usability-Experten die Benutzbarkeit anhand festgelegter Kriterien, ohne auf die spätere Nutzergruppen zu achten. Aufgabenanalytische Verfahren Hinter aufgabenanalytischen Verfahren verbirgt sich die Frage, welche Aufgaben mit dem zu evaluierenden System erfüllt werden sollen. Die Problemstellungen werden in Teilaufgaben bis hin zu konkreten Handlungen aufgeteilt. Dadurch können z.b. Ausführungszeiten objektiv bewertet und Problembereiche identifiziert werden. Blandford, Hyde, Connell und Green (2004) stellen in einer Vergleichsstudie fest, dass sich die aufgedeckten Problematiken in 5 Hauptkategorien gruppieren: Systemgestaltung, Nutzerwissen, konzeptuelle und physikalische Passung zischen Nutzer und System, sowie Themen des Nutzungskontextes. Jedes der 7 untersuchten Verfahren konzentrierte sich dabei jedoch nur auf eine oder zwei dieser Kategorien. Das GOMS-Modell (Goals, Operators, Methods, Selection Rules) ist einer der bekanntesten Modellierungsansätze, die eine formale Beschreibung der Mensch-Computer-Interaktion versuchen und vom Human Processor -Modell abstammen (Card, Moran & Newell, 1983). GOMS geht davon aus, dass Nutzer anstehende Aufgaben in unabhängig voneinander zu erreichende Unteraufgaben aufteilen. Für die Ausführung jeder Unteraufgabe (z.b. Tastendruck, Bewegung der Hand zur Maus) gibt es bestimmte Zeiten vor, die ein typischer Nutzer benötigt. Damit will das Modell a priori Vorhersagen darüber machen, wie lange eine Aufgabe insgesamt dauern wird. Allerdings weisen Olson und Olson (1990) darauf hin, dass wichtige Aspekte nicht berücksichtig werden, wie Ermüdung der Nutzer und Nutzerakzeptanz. Außerdem unterscheiden sich verschiedene Anwender beträchtlich in der Ausführungsgeschwindigkeit, was zu einer starken Unterschätzung der Aufgabendauer führen kann. GOMS ist daher nur auf gut definierte kognitive Aufgaben anwendbar, für die Erfahrungswerte bestehen.

11 Expertenleitfäden Ähnlich wie Guidelines sind auch Expertenleitfäden für Usability-Experten konzipiert, die das System hinsichtlich der Softwareergonomie untersuchen, anstatt gemäß der Aufgabenerfüllung. Die Leitfäden stellen im Allgemeinen eine Sammlung von Fragen oder Aussagen bezüglich der Gestaltung von Benutzerschnittstellen dar. Anders als bei Guidelines ist die Durchführung jedoch streng standardisiert (Oppermann, Murchner, Reiterer & Koch, 1992). Da Expertenleitfäden früh eingesetzt werden, wenig Erfahrung des Evaluators voraussetzen und zeiteffektiv sind, eignen sie sich beispielsweise als Selbstkontrolle der Entwickler während der Programmierung. Usability-Probleme, die sich erst im späteren Anwendungskontext ergeben, werden allerdings häufig nicht erfasst, da wie erwähnt Aufgabenmerkmale nur eine untergeordnete Rolle spielen. Expertenleitfäden haben in den vergangenen Jahren an Bedeutung verloren, da Prozess- und Aufgabenangemessenheit verstärkt betrachtet werden. Der im deutschsprachigen Raum bekannteste Expertenleitfaden ist EVADIS II (Oppermann et al., 1992). EVADIS Ziel von EVADIS ist die software-ergonomische Bewertung der Mensch-Computer- Schnittstelle für den Büro-Bereich, außerdem wird mit der zweiten Version dieses Expertenleitfadens eine Bewertung der Gebrauchstauglichkeit ermöglicht. Aspekte der Funktionalität, Organisation und ihre Passung zueinander werden betrachtet. EVADIS wurde für Experten entwickelt, die über notwendige Kenntnisse um die Entwicklung gebrauchstauglicher Software verfügen und das zu bewertende System detailliert kennen. Das zeitaufwändige Verfahren bedient sich einer Methodenkombination: Den Hauptteil bildet eine Prüffragensammlung, anhand derer Funktionalitäten und ihre ergonomische Qualität bewertet werden. Daran schließt sich eine Benutzerbefragung an, die solche Benutzermerkmale erfasst, die für die Bewertung sinnvoll sind. Mithilfe der Arbeitsanalyse und der Ergebnisse der Benutzerbefragung wird der Schwerpunkt bei der Systemevaluation festgelegt und eine geeignete Prüfaufgabe erstellt. Das Ergebnis der Evaluation mit EVADIS ist ein standardisierter Prüfbericht, der aus den Mittelwerten der Bewertungen von Systemkomponenten und generellen ergonomischen Kriterien zusammengesetzt ist. Die Kriterien der Systemevaluation sind dabei an die Kriterien der DIN EN ISO angelehnt. Hauptkritikpunkt am EVADIS II-Verfahren stellt die mangelnde Standardisierung dar: Die Prüffragen entstammen hauptsächlich Literaturstudien und eigenen Erfahrungen der Autoren;

12 trotz des fundierten theoretischen Rahmens werden keinerlei Angaben über testtheoretische Kennwerte gemacht. Die Notenvergabe durch die Evaluatoren geschieht subjektiv, somit sind Vergleiche zwischen Systemen nur dann möglich, wenn vom selben Evaluator durchgeführt. Außerdem wurde das Verfahren seit 1991 nicht mehr aktualisiert, sodass der Bezug zu vielen aktuellen Problemdomänen fehlt zur Evaluation von Websites beispielsweise ist EVADIS nicht geeignet. Kritik Die Qualität einer Evaluation mit formal-analytischen Verfahren hängt in hohem Maße von der Expertise des Evaluators ab. Er benötigt nicht nur eingehende Erfahrungen im Usability- Bereich und im Umgang mit dem verwendeten Verfahren, sondern muss alle Aspekte der dem System zugrunde liegenden Aufgabenstruktur verstehen und bewerten können. Durch den hohen Zeitaufwand der Methoden scheint die Verwendung formal-analytischer Verfahren jedoch gerade bei sehr komplexen Systemen angezeigt, bei denen die Aufgabenerfassung und -beschreibung wiederum sehr aufwändig ist. Hier tritt die Frage der Kosten-Nutzen-Rechnung in den Vordergrund. Positiv an den genannten Verfahren ist, dass man mit ihnen schon vor der eigentlichen Implementierung in die Software Mängel in der Gebrauchstauglichkeit aufdecken kann Inspektionsmethoden Inspektionsmethoden versuchen potentielle Usability-Probleme im System zu entdecken und konkrete Hinweise zur Verbesserung zu geben. Sie werden somit hauptsächlich zur formativen Evaluation während des Entwicklungsprozesses verwendet; es handelt sich um eine nicht-empirische Vorgehensweise. Inspektionsverfahren sind recht jung: Der Begriff wurde erstmals 1994 von Nielsen und Mack verwendet. Lavery et al. (1997) unterscheiden zwei Typen von Inspektionsmethoden: Design-Prinzipien: Heuristische Hinweise, welche Eigenschaften interaktive Systeme idealerweise haben sollten. Die verwendeten Kategorien sind meist breit und wenig spezifisch, somit wird der Evaluator dazu animiert, einzelne Verstöße gegen die Prinzipien

13 aufzudecken. Hohe Usability-Expertise beim Durchführenden wird vorausgesetzt. Das Vorgehen ist Bottom-Up, da Detailverbesserungen positive Auswirkungen auf die Bearbeitung der globalen Aufgabe haben sollen. Design-Aufgabenanalysen: Sie besitzen Ähnlichkeit zur Modellbildung der Aufgabenanalysen bei der formal-analytischen Evaluation. Hier folgen die Evaluatoren allerdings einer Reihe von Bearbeitungsschritten in dem zu evaluierenden System, die für die Erfüllung von Aufgaben notwendig sind. Potenziell kritische Punkte in der Interaktion sollen gefunden werden, fokussiert wird also auf die konkrete Umsetzung statt auf den eigentlichen Ablauf der Verfahrensschritte. Das Verfahren ist Top-Down: Von der globalen Aufgabe (z.b. Grafik freistellen) über Subaufgaben (z.b. verschiedene Ebenen erstellen) bis hin zu einzelnen Behandlungsschritten (verschiedene Teile der Grafik mit der Maus markieren). Heuristische Evaluation Die Heuristische Evaluation ist ein Sonderfall des strukturierten Expertenurteils. Ein Bewerter orientiert sich an einer Reihe von Heuristiken, bei deren Nicht-Einhalten sich Usability- Probleme ergeben können. Ziel ist es, die aufgedeckten Probleme jeweils einer Heuristik zuordnen zu können um ein zugrunde liegendes Problem zu identifizieren. Sowohl die Cognitive Walkthrough-Methode als auch Expertenurteile erfordern gute Kenntnisse über Nutzer und Aufgabenanforderungen. Nielsen (1994) schlägt folgende Regeln zur Beachtung vor (deutsche Übersetzung von Klemmert, Brau & Marzi, 2001): 1. Sichtbarkeit des Systemstatus: Das System sollte den Nutzer immer informieren, was gerade vorgeht, durch geeignetes Feedback innerhalb angemessener Zeit. 2. Übereinstimmung zwischen System und realer Welt: Das System soll die Sprache des Nutzers sprechen, mit Wörtern, Formulierungen und Konzepten, die dem Nutzer vertraut sind, nicht mit systemorientierten Begriffen. Folge Konventionen aus der Realität, sodass Informationen in natürlicher und logischer Reihenfolge erscheinen. 3. Benutzerkontrolle und Freiheit: Nutzer wählen Softwarefunktionen oft versehentlich. Sie brauchen einen klar markierten Notausgang, um einen

14 unabsichtlich erreichten Zustand verlassen zu können, ohne durch einen ausgedehnten Dialog hindurch zu müssen. Unterstütze Undo und Redo. 4. Konsistenz und Standards: Die Nutzer sollten nicht überlegen müssen, ob verschiedene Begriffe, Situationen oder Aktionen dasselbe bedeuten. Folge Plattform-Konventionen. 5. Fehler vermeiden: Besser noch als gute Fehlermeldungen ist ein sorgfältiges Design, das verhindert, dass überhaupt erst Probleme auftreten. 6. Erkennen vor Erinnern: Mache Objekte, Aktionen und Optionen sichtbar. Der Nutzer sollte nicht gezwungen werden, sich Informationen aus einem Teil eines Dialogs für einen anderen Teil zu merken. Anleitungen zur Benutzung des Systems sollten sichtbar oder leicht auffindbar sein, wann immer angemessen. 7. Flexibilität und effiziente Nutzung: Beschleunigungsmöglichkeiten, die der ungeübte Nutzer nicht sieht, können für erfahrene Nutzer die Interaktionsgeschwindigkeit erhöhen, sodass das System sowohl für Neulinge als auch für Experten geeignet ist. Erlaube Nutzern, häufige Aktionen auf ihre Bedürfnisse zuzuschneiden. 8. Ästhetisches und minimalistisches Design: Dialoge sollten keine Information enthalten, die irrelevant ist oder selten benötigt wird. Jedes Extra an Information in einem Dialog konkurriert mit relevanten Informationen und vermindert deren relative Sichtbarkeit. 9. Unterstützung beim Erkennen, Verstehen und Bearbeiten von Fehlern: Fehlermeldungen sollen in klarer Sprache (keine Kodierungen) gegeben werden. Sie sollen das Problem genau beschreiben und konstruktiv eine Lösung vorschlagen. 10. Hilfe und Dokumentation: Obwohl es besser ist, wenn das System ohne Dokumentation benutzt werden kann, kann es nötig sein, Hilfe und Information mitzugeben. Jede solche Information sollte leicht zu durchsuchen sein, die Aufgaben des Nutzers in den Mittelpunkt stellen und konkrete Schritte zur Ausführung nennen. Die Dokumentation sollte nicht zu umfangreich sein. Seit Veröffentlichung dieser Prinzipien wurde eine Vielzahl alternativer Sets von Heuristiken entwickelt: Nielsen (1997) weist darauf hin, dass die Heuristiken je nach Belang der vorliegenden Wissens- oder Einsatzdomänen der zu evaluierenden Software erweitert und modifiziert werden können, wenn dadurch eine Verbesserung der qualitativen und/oder

15 quantitativen Effektivität der Evaluation erwartet werden kann. In der Tat erscheinen Nielsens Heuristiken heute vielfach nicht mehr zeitgemäß, da im letzten Jahrzehnt weitere Aspekte der Benutzung in den Vordergrund getreten sind und auch die rapide weiterentwickelten technischen Möglichkeiten nicht berücksichtigt werden können. Sarodnick und Brau (2006) schlagen einen neuen Satz Heuristiken, basierend auf der DIN EN ISO und Erfahrungen aus Evaluationsprojekten vor, der bewährte Heuristiken mit neueren Forschungsergebnissen und technischen Entwicklungen zu integrieren versucht. Da eine detaillierte theoretische Begründung und Erfahrungen fehlen, bleibt abzuwarten als wie wertvoll diese Heuristiken gegenüber den etablierten Sets anzusehen sind: 1. Aufgabenangemessenheit: Alle benötigten Funktionen für anstehende Aufgaben im System müssen vorhanden und hinreichend so gestaltet sein, dass sie den Nutzer unterstützen und bei Routineaufgaben entlasten. 2. Prozessangemessenheit: Das System sollte für die Erfüllung realer Arbeitsaufgaben in typischen Einsatzfeldern optimiert sein, einen Bezug zum übergeordneten realen Prozessziel haben und auf Qualifikationen und Erfahrungen der realen Nutzer abgestimmt sein. 3. Selbstbeschreibungsfähigkeit: einheitliche und unmittelbare Anzeige des Systemstatus. Der Benutzer sollte die Detaillierung der Information über den Systemstatus selbst bestimmen können. 4. Steuerbarkeit: beinhaltet die Kontrolle des Nutzers über den Dialog, sowie die Möglichkeit, verschiedene Eingabehilfen zu nutzen oder das System ohne Datenverlust zu beenden 5. Erwartungskonformität: Die Informationsdarstellung sollte systemimmanent und mit plattformspezifischen Konzepten konsistent sein. Bei ähnlichen Aufgaben sollten Dialoge vergleichbar und an erwarteter Position dargestellt sein. 6. Fehlertoleranz: Fehlermeldungen sollten deutlich sein und Hinweise beispielsweise über Art und Handlungszusammenhang enthalten. Der Nutzer muss über irreversible Handlungen informiert werden. 7. System- und Datensicherheit: Das System sollte auch bei fehlerhaften Eingaben des Nutzers und unter hoher Ressourcenbelastung stabil und ohne Datenverluste arbeiten.

16 8. Individualisierbarkeit: Das Dialogsystem sollte sich individuell an die Präferenzen der Nutzer anpassen lassen, solange dies der Effektivität, Effizienz und Zufriedenstellung dient und nicht im Widerspruch zu notwendigen technischen oder sicherheitsrelevanten Begrenzungen steht. 9. Lernförderlichkeit: Lernstrategien wie Learning by Doing sollten durch schrittweise Anleitungen oder Navigationshilfen unterstützt werden. 10. Wahrnehmungssteuerung: Das Layout sollte minimalistisch gehalten werden. Gruppierungen, Farbgestaltung und sinnvolle Informationsreduktion etc. sollten so verwendet werden, dass die Aufmerksamkeit des Nutzers hin zu relevanter Information gelenkt wird. 11. Joy of use: Arbeitsabläufe und grafische Gestaltung des Systems sollten bei notwendiger Konsistenz Monotonie vermeiden und zeitgemäß wirken. Metaphern sollten adäquat und auf den Nutzungskontext abgestimmt verwendet werden. 12. Interkulturelle Aspekte: Das System sollte auf einen definierten Nutzerkreis und dessen funktionale, organisatorische und nationale Kultur abgestimmt sein. Walkthrough-Methoden Beim klassischen Walkthrough werden dem Beurteiler Bildschirmansichten präsentiert, die der Benutzer zum Ausführen einer Funktion benötigt. Die Teilnehmer bewerten aus User- Sicht, wie das Programm zu bedienen wäre und geben Bewertungen anhand festgelegter Kriterien ab. Da keine lauffähigen Prototypen gebraucht werden (die Bildschirmansichten bestehen meist aus Screenshots oder Mockup-Screens), können Walkthroughs schon in sehr frühen Entwicklungsstadien eingesetzt werden. Es reicht aus, wenn Aufgabenabläufe so weit feststehen, dass Evaluatoren sie schrittweise bearbeiten können. Virzi et al. (1996) zeigten, dass durch die Evaluation anhand von Screenshots ebenso viele Probleme gefunden werden wie bei der Evaluation am realem System. Da Walkthrough- Methoden zeitaufwändig sind, findet die Evaluation häufig in Gruppen statt um die Effektivität zu steigern (Bias, 1994). Cognitive Walkthrough Der Cognitive Walkthrough (CWT; Lewis et al., 1990; Polson et al., 1992) ist der am weitesten verbreitete Typ der Walkthrough-Verfahren. Er stellt die Frage, ob sich unerfahrene

17 Benutzer schnell im System zurechtfinden. Daher wird vor der Evaluation für jede Aufgabe eine Ideallösung entwickelt, die in einer Gruppe von Usability-Experten gemeinsam analysiert werden soll. Ziel ist es vorauszusagen, ob spätere User von sich aus genauso vorgehen würden. Informationen über die Kenntnisse und Fähigkeiten der Nutzerschicht fließen dabei mit ein. Bei einem negativen Ergebnis werden Alternativlösungen erarbeitet um Optimierungshinweise zu geben. Der CWT achtet im Gegensatz zur breiten heuristischen Evaluation nur auf den Aspekt Erlernbarkeit der DIN EN ISO Hier zeigt sich die Herkunft des Verfahrens, die Kognitionsforschung: Breite Übereinstimmung herrscht darin, dass exploratives Lernen besonders effektiv ist (z.b. Anderson, 1987). Außerdem konnte gezeigt werden, dass Anwender ein System weniger gerne anhand von Manualen erlernen als es selbst explorativ zu ergründen. Zur Vorbereitung des CWT müssen zunächst detaillierte Annahmen über die Nutzer gemacht, dann die zu analysierenden Aufgaben sorgfältig (möglichst repräsentativ für alle zu erfüllenden Aufgaben) ausgewählt und sehr detailliert beschrieben werden. Anschließend wird die Ideallösung erstellt. (Problematisch: Oft gibt es mehrere Ideallösungen, oder verschiedene Nutzer bevorzugen verschiedene Lösungen) In der Analysephase schätzen die Experten ein, ob ein Nutzer die Aufgabe (ideal) lösen würde. Polson und Lewis (1990) geben mit ihrer Theorie des explorativen Lernens eine Hilfestellung, aus der sich vier Leitfragen für die Evaluatoren ergeben: 1. Wird der Benutzer versuchen, den richtigen Effekt an dieser Stelle auszulösen? 2. Wird der Benutzer bemerken, ob die korrekte Handlung auch verfügbar ist? 3. Wird der Benutzer die korrekte Handlung auch mit dem erzeugten Effekt assoziieren können? 4. Wenn die korrekte Handlung durchgeführt wird, kann der Benutzer den Erfolg in Richtung Aufgabenlösung auch sehen? Pluralistischer Usability Walkthrough (PUW) Der PUW hat keine zugrunde liegende Theorie, sondern wurde entwickelt, als unter Zeitdruck Usability-Daten von Usern und Usability-Professionals erhoben werden sollten (Bias, 1994). Grundlage für die Bewertung stellen wiederum meist Bildschirmansichten des Systems dar.

18 Wie beim CWT werden auch hier im Vorhinein Ideallösungen erstellt, allerdings durch Produktdesigner. Bei der Durchführung erhalten die Evaluatoren zunächst einen Überblick über das System durch einen Produktexperten. Bei der anschließenden Evaluation beschreiben die Evaluatoren (Usability-Experten und reale Benutzer) dann genau, was sie wo anklicken würden um ein (Zwischen-)Ziel zu erreichen. Erst danach erklärt der Versuchsleiter die Ideallösung. Als nächstes diskutieren die Bewerter ihre Lösungen. Die Usability-Experten geben dabei zum einen konkrete Gestaltungshinweise, fungieren aber zum anderen auch als Bindeglied zwischen Benutzern (die ihre Eindrücke und Kritikpunkte möglicherweise schlecht verbalisieren können) und Entwicklern. Insgesamt beweist der PUW relativ hohe Effizienz (Bias, 1994), und es wird von synergetischen Effekten berichtet. Leider fehlt es bis dato an methodisch hochwertigen Replikationsstudien. Grenzen sind dem PUW unter anderem durch die Komplexität gesetzt: Das Verfahren eignet sich für Domänen bis mäßiger Komplexität. Des Weiteren ist sicherzustellen, dass sich alle beteiligten Gruppen ihrer Rolle bei der Evaluation klar sind um eine strikt konstruktive Diskussion zu ermöglichen Usability-Tests Beim Usability- oder Benutzbarkeitstest arbeiten Nutzer am realen System, während sie von Usability-Experten beobachtet werden. Während frühere Usability-Tests meist als Experiment im klassischen testtheoretischen Sinne durchgeführt wurde, hat sich seit einiger Zeit die Durchführung mit weicheren verhaltens- und meinungsbasierten Methoden durchgesetzt (Gediga & Hamborg, 2002). Beim Usability-Test werden anhand verschiedener Verfahren (Beobachtungen, lautes Denken, Interviews nach dem Test, Zeitmessungen während der Aufgabenbearbeitung) Daten zu Problembereichen gewonnen und Verbesserungsvorschläge erarbeitet. Die Methode kann sowohl auf Prototypen im Usability-Engineering-Prozess angewendet werden, als auch zur Evaluation eines finalen Produkts.

19 Grundlagen des Usability-Testings Je nachdem, ob der Usability-Test zur summativen oder formativen Evaluation eingesetzt werden soll, unterscheidet sich die Vorgehensweise und die Zielsetzung. Während induktive Tests der formativen Evaluation dienen (und somit Gestaltungsvorschläge für die weitere Entwicklung von Prototypen gegeben werden sollen), können bei deduktiven Tests zur summativen Evaluation auch mehrere Alternativen miteinander verglichen oder eine fertige Software hinsichtlich ihrer Leistungsfähigkeit bewertet werden. Während induktive Tests vorzugsweise im realen Arbeitsumfeld durchgeführt werden (z.b. um relevante Störvariablen mit zu erheben), sind bei deduktiven Tests Laboruntersuchungen angezeigt um eine Vergleichbarkeit zwischen den Verfahren gewährleisten zu können. Bei allen Usability-Tests werden vorher erstellte Arbeitsaufgaben durch Nutzer bearbeitet, während ein Experte als Beobachter fungiert. Zu beachten ist, dass auch bei induktiven Tests die gesamte für die Aufgabenbearbeitung erforderliche Funktionalität gegeben sein muss um sinnvolle Ergebnisse zu erhalten, da bei der Bearbeitung ansonsten Probleme entstehen können, die beim realen Produkt nicht auftreten würden. Außerdem müssen die Testaufgaben einer realistischen Arbeitssituation möglichst nahe kommen. Damit einher geht, dass auch die Versuchspersonen möglichst repräsentativ für die spätere Anwendergruppe sein müssen. Diese Voraussetzungen bedingen zwar, dass Usability-Tests nicht in ähnlich frühen Stadien durchführbar sind wie solche Evaluationsverfahren, die anhand von Screenshots oder Mockup-Screens durchgeführt werden können. Eine Durchführung in recht frühen Stadien ist trotzdem möglich, indem auf Prototypen zurückgegriffen wird, die nur einen kleinen Teil des endgültigen Systems abbilden. Eine möglichst frühe Durchführung ist auch deshalb sinnvoll, weil es den Nutzern in frühen Entwicklungsstadien leichter fällt grundlegende Kritik zu äußern als bei nahezu fertigen Systemen. Diese wiederum geben meist einen realistischeren Eindruck des Endprodukts (Rosson & Carroll, 2002). Eine weitere Frage besteht in der erforderlichen Anzahl von Versuchspersonen: Während viele Artikel darauf hinweisen, dass bereits mit etwa fünf Versuchspersonen rund 80% der Usability-Probleme aufgedeckt werden (z.b. Nielsen, 1993; Virzi, 1992), weist Faulkner (2003) auf Probleme dieser Faustregel hin. So beträgt die Standardabweichung bei den durchschnittlich gefundenen Problemen bei Gruppen von 5 Testern 9.30 (bei im Mittel und minimal 55 Prozent gefundenen Problemen). Bei 10 Testpersonen beträgt die Standardabweichung immer noch 3.22 (Mittelwert 94.69, Minimum 82). Während in frühen

20 Entwicklungsstadien typischer Anwendersoftware eine Aufdeckungsrate von 80% durchaus genügen mag, ist dieser Prozentsatz bei sicherheitsrelevanten Systemen inakzeptabel. Methoden des Usability-Testings In der Regel werden beim Usability-Test Versuchspersonen bei der Arbeit mit einer für sie relevanten Software mit einer oder mehreren Kameras gefilmt und von einem Usability- Experten beobachtet. Neben dem Bildschirminhalt wird dabei häufig auch die Versuchsperson selbst abgelichtet. Da die Versuchsperson beim Usability-Testing mit einem lauffähigen Prototyp interagiert, kann das das Verfahren erst relativ spät im Entwicklungsprozess eingesetzt werden. Folgende Ansätze finden üblicherweise Gebrauch (Fragebogenmethoden werden im nächsten Abschnitt separat besprochen): Videofeedback: Hier werden der Testperson nach der Aufgabenbearbeitung anhand von Videoaufzeichnungen Fragen zur Bearbeitung gestellt, oder der Testteilnehmer erläutert sein Handeln anhand des Videos. Im Vergleich zum einfachen Interview erhöht sich die Testdauer erheblich, jedoch kann sich die Testperson besser in die Situation zurückversetzen (Nielsen, 1993). Eingabeprotokolle: Verfahren, die neben Bilddaten auch detaillierte Log-Files erstellen, werden selten eingesetzt. Zwar haben sich die technischen Voraussetzungen seit Einführung von Harrisons bekanntem VANNA-System 1991 erheblich verändert. Die Auswertung der großen Datenmengen ist jedoch nach wie vor sehr komplex und zeitaufwändig, sodass Dumas und Redishs Einschätzung des Verfahrens (1999) als one of the most talked about but unused measures of performance wohl noch heute zutrifft. Eye-Tracking-Verfahren: Da Anwender häufig binnen weniger Sekunden ein festes Urteil über eine Software (insbesondere über Websites) bilden, ist das Eye-Tracking- Verfahren ein äußerst effektives Mittel um die Aufmerksamkeit eines Probanden zu analysieren und Software dahingehend zu optimieren, dass das Interesse auf wichtige Aspekte gelenkt wird. Ähnlich wie beim Umgang mit Eingabeprotokollen ist das Verfahren jedoch sehr aufwändig und wird daher selten genutzt.

21 Lautes Denken: Die Methode ermöglicht Einblicke in die mentalen Prozesse eines Probanden, indem die Versuchsperson vor, nach oder (üblicherweise) während der Ausführung einer Handlung seine Gedanken verbalisiert. Die dabei gewonnenen Daten sind in der Regel qualitativ hochwertig, sodass schon die Durchführung mit wenigen Versuchspersonen sehr hilfreich sein kann (Bowers & Snyder, 1990). Nachteile des Laut-Denken-Ansatzes sind u. a. die kognitive Doppelbelastung der Testpersonen und die sich daraus ergebene Unverträglichkeit mit Performance- Messungen. Des Weiteren kann angenommen werden, dass durch das langsamere und überlegtere Vorgehen manche Probleme nicht entstehen, die beim intuitiven Agieren mit der Software auftreten. Remote-Usability-Testing: Bei dieser Form des Usability-Tests werden die Evaluationsdaten nicht im Usability-Labor, sondern meist am persönlichen Rechner des Benutzers erhoben. Im Gegensatz zu seinen Wurzeln wird das Verfahren heute am häufigsten zur Evaluation von Websites eingesetzt, ohne dass der Nutzer sich dessen bewusst ist: Ähnlich wie bei Eingabeprotokollen (wenn auch weniger detailliert), zeichnet eine Serversoftware etwa auf, wie lange ein Benutzer auf einer Seite verweilt, wie oft welche Links angeklickt werden und wie häufig ein Nutzer eine Seite besucht. Unseres Wissens wurde diese Methode bisher jedoch nicht ausreichend auf ihre Nützlichkeit hin untersucht. Des Weiteren werden wiederholt Bedenken von Datenschützern geäußert, da (ungewusst und ungewollt vom Benutzer) komplexe Nutzungsprofile erstellt werden können Fragebogen-Verfahren Bei der Fragebogen-Methode werden Nutzer zu verschiedenen Aspekten einer Software befragt. Voraussetzung ist meistens, dass die Nutzer das System gut kennen. Da Fragebogen fast immer quantitative Daten erheben, kann man mit ihnen besonders gut verschiedene Systeme oder Systemversionen vergleichen. Da sie kostengünstig sind und ihre Durchführung meist nicht sehr lange dauert, werden sie aber auch häufig eingesetzt, wenn Mittel für aufwändigere Verfahren fehlen oder es nicht möglich ist Nutzer eines Systems längere Zeit für eine Usability-Evaluation abzustellen. Die meisten verbreiteten Instrumente liegen

22 inzwischen auch als computergestützte Version vor, die Erhebung und Auswertung weiter vereinfachen können. Ein qualitativ hochwertiger Fragebogen zeichnet sich neben der ökonomischen Anwendung durch die drei Haupt-Gütekriterien aus (vgl. z.b. Bortz & Döring, 1995): Objektivität: Sind die Ergebnisse des Fragebogens unabhängig von den Rahmenbedingungen der Durchführung (z.b. räumliche Bedingungen, Versuchsleiter)? Reliabilität: Ist der Test frei von Zufallsfehlern? D.h. ergibt der Fragebogen bei gleichen Versuchsbedingungen stets (annähernd) gleiche Ergebnisse? Validität: Misst der Fragebogen, was er messen soll? Die Konstruktion von Fragebogen, die die Gütekriterien erfüllen, ist daher sehr aufwändig und eine projektspezifische Erstellung demzufolge selten möglich. Für eine aussagekräftige Evaluation muss jedoch davon abgesehen werden auf gut Glück einen Fragebogen für ein bestimmtes System mit selbst erdachten oder anderweitig zusammengestellten Fragen zu formulieren, da davon ausgegangen werden muss, dass die oben genannten Gütekriterien dabei nicht erfüllt werden. Die Aussagekraft der Ergebnisse kann insofern nicht bestimmt werden, eine Vergleichbarkeit mit etablierten Verfahren ist ebenfalls nicht gegeben. In den vergangenen Jahren ist die Zahl wissenschaftlich erarbeiteter und standardisierter Fragebogen zur Usability-Evaluation stark angestiegen. Auf dem Markt erhältlich sind sowohl solche Kataloge, die auf besonders viele Software-Systeme anwendbar sind und damit eine möglichst große Vergleichbarkeit ermöglichen, als auch domänenspezifische Fragebogen, die nur einen kleinen Anwendungsbereich adressieren. Wie später noch erörtert wird, ist ein großes Problem der Methode, dass ein sinnvoller Spagat zwischen globaler Aussagekraft und Domänenspezifik nicht immer möglich ist bzw. für eine Vielzahl von Domänen noch keine passenden Fragebogen existieren. Alle vollstandardisierten Verfahren legen das Antwortformat fest (üblicherweise Multiple Choice oder Ratingskalen), teilstandardisierte Verfahren erlauben zusätzlich frei formulierte Antworten. In jedem Falle kann die Auswertung über Mittelwert und Standardabweichungen erfolgen, und es können die Ergebnisse verschiedener Systeme, Systemversionen oder auch Nutzergruppen verglichen werden. Einen Überblick über einige bekannte Fragebogen-Verfahren gibt der folgende Abschnitt.

23 2.3. Vergleich ausgewählter Fragebogenmethoden Wie bereits erwähnt wurde, sind Fragebogenverfahren kostengünstige Alternativen zu aufwändigen Evaluationsverfahren. Sie müssen meist nicht von Usability-Experten durchgeführt werden und erlauben die Untersuchung vieler Nutzer in kurzer Zeit. Da eine Vielzahl an Fragebogen am Markt erhältlich ist, scheint es uns angebracht einen Überblick über diejenigen Verfahren zu geben, die durch hohe Qualität der Gütekriterien und/oder sehr häufige Verwendung auf sich aufmerksam machen. Berücksichtigt werden dabei nur solche Fragebogen, die (auch) in deutscher Sprache vorliegen ISONORM (Prümper & Anft, 1993) basiert auf der ISO DIN EN (Grundsätze der Dialoggestaltung). ISONORM besteht aus 7 Skalen, die den Usability-Kriterien der genannten Norm entsprechen (siehe Abschnitt 2.1.1). Jede Skala enthält 5 Items, die auf einer siebenstufigen Ratingskala ( sehr negativ bis sehr positiv ) beantwortet wird. Ein weiterer Fragebogenteil beschäftigt sich mit vorwiegend demographischen Themen. Die Durchführung erfordert rund 15 Minuten. In einer Langversion wird außerdem nach der Wichtigkeit der Dimension für die auszuführende Tätigkeit gefragt und bei Verletzung der Kriterien darum gebeten ein Beispiel zu geben. Es liegt außerdem eine Online-Version vor. ISONORM soll erste Hinweise auf ergonomische Schwachstellen geben (Prümper & Anft, 1993). Da die Fragen allgemein formuliert sind, muss der Fragebogen mit weiteren Verfahren kombiniert werden um konkrete Hinweise auf Mängel und zur Verbesserung des Systems zu erhalten. Eine Normierung durch Prümper erfolgte Die Autoren verlangen, dass ein Beurteiler das Programm sehr gut kennen sollte (tägliche Nutzung über Monate hinweg). Somit eignet sich das Verfahren wohl nur in seltenen Fällen zur Evaluation von Prototypen. Die ermittelten Reliabilitäten (Prümper, 1997) von 0.59 bis 0.89 (MW t2 t1 = 6.7) sind nur teilweise als gut anzusehen. Zur Validierung des Verfahrens wurden die Gesamtscores zwei anderer Usability-Fragebogen herangezogen, die keinen Bezug zu ISO aufweisen. Die Korrelationen betrugen r = 0.71 und r = Außerdem wurden die Ergebnisse von ISONORM und des EVADIS II-Verfahrens (s. o.) miteinander verglichen. Leider wurde die Validität der einzelnen Dimensionen nicht überprüft.

24 Tabelle 1: Beispiel-Items zur Selbstbeschreibungsfähigkeit (aus Prümper & Anft, 1993). Ist die Software so gestaltet, daß Sie sich ohne großen Aufwand in sie einarbeiten konnten und bietet sie auch dann Unterstützung, wenn Sie neue Funktionen lernen möchten? Die Software / Die Software... erfordert viel Zeit zum Erlernen. erfordert wenig Zeit zum Erlernen. ermutigt nicht dazu, auch neue Funktionen auszuprobieren. ermutigt dazu, auch neue Funktionen auszuprobieren IsoMetrics Wie ISONORM orientiert sich IsoMetrics (zusammenfassend siehe Gediga & Hamborg, 1999) ebenfalls an Teil 10 der ISO 9241 und enthält ebenfalls sieben Skalen zu den in der Norm formulierten Kriterien. Mit 75 fünffach gestuften Items ( unwichtig bis wichtig, sowie Antwortmöglichkeit keine Meinung ) ist der Fragebogen in der aktuellen Version 2.01 noch immer recht umfangreich (bis Version 2: 90 Items). Eine für die formative Evaluation gedachte Langversion enthält zusätzlich ein Feld zur Antwortbegründung nach jeder Frage sowie eine Einschätzung der Wichtigkeit dieses Aspekts. IsoMetrics eignet sich daher in der Lang-Version auch für Software-Prototypen da das Verfahren in zwei der Dimensionen aufeinander folgende Versionen unterscheiden kann sowie für Evaluationen, bei denen der Proband die Software erst beim Testen kennenlernt. Die Durchführung dauert in der Langversion jedoch sehr lange berichtet Hamborg über hohe Effektivität und Effizienz des Verfahrens im Vergleich zu Usability-Testing- und Inspektionsmethoden, allerdings fehlt eine Gegenüberstellung mit anderen Fragebogen-Methoden. Wie Ollermann (2004) anmerkt, berücksichtigt die Validierung des IsoMetrics insbesondere die unterschiedlichen Fragebogen-Dimensionen. Das Verfahren basiere ferner jedoch

25 weitgehend auf Plausibilitätsannahmen. Insgesamt kann IsoMetrics jedoch als gut validiert und mit ermittelten Reliabilitäten zwischen 0.69 und 0.86 als reliabel bezeichnet werden. Tabelle 2: Beispiel-Items zur Steuerbarkeit des IsoMetrics Steuerbarkeit Es ist für mich einfach, zwischen unterschiedlichen Bearbeitungsbildschirmen zu wechseln. Mit der Software ist für mich ein einfaches Bewegen zwischen den unterschiedlichen Menüebenen möglich. Es besteht jederzeit die Möglichkeit, bei einer Befehlseingabe abzubrechen. stimmt nicht stimmt sehr Keine Angabe SUMI und WAMMI Das SUMI (Software Usability Measurement Inventory; Porteous, Kirakowski & Corbett, 1993) umfasst 5 Skalen mit insgesamt 50 Items, die die subjektiv wahrgenommene Usability erfassen und mit Zustimmung, Unentschlossenheit oder Ablehnung beantwortet werden können. Eine Global -Skala enthält die 25 am stärksten auf einem allgemeinen Usability- Faktor ladenden Items. Durch die Skala Affect grenzt sich das SUMI dabei von anderen Instrumenten ab (z. B.: I would not like to use this software every day ). Zwar ist auch das SUMI an ISO 9241 angelehnt, die einzelnen Dimensionen (Affect, Control, Efficiency, Helpfulness und Learnability) sind jedoch eigenständig entwickelt und psychometrisch abgesichert worden. SUMI wurde außerdem fortlaufend an verschiedenen Systemen unterschiedlicher Domänen anhand von über 1000 ausgefüllten Fragebogen standardisiert. Es liegt in den Sprachen Niederländisch, Englisch, Deutsch, Französisch, Griechisch, Italienisch, Spanisch und Schwedisch vor. Der Fragebogen ist ausschließlich in Papierform erhältlich, die Auswertung erfolgt allerdings computergestützt mit dem dazugehörigen Programm SUMISCO.

26 Tabelle 3: Beispiel-Items des SUMI (übersetzt nach Porteous et al., 1993): Item Zustimmung unentschlossen Die Instruktionen und Aufforderungen sind hilfreich. keine Zustimmung Die Software reagiert zu langsam auf Eingaben. Die Art und Weise, auf die das System Informationen darbietet, ist klar und verständlich. Das WAMMI (Website Analysis and Measurement Inventory; Kirakowski & Cierlik, 1998) ist ein weit verbreitetes Instrument zur Erfassung der Usability von Websites und stellt eine spezifische Weiterentwicklung des SUMI dar. In der Kurzversion enthält es 5 Skalen mit insgesamt 20 Items, die in der Benennung den SUMI-Skalen ähneln. Einzig die Skala Affect heißt hier Attractiveness. Die einzelnen Dimensionen wurden ohne Überprüfung der Faktorenstruktur aus dem SUMI übernommen, daher kann nicht beurteilt werden, ob und welche der Items in einer Faktorenanalyse als zusammengehörig erscheinen würden. Die Gesamtreliabilität beträgt 0.96 (Cronbach s Alpha) in der Version 1.1. Tabelle 4: Beispiel-Items des WAMMI (übersetzt nach Kirakowski et al, 1998) Item Diese Website bietet viel, das mich interessiert. Stimme voll zu Keine Zustimmung Diese Website ist zu langsam. Diese Website zu benutzen ist Zeitverschwendung QUIS Das QUIS (Questionnaire for User Interface Satisfaction; Shneiderman, 1987; siehe auch Chin, Diehl & Norman, 1988; Shneiderman & Plaisant, 2005), das aktuell in Version 7 vorliegt, konzentriert sich auf die subjektive Zufriedenheit mit der Software im Allgemeinen (6 Skalen) sowie in Bezug auf spezielle Aspekte (weitere 9 Skalen, u. a. screen factors,

27 technical manuals und software installation ). Verschiedene Themenblöcke können für verschiedene Produkte benutzt werden um den Fragebogen an die Software anzupassen. Harper et al. (1997) berichten über gute Reliabilitätswerte des QUIS-Gesamtscores (Cronbach s Alpha = 0.95), machen jedoch keine Angaben zu Reliabilitäten der einzelnen Skalen. Die Konstruktvalidität überprüften sie mittels Korrelation mit 6 generellen Zufriedenheits-Fragen (r min =0.49, r max =0.61). Ollermann (2004) kritisiert, dass der Zusammenhang des untersuchten Aspekts Gefallen an der Software mit der Gebrauchstauglichkeit unklar bleibt. QUIS 7.0 ist in den Sprachen Englisch, Deutsch, Italienisch, Portugiesisch und Spanisch verfügbar. Tabelle 5: Beispiel-Items der spezifischen Zufriedenheits-Skala (übersetzt nach Shneiderman, 2005): 5.4 Nachrichten, die auf dem Bildschirm erscheinen: verwirrend klar n.b Instruktionen für Befehle oder Auswahlen: verwirrend klar n.b EU-CON II EU-CON II (Stary & Riesenecker-Caba, 1999) ist ein teilstandardisiertes Verfahren zur Umsetzung der EU-Richtlinie 90/270/EWG, die Anforderungen an Bildschirmarbeitsplätze formuliert. Als von der DEKITZ anerkannte Methode soll es methodische und inhaltliche Hilfestellungen zur Umsetzung der Richtlinie und Hinweise zur Verbesserung der Nutzungsschnittstelle im Rahmen einer summativen Evaluation geben. EU-CON II wendet sich explizit auch an Usability-Laien, also z.b. Unternehmen, die Anwendungen ihres Betriebs selbständig evaluieren möchten. Das Vorgehensmodell von EU-CON II besteht aus vier Teilen: 1. Vorbereitung: Hier wird empfohlen, zunächst ein Projektteam zu gründen, Ziele klar zu definieren und die Mitglieder des Projekts (mithilfe eines mitgelieferten Handbuch für Evaluateure und Gestalter ) zu schulen.