Das Problem
Heutzutage gehört die Usabilityanalyse zum iterativen Designprozess dazu. Man muss ja schließlich wissen, ob das was man sich ausgedacht hat auch bei den Nutzern ankommt. Wenn man seine Schlüsselindikatoren (KPI) analysiert kann man manchmal einschätzen wo der Hase im Pfeffer liegt. Wurde die eigene App oft heruntergeladen, aber auch gleich wieder deinstalliert, dann vermuten wir erstmal ein technisches Problem. Ein Blick in unseren Crashreport zeigt jedoch grünes Licht. Muss das Problem also nicht-technischer Natur sein. Kann es daran liegen, dass die App die Erwartung der Nutzer nicht erfüllt?
Ihr seht: Analytics-Zahlen zu interepretieren ist nicht immer eine genaue Wissenschaft. Hier können wir nur Mutmaßungen anstellen, was das Nutzerverhalten auslöst. Im vorigen Fall haben wir angenommen, dass der Grund für die vielen Deinstallationen eine nicht erfüllte Nutzererwartung ist. Und selbst mit dieser Annahme wissen wir jetzt nicht genau was wir verbessern sollen. Den Beschreibungstext der App? Die Screenshots? Den Namen? Sind die Screens der App evtl mehrdeutig?
Alle Annahmen sind gleichermaßen berechtigt, führen aber zu unterschiedlichen Maßnahmen. Der Beschreibungstext ist schnell geändert. Die Marke will man nur ungern ändern und die Screens der App umzuprogrammieren ist eine Menge Arbeit. Wir brauchen also konkrete Informationen, wo das Problem liegt.
Checken wir die Nutzerkommentare des Appstores. Hier kann man schon mal einen ersten Eindruck erhalten was der Grund sein kann. In unserem Beispiel finden alle die App toll, bis auf einen der sich ärgert, dass er mit dem neuen Design nicht zurechtkommt. Bedeutet das was oder ist das zu vernachlässigen? Wir können nicht wegen einem Kommentar immer alles gleich umändern.
Selbst eine Auswertung durchführen
Wir müssen also das Heft in die Hand nehmen und selbst eine Usabilityauswertung durchführen. Soll nichts kosten und kaum Arbeit machen. Schnell gegoogelt was es da so gibt. Viele Treffer zum Thema „10 Tools um Usability zu messen“. Stellen sich beim Durchlesen als Fragebogentools heraus, die ein, zwei vorgefertigte Fragen zum Thema Usability anbieten. Das macht Sinn den Nutzern nicht viele Fragen zu stellen, ich will ja möglichst viele Antworten. Aber haben die sich die Frage ausgedacht, oder ist das ein validiertes Instrument aus der Forschung und wie kann ich die Antworten nutzen? Wenn ich eigene Fragen stellen will wie sollte ich sie formulieren, damit ich sinnvolle Antworten erhalte?
Als Akademiker habe ich mich damals dafür entschieden alles zum Thema zu lesen was mir relevant erscheint, um entscheiden zu können für welche Problemstelle welche (validierten) Fragen gestellt werden müssen.
Es gibt Tests, die zur Verbesserung (formativ) und welche die zur abschließenden Auswertung (summativ) einer Software genutzt werden. Formative Test werden so lange mit einer kleinen Gruppe von Testern durchgeführt, bis man zufrieden ist (ist man das jemals?). Summative Tests werden nur einmal aber dann gleich mit einer großen Gruppe von Testern durchgeführt. Wir wollen die App verbessern, keine Doktorarbeit schreiben, also interessiert uns ein formativer Test.
Test mit echten Nutzern
Die beste Methode, um herauszufinden woran es hakt ist ein Usability Walkthrough mit echten Nutzern. Also Mitgliedern der Zielgruppe. Wer hier 2 Tage Zeit für einen Test investiert hat später mehr Erfolg. Dafür braucht man keinen Fragebogen, sondern einen Prototyp der Anwendung. Diese Methode kann man sogar in der Planungsphase nutzen. Gerade hier macht es am meisten Sinn, weil man bereits viel Arbeit bei der zielgruppenbewussten Ausrichtung der Software sparen kann. Es reicht ein Prototyp der nur so tut, als wäre er eine App. Ein interaktiver Klickdummy, der echt aussieht. Ist an einem Tag erstellt und wird nach dem Test weggeworfen.
Usability Gurus im Netz wiederholen beharrlich, dass fünf Tester ausreichen, um 90% der schwerwiegendsten Fehler zu finden. Einige wenige Gurus kennen den Ursprung dieses Models: die Arbeiten von Virzi (Virzi 1992), Nielsen (Nielsen 2000) und Landauer (Nielsen und Landauer 1993). Fünf Nutzer zu testen hört sich selbst für einen einzelnen Entwickler auf Wahrheitssuche machbar an. Es gibt zwar Hinweise, dass man mit fünf Testern gerade mal 35% der Fehler findet (Spool und Schroeder 2001), aber für mehr haben wir jetzt keine Zeit. Testen wir also fünf.
Bald werde ich einen Post darüber schreiben, wie man einen solchen Test durchführt, worauf zu achten ist und wie man die Ergebnisse schnellstmöglich verwerten kann. Bevor wir uns jedoch mit Usabilityauswertungen durch Fragebögen befassen musste ich darauf hinweisen, dass ich den Usability Walkthrough für die direkteste und effektivste der formativen Methode halte.
Test mit Fragebögen
Warum dann noch Fragebögen? Wenn man die Zielgruppe nur schwer zu einem Test einladen kann, ein Fragebogen aber ok ist. Wenn man ermitteln will wie sich etwas über einen Zeitverlauf hin verbessert oder verschlechtert hat (Verlaufsbenchmark). Wenn man für kritische Augen nachvollziehbare Ergebnisse braucht, z.B. weil der Chef/Quality Controll das so möchte oder ein Paper geschrieben werden muss. Wenn man zeigen will, dass man besser ist als die Konkurrenz (vergleichender Benchmark).
Uns fallen bestimmt noch viele weitere pragmatische Gründe ein. Der wichtigste Grund, der meines Erachtens für Usabilityfragebögen spricht ist jedoch ein ganz anderer: Verrückterweise wird die wahrgenommene Usability mehr durch die Ästhetik der Nutzeroberfläche beeinflusst, als durch die beobachtbare Usability (Seite 9, Hassenzahl 2010). Also sollte man selbst nach einem Usabilitytest bei dem man Usabilityprobleme beobachtet hat die wahrgenommene Usability abfragen. Dafür gibt es standardisierte Usabilityfragebögen.
Usabilityfragebögen
Es gibt viele, tolle, validierte Werkzeuge. Ich greife mir hier mal exemplarisch ein paar heraus, um sie vorzustellen: QUIS (Chin 1988, Harper et al. 1997), SUS (Brook 1986), IsoMetrics (Gediga 1999) und ISONORM (Prümper 1993, Prümper 2014).
QUIS und SUS haben beide eine ungerade Skala. Eine Skala ist die Bandbreite an Antwortoptionen. Eine ungerade Skala bedeutet, es gibt bei den Antwortoptionen einen Mittelpunkt. Die Experten streiten sich darüber ob das gut oder schlecht ist, auf jeden Fall wird eine ungerade Skala mehr Antworten in der Mitte erhalten, als eine gerade Skala für jede der Mitte nächsten Antwortoptionen (Porst 2014). Hä? Naja, auch nicht verwunderlich. Dann teilen sich die der Mitte nächsten Optionen eben die Anzahl der Antworten, die vorher genau auf die Mitte gefallen wären. Ich persönlich gehe davon aus, dass in jedem Nutzer eine Meinung schlummert. Mit der geraden Skala zwingt man den Nutzer in eine Richtung. Habe ich nur Zeit für eine Frage, stelle ich lieber eine mit einer geraden Skala. Das kann allerdings auch zu verfälschten Ergebnissen führen. Daher haben ungerade Skalen durchaus ihre Berechtigung. Die verwende ich lieber für Fragebögen mit mehreren Fragen.
Porst macht auf einen wesentlich wichtigeren Fallstrick bei ungeraden Skalen aufmerksam (Seite 81, Porst 2014). Die Gefahr droht, wenn der Fragebogen eindimensionale Fragen mit ungerader Skala stellt. Eindimensionale Fragen machen eine Aussage und bitten den Nutzer einzuschätzen wie sehr er dieser Aussage zustimmt („Die Nutzung war kompliziert“ – „Stimme zu…….. Stimme nicht zu“). Bedeutet bei zweidimensionalen Fragen eine Antwort in der Mitte eine Enthaltung („War die Nutzung..“ – „kompliziert…….einfach“), bedeutet bei einer eindimensionalen Frage eine Antwort in der Mitte 50% Zustimmung, also in dem Beispiel stimme ich zu 50% zu, dass die Nutzung kompliziert war. Das ist alles andere als eine Enthaltung. Der SUS macht genau das: ungerade Skalen bei eindimensionalen Fragen.
Kurzer Einschub: Was ist Usability eigentlich?
Usability und was man darunter versteht hat sich in den letzten Jahrzenten geändert. Zuerst wurde Usability als das Zusammenspiel von Effektivität, Effizienz und Zufriedenheit des Nutzers verstanden (ISO 9241-10:1999). Effektivität: wie gut kann man mit der Software das machen, was man will? Wird gemessen in Fehlern, die ein Nutzer während einem Test macht (was zählt als Fehler? Einmal in ein Dokument reinschauen und wieder zurück gehen kann auch aufgrund von Neugierde geschehen sein). Effizienz: wie schnell kann man mit der Software das machen, was man will? Wird gemessen in der Zeit, die man braucht um eine vorgegebene Aufgabe zu lösen. Zufriedenheit: wie sehr ist der Nutzer mit der Software zufrieden? Eine Frage, die der Nutzer nach dem Test in einem Fragebogen beantwortet (Wenn diese Frage nicht standardisiert ist und jeder seine eigene Version davon verfasst, dann sind die Ergebnisse nicht vergleichbar).
Dann wurden mehr Facetten von Usability als relevant zur Beurteilung der Qualität einer Software eingestuft: Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit, Erwartungskonformität, Lernförderlichkeit, Steuerbarkeit, Fehlertoleranz und Individualisierbarkeit (ISO 9241-110:2006).
- Aufgabenangemessenheit: Wie gut bietet die Software das an, was man braucht um das zu erledigen weshalb man die Software nutzen würde?
- Selbstbeschreibungsfähigkeit: Wie sehr ist dem Nutzer bewusst wo er sich gerade in der Software befindet, was er da machen kann und wie er das machen kann?
- Erwartungskonformität: Wie sehr verhält sich die Software so, wie es der Nutzer erwarten würde? (Es so zu machen, wie die anderen kann helfen die Erwartungskonformität zu steigern, ist aber auch langweilig, oder? 😉
- Lernförderlichkeit: Wie gut unterstützt die Software den Nutzer beim Lernen des Umgangs mit der Software?
- Steuerbarkeit: Wie sehr hat der Nutzer die Kontrolle über das System? (Ist es schlimm wenn er wenig Kontrolle hat oder ist es schlimm wenn er das Gefühl hat wenig Kontrolle zu haben?)
- Fehlertoleranz: Wie sehr unterstützt die Software den Nutzer darin Fehler zu vermeiden, zu korrigieren und zu managen?
- Individualisierbarkeit: Wie gut lässt sich die Software an die individuellen Bedürfnisse eines Nutzers anpassen oder passt sich selbst an?
Diese Facetten kann man nicht blind zur Bewertung jeder Software anwenden. Eine Banking App kann einen tollen Dienst machen, ohne dass sie individualisierbar ist, während Individualisierbarkeit in einer Dating App das wichtigste Feature ist.
Zurück zu den Fragebögen
Da sich das Usabilityverständniss geändert hat, ist es also nur bedingt ratsam alte Fragebögen zu verwenden. QUIS und SUS z.B. berücksichtigen nicht die Facetten der Usability, wie im Einschub beschrieben. Der IsoMetrics und ISONORM dagegen schon (daher auch der Name, da die Facetten durch eine ISO Norm beschrieben sind). Beide Fragebögen fördern mehr Usabilityprobleme zu Tage als während einem Nutzertest oder durch eine Einschätzung eines Usabilityexperten (Hamborg 2002).
IsoMetrics und ISONORM verwenden ungerade Skalen von 5 Antwortoptionen und ein zusätzliches Kästchen zum Ankreuzen, wenn man keine Antwort geben kann. Dadurch soll dem Tester die Möglichkeit gegeben werden lieber die Frage nicht zu beantworten, als irgendeinen Mist anzugeben, der uns die Daten verwässert. Wenn vorhanden, wird diese Antwortoption von Testern häufig genutzt (macht die Lösung dann was sie soll, oder zieht sie uns andernfalls valide Daten aus der Umfrage raus?). Porst hat wieder mal einen guten Hinweis für uns: Die Option „Keine Antwort“ führt dazu, dass wir pro Frage eine unterschiedliche Anzahl von Antworten haben können (Porst 2014). Das beeinflusst massiv die Auswertung, denn die Option „Keine Antwort“ ist eben keine Antwort. Haben von 100 Befragten 90 die Option „Keine Antwort“ gewählt, 9 angegeben die App wäre stressig und 1 sie wäre entspannt, dann hat nicht 9% der Befragten angegeben sie wäre stressig, sondern 90%. Das macht einen großen Unterschied.
Wenn die „Keine Antwort“ Option mit einer ungeraden Skala verwendet wird, dann entfallen weniger Antworten auf die Mitte der Skala, selbst wenn es sich um eine eindimensionale Frage handelt, wo die Mitte ja nicht Enthaltung bedeutet (haben wir dadurch die Leute rausgefiltert, die die Frage nicht verstanden haben?). Der IsoMetrics ist genau so aufgebaut (eindimensionale Frage + ungerade Skala + „Keine Antwort“ Option.) Der QUIS hingegen verwendet statt der eindimensionalen Frage zwei entgegengesetzte Poltexte („Ist die Anwendung….“ – „stressig……entspannt“).
Der IsoMetrics (75 Fragen) und der ISONORM (35 Fragen) liefern die gleichen Ergebnisse mit der gleichen Genauigkeit (Figl 2010). Wenn er also genauso gut ist können wir unseren Nutzern Zeit sparen, wenn wir den ISONORM verwenden.
Haben wir damit einen Gewinner? Leider nein. Denn eindimensionale Fragen beeinflussen bereits die Antwort. Wenn ich frage „Diese Software reagiert nur langsam auf Eingaben“ – „Stimme zu…. Stimme nicht zu“ erhalte ich tendenziell negative Antworten (Porst 2014). Aber genau so ist der IsoMetrics und ISONORM aufgebaut.
Auch bei zweidimensionalen Frage kann es eine Verfälschung der Antworten geben, wenn die positiven Antworten immer blind an der selben Stelle abgegeben werden können. Der QUIS wechselt daher die Position der positiven und negativen Antwortoptionen ab. Bei Frage 1 ist eine Antwort auf der rechten Seite positiv, bei Frage 2 ist eine Antwort auf der rechten Seite negativ. Meiner Meinung nach hat man da aus einem kleinen Problem ein größeres gemacht, denn jetzt muss der Tester nach all dem anstrengenden Testablauf auch noch angestrengt nachdenken, was hier wo ist und was er eigentlich sagen will.
Fazit Usability messen
Mir ist kein wissenschaftlich geprüfter Usabilityfragebogen bekannt, der nicht irgendeinen Nachteil hätte. Wie gut etwas ist kann man eben immer nur im Kontext beantworten. Wer nun selbst einen Usabilityfragebogen erstellen will dem rate ich pauschal zu zweidimensionalen Fragen (viele checken das mit dem Mittelpunkt ja nicht). Der Fragetext sollte nicht wertend formuliert sein.
Und was ist jetzt User Experience?
Ein sehr schwammiger Begriff. Man bezeichnet damit sowohl ein Forschungsgebiet, als auch ein messbares Phänomen (z.B. nach einem Nutzertest), als auch etwas Gestaltbares (um damit das Phänomen auszulösen).
Gehen wir strukturiert vor. User Experience ist ein verwandtes Konzept von Usability aber auch etwas eigenes. Ihr erinnert euch an den Einschub von oben mit der kurzen Historie wie der Begriff von Usability gewachsen ist? Im Jahr 2010 wurde User Experience die Ehre zuteil von einer ISO Norm erfasst zu werden: User Experience ist die Summe der Wahrnehmungen und Reaktionen eines Nutzers, die aufgrund einer tatsächlichen oder erwarteten Nutzung resultieren (ISO 9241-210:2010).
User Experience ist also im Unterschied zu Usability auch etwas, das bereits in der bloßen Erwartung reale Auswirkungen darin hat, dass die Nutzer in einer bestimmten Art und Weise reagieren. Usability wirkt nur wenn die Nutzer tatsächlich interagiert haben. Eine Erwartung wird aufgrund vorheriger Erfahrung entwickelt. Ich mag Libre Office noch nie verwendet haben. Weil ich aber weiß, dass es „so ähnlich ist wie“ Word, erwarte ich, dass es so ähnlich funktioniert wie Word. Daran zeigt sich, dass User Experience sehr individuell ist, weil die Erfahrungen individuell sind und dass User Experience stark kulturellen Einflüssen ausgesetzt ist. Ich kann nur empfehlen mal chinesische Apps zu testen, das ist eine komplett neue Welt.
Bereits das bloße Beobachten, wie jemand anders eine Software nutzt führt zu Emotionen und Reaktionen. So lässt sich der Hype um Let’s Play Videos erkären.
Die Berufsbezeichnung User Experience Designer, die fast synonym mit „Mensch, der dem Designer sagt, was er machen soll“ oder „Interaktionsdesign Prototypisierer“ ist, wird manchmal fälschlicherweise ausschließlich in die Design-Ecke geschoben. User Experience kommuniziert über Nutzeroberflächen, aber resoniert auch mit der ganzen Marke.
Und nun meiner Meinung nach das Wichtigste: User Experience ist etwas was die ganze Zeit in ständiger Veränderung ist und zu unterschiedlichen Zeitpunkten etwas anderes bedeutet (Roto et al. 2011). User Experience passiert vor, während und nach einer Nutzung. Während der Nutzung gibt es bestimmte Momente, Hochs und Tiefs. Messen wir also die User Experience während dem Test erfassen wir diese Hochs und Tiefs. Nach der Nutzung werden diese Hochs und Tiefs als ein Bild, die episodische User Experience, zusammengefasst in der man ein Zwischenfazit über die Software zieht. Über einen längeren Zeitraum hinweg bildet sich die kummulative User Experience. Alle Zwischenfazits werden mit der Erwartung und allem was die Marke zu einem Gesamteindruck vermischt. Je nachdem wann man fragt, erhält man also eine andere Form der User Experience als Antwort.
Wozu misst man nun User Experience wenn wir bereits die Usability gemessen haben? Ich will doch nur meine App verbessern? Eine gute Usability bedeutet, dass man seinen Nutzern keine Steine in den Weg gelegt hat. Das bringt noch niemand aus dem Häuschen. Eine gute User Experience bedeutet, dass die Leute einen lieben. Eine gute Usability ist die Voraussetzung für eine gute User Experience, aber nicht der alleinige Faktor. Eine gute User Experience zu erzeugen hat mit der Markendarstellung zu tun – ja, jede kleine App steht auch für eine Marke ein und wenn es nur der Name des Entwicklers ist – mit dem Gefühl, dass die Software auslöst. Damit man das beeinflussen kann muss man erstmal wissen wie man wahrgenommen wird. Dafür sind Fragebögen perfekt geeignet.
User Experience messen
Der Goldstandard der User Experience Fragebögen ist vom User Experience Urvater Marc Hassenzahl persönlich: Attrakdiff (Hassenzahl 2003). Mittlerweile gibt es die Version 2 davon. Ich nutze den Fragebogen immer vor und nach der Änderung einer Software, damit ich sehen kann in welche Richtung wir uns bewegt haben. Durch die User Experience Umfrage erfahren wir auch sehr viel über unsere Zielgruppe, denn User Experience ist individuell und kulturell abhängig. Wir erfahren auch wie sich die Zielgruppe im Nutzungskontext fühlt. Eine Software die für mich im Büro einfach zu bedienen ist kann für jemand aus der Zielgruppe überfordernd sein, wenn er gerade unter Hochstress seinen wöchentlichen Psychotherapiefragebogen ausfüllt.
Wir haben vorhin gelernt, dass es unterschiedliche Arten von User Experience gibt, je nachdem wann man misst. Mit dem Attrakdiff finde ich episodische und kummulative User Experience heraus.
Möchte ich situative User Experience messen, dann kann man den Tester eine User Experience Kurve malen lassen, die darstellt zu welchem Zeitpunkt der Nutzung er sich gut oder schlecht gefühlt hat. Eignet sich gut, um daran nach dem Nutzertest das Interview zu führen.
Quellen
Hassenzahl, M., Burmester, M. and Koller, F. (2003) ‘AttrakDiff: Ein Fragebogen zur Messung wahrgenommener hedonischer und pragmatischer Qualität’, Mensch & Computer, pp. 187–196 [Online]. Online verfügbar unter http://attrakdiff.de/files/mc2003_hassenzahl_review.pdf (Geprüft 11. November 2014).
Roto, V., Law, E., Vermeeren, A. and Hoonhout, J. (2011) User Experience White Paper: Bringing clarity to the concept of user experience [Online]. Online verfügbar unter http://www.allaboutux.org/files/UX-WhitePaper.pdf (Geprüft 11. November 2014).
ISO (2010) DIN ISO 9241-210:2010: Ergonomie der Mensch-System-Interaktion – Teil 210: Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme [Online]. Online verfügbar unter http://perinorm-s.redi-bw.de/volltexte/CD21DE05/1728173/1728173.pdf? (Geprüft 29. Oktober 2014).
ISO (2006) DIN ISO 9241-110:2006: DIN EN ISO 9241-110 Ergonomie der Mensch-System-Interaktion – Teil 110: Grundsätze der Dialoggestaltung (ISO 9241-110:2006); Deutsche Fassung EN ISO 9241-110:2006: Perinorm [Online]. Online verfügbar unter http://perinorm-s.redi-bw.de/volltexte/CD21DE04/1464024/1464024.pdf? (Geprüft 28 Juni 2013).
ISO (1999) DIN ISO 9241-11:1998: DIN EN ISO 9241 Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten – Teil 11: Anforderungen an die Gebrauchstauglichkeit (ISO 9241-11:1998); Deutsche Fassung EN ISO 9241-11:1998 (in Kraft getr. am 1999) [Online]. Online verfügbar unter http://www.naerg.din.de/cmd?level=tpl-art-detailansicht&committeeid=54738891&artid=5160339&languageid=en&bcrumblevel=3&subcommitteeid=54744823 (Geprüft 28 Juni 2013).
Hamborg, K.-C. (2002 [2002]) ‘Gestaltungsunterstuetzende Evaluation von Software: Zur Effektivitaet und Effizienz des IsoMetrics Verfahrens’, Mensch & Computer, pp. 303–312 [Online]. Online verfügbar unter http://bjoern.releasemyalbum.com/literature/HamborgKC_2002_Gestaltungsunterstuetzende%20Evaluation%20von%20Software%20-%20Zur%20Effektivitaet%20und%20Effizienz%20des%20IsoMetrics%20Verfahrens.pdf (Geprüft 11. November 2014).
Prümper, J. (2014) Beurteilung von Software auf Grundlage der Internationalen Ergonomie-Norm DIN EN ISO 9241-110 [Online]. Online verfügbar unter http://www.seikumu.de/de/dok/dok-echtbetrieb/Fragebogen-ISONORM-9241-110-S.pdf (Geprüft 13. November 2014).
Prümper, J. and Anft, M. (1993) ‘Die Evaluation von Software auf Grundlage des Entwurfs zur internationalen Ergonomie-Norm ISO 9241 Teil 10 als Beitrag zur partizipativen Systemgestaltung – ein Fallbeispiel.’, Software-Ergonomie, pp. 145–156.
Gediga, G., Hamborg, K.-C. and Düntsch, I. (1999) ‘The IsoMetrics Usability Inventory: An operationalisation of ISO 9241-10’, Behaviour and Information Technology, vol. 18, pp. 151–164.
Brook, J. (1986) System Usability Scale (SUS) [Online], Department of Health and Human Services. Online verfügbar unter http://www.usability.gov/how-to-and-tools/methods/system-usability-scale.html (Geprüft 11. November 2014).
Chin, J. P., Diehl, V. A. and Norman, K. L. (1988) Development of an Instrument Measuring User Satisfaction of the Human-Computer Interface [Online]. Online verfügbar unter http://garyperlman.com/quest/quest.cgi?form=QUIS (Geprüft 24. September 2015).
Harper, B., Slaughter, L. and Norman, K. (1997) ‘Questionnaire administration via the WWW: A validation and reliability study for a user satisfaction questionnaire’, Proceedings of WebNet 97 – World Conference on the WWW, Internet & Intranet. Canada, Toronto, AACE.
Figl, K. (2010) ‘Deutschsprachige Fragebögen zur Usability-Evaluation im Vergleich’, Zeitschrift für Arbeitswissenschaft, vol. 4 [Online]. Online verfügbar unter http://nm.wu-wien.ac.at/research/publications/b939.pdf (Geprüft 11 November 2014).
Porst, R. (2014) Fragebogen: Ein Arbeitsbuch, 4th edn, Wiesbaden, VS-Verl.
Hassenzahl, M. (2010) Experience design: Technology for all the right reasons, [San Rafael, Calif.], Morgan & Claypool Publishers.
Virzi, R. A. (1992) ‘Refining the Test Phase of Usability Evaluation: How Many Subjects Is Enough?’, Human Factors: The Journal of the Human Factors and Ergonomics Society, vol. 34, no. 4, pp. 457–468.
Nielsen, J. (2000) Why You Only Need to Test with 5 Users [Online]. Online verfügbar unter https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ (Geprüft 15. Mai 2018).
Nielsen, J. und Landauer, T. K. (1993) ‘A mathematical model of the finding of usability problems’, Bridges between worlds: Conference on Human Factors in Computing Systems, INTERACT ’93 and CHI ’93, Amsterdam, the Netherlands, 24-29 April 1993. Amsterdam, The Netherlands. New York, N.Y., Association for Computing Machinery, pp. 206–213.
Spool, J. und Schroeder, W. (2001) ‘Testing web sites: five users is nowhere near enough’, Extended Abstracts on Human Factors in Computing Systems. New York, NY, USA, ACM, pp. 258–286.