Lab meets Data – quantitative Daten für und in Usability-Tests

Intro

Das Ergebnis einer klassischen quantitativen (Online-)Forschung spiegelt in der Regel das Gesamtbild der Zufriedenheit und/oder Usability eines Produkts, einer Website, Software oder App wider. Wie genau die spezifischen Problembereiche, deren Ursachen oder sogar nutzerorientierte Lösungen aussehen könnten, ist dann eher Ergebnis eines Usability-Lab-Tests. Dieser liefert diesbezüglich zwar durchaus nützliche Erkenntnisse, eine zeitliche oder produkt-/websitebezogene Vergleichbarkeit ist jedoch nur begrenzt möglich. Ebenso stellt es sich meist als recht schwierig heraus, die Geschäftsleitung mit einem zwar plakativen, aber doch eben individuellen und somit sehr subjektiven 30-sekündigem Highlight-Video zu einem mehrstelligen Invest zu überreden. Ein möglicher Lösungsansatz ….

Standardisierte Befragung in Usability-Tests

Die Integration von standardisierten Befragungen in Usability-Tests bietet die Möglichkeit, die qualitativen Erkenntnisse um quantitative Daten zu ergänzen. Eine gewinnbringende Hochzeit. Denn Usability-Tests sind zwar ein wertvolles Tool um Produkte, Websites und Anwendungen auf ihre Gebrauchstauglichkeit zu testen und explizite Schwachstellen zu identifizieren, sie stoßen jedoch in machen Bereichen eben auch an ihre Grenzen.

So ist z. B. ein zeitlicher Vergleich nur bedingt und sehr subjektiv möglich. Gerade aber im Rahmen von Relaunches (vorher/nachher) oder bei der agilen Entwicklung (kontinuierliche Kontrolle) sind messbare Fortschritte und Verbesserungen von Interesse. Hier bietet die Einbindung einer standardisierten Befragung eine objektivere und – bei entsprechender Umsetzung – eine valide Basis für Entwicklungs- und Vergleichswerte. Dies kann gerade auch bei der Berichterstattung in Entwicklungsprojekten eine nützliche Größe sein, um die Stakeholder zufriedenzustellen.

Vergleichswerte müssen sich aber nicht nur auf einen zeitlichen Vergleich beziehen. Auch im Hinblick auf die Vergleichbarkeit von einzelnen Komponenten und/oder Use Cases bietet die Integration einer standardisierten Befragung die Möglichkeit, die einzelnen Aspekte auf einer gemeinsamen Basis zu bewerten.

Auch kann die Integration einer Post-Test-Befragung die Objektivität bei der internen Kommunikation steigern. Denn eventuell ist manch eine Fachabteilung daran interessiert, beim abschließenden Report eines Usability-Tests einige der kritischen Ergebnisse zugunsten der weniger schwerwiegenden Probleme unter den Tisch fallen zu lassen – oder gegenteilig: das Produkt schlimmer dastehen zu lassen, in dem nur die Probleme, nicht aber das Gesamtbild inkl. des positiven Nutzerfeedbacks weiter kommuniziert werden. Ein standardisiertes und quantitatives Userfeedback kann hier die Objektivität und das Gesamtbild der Erkenntnisse unterstreichen.

Last but not least kann die Erhebung eines Usabilty Scores, z. B. über eine auf der Website geschaltete Online-Umfrage, eine (kontinuierliche) Messung und Kontrolle darstellen und entsprechende Handlungsbedarfe aufzeigen und folgend auch eine Argumentations- und/oder Ausgangsbasis für einen Usability-Test bieten. Zudem bietet die Online-Umsetzung die alternative Möglichkeit, online eine differenzierte Usability-Befragung einzuleiten.

Der System Usability Scale

Konzept

Der System Usability Scale (SUS) wird allgemein als quick-and-dirty-Methode angesehen. Dieser Bezeichnung sollte aber durchaus kein negativer Beigeschmack beiwohnen, denn nicht nur wegen seiner Schlankheit – und somit guten Integrierbarkeit – hat er sich zu einem beliebten und weit verbreiteten Tool entwickelt. Auch bildet die Skala mit ihren 10 Items eine validierte Basis sowie zudem auch weitreichende Vergleichswerte an – beides wichtige Eigenschaften für die Bewertung meines Systems.

Entwickelt aus einer Basis von ursprünglich 50 Items (vgl. Brook 1996) spiegelt die Skala ein Messinstrument für die Usability, u.a. hinsichtlich der Einfachheit, Erlernbarkeit, Komplexität als auch der weiteren Nutzungsabsicht wider. Die Skala eignet sich für den Einsatz in Bezug auf verschiedene Systeme und kann sich auch im Vergleich zu anderen, teils weit komplexeren Skalen wie bspw. dem SUMI (Software Usability Measurement Inventory) behaupten.

Skala

Die originäre Skala von Brooks (1996) findet sich in dem entsprechenden Paper „SUS – A quick and dirty usability scale“. Offizielle, validierte Übersetzungen bestehen gemäß Brook (2013) bislang noch nicht, ich bin jedoch nicht sicher, ob dem Autor hier die deutsche Forschung bekannt ist. So gibt bzw. gab es ein Projekt von Wolfgang Reinhard, in welchem eine Übersetzung des SUS durch eine Crowdsourcing-Kampagne stattgefunden hat. Begleitet wurde dies von zwei deutschen HCI-Experten (SAP). Neben dieser (nicht zu unterschätzenden) Prüfung der Augenscheinvalidität erfolgte zudem eine nachgelagerte Rückübersetzung ins Englische, um die Kongruenz der Übersetzung zum Original sicherzustellen – eine gängige wissenschaftliche Methode. Die Ergebnisse sollten somit also auch für die deutsche Variante eine valide Skala darstellen (ich freue mich aber über Informationen zu diesbezüglichen Erkenntnissen).

  1. Ich denke, dass ich das System gerne häufig benutzen würde.
  2. Ich fand das System unnötig komplex.
  3. Ich fand das System einfach zu benutzen.
  4. Ich glaube, ich würde die Hilfe einer technisch versierten Person benötigen, um das System benutzen zu können.
  5. Ich fand, die verschiedenen Funktionen in diesem System waren gut integriert.
  6. Ich denke, das System enthielt zu viele Inkonsistenzen.
  7. Ich kann mir vorstellen, dass die meisten Menschen den Umgang mit diesem System sehr schnell lernen.
  8. Ich fand das System sehr umständlich zu nutzen.
  9. Ich fühlte mich bei der Benutzung des Systems sehr sicher.
  10. Ich musste eine Menge lernen, bevor ich anfangen konnte das System zu verwenden.

Unschwer zu erkennen, stellen die Items 2, 4, 6, 8 und 10 negativ formulierte Items dar und müssen bei der Auswertung entsprechend invertiert werden.

Erhebung

Neben der Integration in Online-Umfragen kann der SUS wie oben beschrieben sehr gut im Rahmen von Lab-Tests eingebunden werden. Die Erhebung des SUS kann dann ganz klassisch im Rahmen des abschließenden Interviews auf Papier oder – etwas moderner – auf dem Tablet durchgeführt werden.

Bezüglich der Mindestteilnehmerzahl verweisen Tullis und Stetson (2004) darauf, dass bereits eine Erhebung ab 12 Teilnehmern zu einem verlässlichen Ergebnis des SUS führt (10 Teilnehmer zu 80-prozentiger Verlässlichkeit). Für einen Report oder einen simplen Vergleich mag das ausreichen, wenn Sie die Ergebnisse als quantitativen Datensatz nutzen und damit rechnen wollen, sollten Sie jedoch das klassische n=30 erreichen.

In Bezug auf die Erhebungsskala wird der SUS meist auf einer 5-stufigen Likertskala erhoben. Ich bin aus Gründen der Differenzierbarkeit jedoch ein großer Freund von 7 Stufen. Der Autor des SUS (Brook 1996) nutzt fünf Stufen, lässt es in seinem Paper aber selbst offen auch eine 7-stufige Skala zu nutzen (S. 3). Eine diesbezügliche Studie zur Skalierung des SUS (Finstad 2010) zeigt zudem, dass die Erhebung auf einer 7-stufigen Skala zu akkurateren Ergebnissen führt und Nutzer zudem auf einer 5-stufigen Skala eher dazu tendieren auch mal zwischen den Skalenwerten anzukreuzen – gerade bei der papierbasierten Erhebung im Lab ein Risikofaktor. Ich empfehle daher die 7er Skala (wie wir sie natürlich auch bei eResult nutzen, wir wollen es ja immer genau wissen ;).

Auswertung

Das Ergebnis des SUS ist ein Usability-Gesamt-Score. Dieser errechnet sich aus den summierten Werten der einzelnen Items. Wurde die Skala mit den Werten 1-5 oder 1-7 erhoben, so sind die Datenpunkte vorab jeweils mit -1 zu recodieren (konkret also x-1). Die negativ formulierten Items müssen hingegen invertiert werden, so dass die Extremwerte stets in die gleiche Richtung zeigen. Konkret bedeutet dies für die negativen Items statt -1 also den Maximalwert der Skala plus eins minus den Skalenwert (6-x oder 8-x).

Auf die Bildung der Summe hin erhält man einen Gesamtwert von 0-40 bzw. 0-70. Da wir es ja aber gewohnt sind im Bereich 0-100 zu denken, wird der Gesamtwert sodann mit 10/4 (5er Skala) oder 10/6 (7er Skala) multipliziert. Wir sehen also, dass der SUS somit eigentlich kein Prozentwert ist, allerdings stellt ein SUS-Score von 80 bei max. 100 ja dennoch 80 % des möglich Erreichbaren dar.

Interpretation

Eines ist klar, je höher der Wert, desto besser die Usability. Die meisten Product Owner, Tester, Manager etc. wollen ja aber immer auch wissen „was heißt das [mein Wert] denn jetzt nun?“. Um diese Frage beantworten zu können, wird meist auf den globalen Durchschnittswert von 68 verwiesen (Bangor et al. 2009 für Web, Sauro 2011 im Allgemeinen). Nützlich ist zudem eine Betrachtung des Medians, also ob mehr als die Hälfte der Teilnehmer meine Anwendung über- oder unterdurchschnittlich bewerten.

Wer es etwas genauer nehmen bzw. berichten möchte, greift auf die Klassifikation von Bangor et al. (2009) zurück. Diese haben verschiede SUS-Bereiche mit einem klassischen Schulnotensystem (allerdings mit dem ECTS/amerikanischen System) von A-F verknüpft. Demnach ist ein Usability-Wert über 90 außerordentlich und mit einem „sehr gut“ zu vergleichen. Werte ab 80 spiegeln ein „gut“, Werte größer 70 ein „befriedigend“ wider. Usability-Werte unter 70 stellen hingegen besorgniserregende Ergebnisse dar, wobei hier Werte zwischen 60 und 70 noch unter geringwertig schlecht, aber eben gerade noch „ausreichend“, Werte unter 60 als „ungenügend“ und somit nicht tragbar angesehen werden (vgl. Abb 1).

Abb. 1: Beispielhafte Darstellung des SUS-Scores

Abb. 1: Beispielhafte Darstellung des SUS-Scores


Fazit

„Quick but not so dirty“ so lautet das Fazit des UX-lers Jeff Sauro, welchem ich mich gerne anschließen möchte. Denn der SUS bietet nicht nur zuverlässige erste Ergebnisse bezüglich der Usability eines Systems, sondern auch zahlreiche weitere Vorteile, wie die oben genannte zeitliche und Use-Case-/objektbezogene Vergleichbarkeit oder eine praktikablere Kommunikationsgrundlage. Der weit verbreitete und vielseitige Einsatz als auch seine Kürze sprechen somit, auch trotz – oder gerade wegen – der sich ständig ändernden Technologielandschaft für sich. Nichtsdestotrotz liefert der SUS alleine keine Erkenntnisse, wo genau eventuelle Probleme liegen und bietet somit definit keinen Ersatz für weitere Forschung bzw. den Usability-Test an sich – wir beraten Sie da aber gerne.

Quellen

Bangor, A.; Kortum, P.; Mille, J (2009): Determining What Individual SUSvScores Mean: Adding an Adjective Rating Scale, in: JUS – Journal of Usability Studies (4/3), S. 114-123.
Brooke, J. (1986): SUS: A „quick and dirty“ usability scale, in: Jordan, B.; Thomas, P.; Weerdmeester, B.; McClelland, I.(Hrsg.), Usability evaluation in industry, S. 189–194.
Brooke, John (2013): SUS: A Retrospective, in: JUS – Journal of Usability Studies (8/2), S. 29-40.
Finstad, K.(2004): Response Interpolation and Scale Sensitivity: Evidence Against 5-Point Scales, in: JUS – Journal of Usability Studies (5/3), S. 104-110.

Portraitfoto: Susanne Niklas

Susanne Niklas

Senior User Experience Consultant

Alumni-eresult GmbH

Bisher veröffentlichte Beiträge: 7

Ein Kommentar

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.