Dies ist der dritte Teil der Blogserie “Die User Experience messen”. Wenn Sie mehr zu einer möglichen Kategorisierung verschiedener User Experience Forschungsmethoden erfahren möchten und wann welche Methode am besten geeignet ist, können sie zu Teil 1: “Wann ist welche UX Forschungsmethode geeignet?” springen.
Im zweiten Teil erfahren Sie mehr zu den Evaluationsinstrumenten, die dabei helfen die Qualität der User Experience oder einzelnen Aspekten davon abzuschätzen.
Teil 2: User Experience Evaluationsmethoden
Wie diese dreiteilige Blogserie versucht aufzuzeigen, gibt es sehr viele verschiedene Methoden und Metriken mit denen man versuchen kann, Apekte der User Experience zu erfassen.
Die User Experience im kleinen Rahmen zu messen, kann mittels Interviews, Usability Tests usw. erreicht werden. Schwierieger wird es wenn man dies im grösseren Stil erfassen und die Entwicklung über die Zeit mitverfolgen möchte. Interessant ist dies etwa wenn man herausfinden will wie sich eine Designänderung auf die User Experience auswirkt, z.B. im Rahmen eines A/B Tests oder beim Hinzufügen neuer Features. Man kann beispielsweise regelmässige Online- oder Telefonbefragungen durchführen, wobei bei alleiniger Anwendung desselben das Problem wieder ins Spiel kommt, dass das, was die Leute sagen, sich nicht zwingend mit dem deckt, was sie tun. Um herauszufinden, was die Leute tun, muss man Verhaltensdaten erheben. Viele etablierte Messmethoden für Verhaltensdaten eignen sich jedoch schlecht für die grossflächige oder und kontinuierliche Erhebung, da z.B. mit Stoppuhren und Checklisten gearbeitet wird um beispielsweise zu messen, wie lange man für eine Aufgabe braucht oder wie viele Fehler gemacht werden.
Die steigende Verbreitung von Web-Applikationen, die es erlauben eine ganze Reihe von Aufgaben online zu erledigen, wie zum Beispiel Dokumente zu erstellen und zu bearbeiten oder Photos zu editieren, ermöglicht es eine ganze Reihe an Webserver Logdaten zu analysieren, die die Produktnutzung im grossen Stil und kontinuierlich aufzeigen kann. Ausserdem gibt es mittlerweile viele Tools, die auch die Benutzung von Webseiten, oder das Lesen von Mail Newslettern mittracken und verfolgen können. Alle diese Tracking Mechanismen generieren eine grosse Menge an Daten, die man auswerten kann. Daher gibt es unterdessen sehr viele verschiedene Metriken im Bereich von Webseiten wie man z.B. in der Liste auf cxpartners.co.uk sehen kann, mit über 100 verschiedenen Metriken. Viele dieser Metriken messen zwar die User Experience nicht direkt, aber sie können Hinweise darauf liefern, wie das Benutzererlebnis sein könnte: Wenn man zum Beispiel auf Google Analytics sieht, dass viele Benutzer den Zurück-Button im Browser an einer unerwarteten Stelle verwenden, könnte das ein Hinweis dafür sein, dass dort entweder etwas nicht funktioniert, oder die Benutzer nicht wissen was sie als nächstes tun sollen, was natürlich einem guten Benutzererlebnis wenig zuträglich ist. Eine Schwierigkeit ist also herauszufinden, welche Kombination von Messmethoden Sie anwenden wollen und welche Messmethoden Ihnen dabei helfen Ihre Fragestellung zu beantworten.
Die meistgebrauchten Metriken wie Seitenaufrufe, Geschwindigkeit, Einnahmen, usw. sind zwar wichtig und haben auch einen Einfluss auf die User Experience, sind aber konzeptionell nur low-level oder indirekte Metriken für die User Experience und können nicht gut gebraucht werden, um den Einfluss von Interface Änderungen zu evaluieren.
Rodden et al. von Google Ventures haben eine Methode entwickelt, wie man für Web-Applikationen die richtigen benutzerzentrierten Metriken auswählen kann, die einem dann wirklich etwas nützen und Verhaltensdaten und Einstellungsdaten im grossen Stil erfassen, die einen stärkeren Zusammenhang mit der User Experience als die klassischen Metriken haben.
Die Methode beinhaltet das HEART-Framework und den Goals-Signals-Metrics-Prozess:
HEART steht für Happiness, Engagement, Adoption, Retention und Task success. Metriken, die gebraucht wurden, fielen meistens in eine dieser Kategorien und im nächsten Abschnitt sind sie kurz erklärt:
Das Google HEART-Framework
- Happiness: Metriken für Einstellungen der Benutzer, oft erhoben mittels Umfragen. Zum Beispiel: Zufriedenheit, wahrgenommene Einfachheit der Benutzung
- Engagement: das Level des Engagements der Benutzer, typischerweise indirekt gemessen über Verhaltensvariablen wie Häufigkeit, Intensität, oder die Tiefe der Interaktion über einen bestimmten Zeitraum. Zum Beispiel die Zahl der Besuche pro Woche pro Benutzer.
- Adoption: Neue Benutzer eines Produkts oder Features, z.B. die Anzahl neuer Benutzeraccounts in der letzten Woche, oder der Prozentsatz der Webseitenbesucher, die ein bestimmtes Feature benutzen.
- Retention: Die Fähigkeit eines Produkts die Nutzer zu binden und zu regelmässigem Gebrauch zu animieren. Zum Beispiel die Anzahl aktiver Benutzer vor einem halben Jahr, die auch heute noch aktiv sind.
- Task success: Hier gehören auch traditionelle Verhaltensmetriken der Usability hinein, wie zum Beispiel die Effektivität (die Genauigkeit und Vollständigkeit mit der Benutzer ihre Ziele erreichen, z.B. der Prozentsatz an abgeschlossenen Aufgaben) oder die Fehlerrate. Diese Kategorie ist am besten geeignet für Bereiche Ihres Produkts, die sehr Aufgabenzentriert sind.
Dies auf verschiedenen Levels angewendet werden: Man kann so ein ganzes Produkt, oder nur ein bestimmtes Feature untersuchen.
Man muss auch nicht Metriken für alle Kategorien definieren, sondern nur diejenigen verwenden, die für das aktuelle Projekt am relevantesten sind und am meisten Sinn ergeben, dazu mehr im nächsten Abschnitt über den Goals-Signals-Metrics-Prozess. Das HEART-Framework kann Ihnen also helfen zu entscheiden, ob eine bestimmte Kategorie für eine Evaluation einbezogen oder ausgeschlossen werden soll. Zum Beispiel macht es bei einer Firmensoftware nicht viel Sinn das Engagement zu messen, wenn die Benutzer die Software jeden Tag brauchen, um ihre Arbeit zu erledigen. In diesem Fall macht es vielleicht mehr Sinn sich eher auf die Happiness oder Task Sucess Kategorie zu konzentrieren. Die Engagement Kategorie macht vielleicht aber wieder Sinn, wenn man ein bestimmtes Feature der Software untersuchen möchte.
Goals-Signals-Metrics Prozess
Wie kommen Sie nun von diesen Kategorien zu den Metriken, die Sie verwenden wollen?
Der Goals-Signals-Metrics Prozess hilft dabei die Ziele (Goals) eines Produkts zu definieren, dann die Signale oder Indikatoren zu identifizieren die einen Fortschritt in Richtung der Ziele anzeigen, und schliesslich spezifische Metriken zu erstellen die die Signale messen können und die man verfolgen kann.
Goals (Ziele) identifizieren und definieren
Bevor man einfach eine Liste mit Metriken aufstellt bei der man nachher Mühe hat Prioritäten zu setzen und herauszufinden, was diese schlussendlich aussagen, sollte auf einem höheren Level begonnen werden: Identifizieren und definieren Sie die Ziele im Bereich User Experience des Projekts, so dass Sie dazu anschliessend Metriken definieren können, welche einen Fortschritt zu diesen Zielen hin darstellen. Das Definieren und Artikulieren von Zielen kann sehr schwierig sein; Genau dabei sollen die HEART Kategorien helfen, indem man sich an ihnen orientieren kann und sich überlegen kann, welche Kategorien für das Produkt oder das Feature sinnvoll und am wichtigsten sind.
Eine Gefahr ist es die bereits existierenden Metriken als Ziele umzuformulieren: “Wir wollen die Zugriffe auf unsere Webseite (Traffic) erhöhen”. Sie müssen sich hier fragen wie User Experience Verbesserungen dabei helfen können: Wollen sie durch Verbesserungen das Engagement der Benutzer erhöhen, oder wollen sie durch Verbesserungen neue Benutzer anziehen?
In diesem Schritt ist es vor allem wichtig, dass die Ziele für das zu analysierende Produkt oder Feature klar definiert werden, ohne sich schon zu genau zu überlegen, wie man dies dann messen will.
Signals überlegt auswählen
Als nächstes sollten sie sich überlegen, wie sich der Erfolg, Misserfolg oder die Annäherung an die, respektive die Entfernung von den Zielen im Benutzerverhalten oder den Benutzereinstellungen äussern könnten: Welches Benutzerverhalten könnte anzeigen, ob das Ziel erreicht ist, oder welche Benutzereinstellungen wären ein Indikator dafür, ob Sie dem Ziel zumindest näher gekommen sind? Bei diesem Punkt sollten Sie sich auch langsam überlegen, woher die Daten für diese Signale kommen könnten: Beim Team um Rodden von Google waren es häufig Logs (Protokolle) oder Umfragen, es gibt aber auch andere Möglichkeiten. Oft gibt es viele mögliche und potentiell nützliche Signale für ein bestimmtes Ziel.
Hier kann man ein bisschen Forschung betreiben und analysieren, welche Signale man wählen will. Entscheidungshilfen können sein, wie schwierig es ist ein Signal zu verfolgen und dabei die technischen Möglichkeiten zu beachten.
Weiter sollten Signale gewählt werden, die sensitiv auf Designänderungen reagieren und sehr stark mit den Zielen zusammenhängen. Änderungen in den Signalen sollten möglichst auf die Veränderung der User Experience zurückführbar sein und möglichst nicht von anderen Faktoren beeinflusst werden.
Metrics definieren um Signals zu messen
Der Schritt in diesem Prozess besteht darin zu definieren, wie diese Signale in messbare Skalen transformiert werden können, die Sie dann über die Zeit beobachten und zum Beispiel für einen Vergleich in einem A/B Test heranziehen können. Es ist hier sinnvoll möglichst Mittelwerte und Anteile (Prozent) zu verwenden anstelle von absoluten Zahlen, da dies die Vergleichbarkeit erhöht.
Wie beim vorherigen Schritt müssen Sie vielleicht auch hier einmal ausprobieren und analysieren, welche Metriken am besten geeignet sind, um die Signale zu messen.
Als nächstes wird von Google Ventures empfohlen die HEART Kategorien in einer Tabelle darzustellen und zu den jeweiligen Kategorien die Ziele, Signale, und die Metriken einzutragen. Das Beispiel unten könnte für eine Corporate Webseite angewendet werden: