Lost im Feedback-Dschungel: Ein Guide zum Feature

Gutes Feedback ist ein Geschenk – denn es hilft uns besser zu werden. Beim User Centered Design wollen wir genau das erreichen: Die Software kontinuierlich verbessern – maßschneidern – bis sie auch wirklich zu den Anforderungen passt. Deshalb holen wir im Entwicklungsprozess regelmäßig Nutzerfeedback ein. Nicht selten kommt dabei eine ganze Menge zusammen und man sieht den Wald vor lauter Bäumen nicht. Wir zeigen, wie man im Feedback-Dschungel die Orientierung behält und den Weg zur passgenauen Software bahnt! 

Den richtigen Weg gehen mit User Centered Design (© Foto von 邱 严 auf Unsplash, Schriftzug eXXcellent solutions)

Muster identifizieren mit dem Affinity Diagram

In den vorherigen Beiträgen unserer Kaizen-Reihe haben wir uns bereits damit beschäftigt, warum Feedback so wichtig ist und wie wir es am besten einholen können. Ist das Feedback erstmal gesammelt, stellt sich die Frage: Was machen wir damit?  Wir verschaffen uns erstmal einen Überblick!

Hierfür eignet sich ein Affinity Diagram. Dabei werden die gesammelten Informationen auf einen Notizzettel geschrieben und an ein großes Whiteboard oder an eine Wand geklebt. Im nächsten Schritt sollten die Elemente sortiert und in entsprechende Cluster geordnet werden. Diese ergeben sich meistens aus dem Material. Ein guter Einstieg kann zunächst auch eine Gruppierung nach der Art der Nutzer sein. Jedes Cluster bekommt einen Titel und eine kurze Beschreibung, worum es in der jeweiligen Kategorie geht. Je mehr Informationen man erhält, desto eindeutiger lassen sich Muster erkennen und die Cluster zusammenfassen oder ausdifferenzieren. Diese Prozedur wird so oft wiederholt, bis es nur noch wenige Cluster gibt und die Gruppen in sinnvolle Kategorien unterteilt wurden. Bei dieser Methode ist es üblich, dass sich die Kategorien immer mal wieder ändern, je nachdem welche Informationen gefunden wurden. Um die Datenmenge zu reduzieren, sollten die zehn wichtigsten Erkenntnisse zusammengefasst werden.

Affinity Diagram nach Nutzergruppen geclustert (© eXXcellent solutions)

Dinge, die öfters von verschiedenen Nutzern erwähnt werden, rutschen dabei in der Prioritätsliste weiter oben, da hier wohl die größten Probleme liegen. Gerade bei einer Vielzahl an Informationen ist es sinnvoll, sich auf die wichtigsten Erkenntnisse zu konzentrieren. Eine Methode zur Priorisierung, ist beispielsweise das Kano-Modell. 

Das Kano-Modell als Priorisierungsmethode    

Das Kano-Modell unterscheidet fünf Merkmale, die mehr oder weniger Einfluss auf die Kundenzufriedenheit haben können: Basismerkmale, Leistungsmerkmale, Begeisterungsmerkmale, unerhebliche Merkmale und Rückweisungsmerkmale.

• Basismerkmale sind Kriterien, die eine Anwendung auf jeden Fall beinhalten sollte, ist dies nicht der Fall, ist der Kunde unzufrieden. Jedoch macht die Anwesenheit solcher Kriterien den Kunden auch nicht automatisch zufriedener. 
• Leistungsmerkmale haben direkten Einfluss auf die Zufriedenheit. Sobald sie nicht vorhanden sind, werden die Kunden unzufrieden und sobald sie übertroffen werden, steigt die Zufriedenheit.
• Begeisterungsmerkmale werden vom Kunden nicht erwartet, sind sie jedoch vorhanden, sind sie Alleinstellungsmerkmale für die Anwendung. Das Fehlen von solchen Merkmalen hat keinen Einfluss auf die Unzufriedenheit des Kunden, wenn vorhanden, führen diese Merkmale jedoch zu einer guten UX und steigern die Nutzung und Loyalität des Kunden.
• Unerhebliche Merkmale haben weder Einfluss auf die Zufriedenheit noch auf die Unzufriedenheit des Kunden. Investitionen in solche Merkmale sollten vermieden werden, da sie dem Kunde keinen Mehrwert bieten.  
• Rückweisungsmerkmale können die Kunden davon abhalten, das Produkt überhaupt zu nutzen und sollten daher, wenn möglich, ausradiert werden.

In welchem Bereich des Graphen befinden sich unsere Funktionalitäten aktuell? Wo müssen wir investieren? (© Grafik von eXXcellent solution nach Elmar Sauerwein)

Die Einteilung des Nutzerfeedbacks nach den Merkmalen des Kano-Modells hilft dabei, den Stand der Software einzuordnen. Weist die Anwendung wenig Basisfaktoren und Leistungsfaktoren auf, müssen wir hier investieren, um die Kundenzufriedenheit zu steigern – also im Graphen von unten links nach oben rechts zu rutschen. 

Um zu erkennen, was ein Leistungsmerkmal oder ein Basismerkmal ist und welche Merkmale eher unerheblich für die Nutzer sind, eignet sich eine Matrix. Mittels sogenannten funktionalen Fragen und dysfunktionalen Fragen können die Informationen abgeprüft und dem entsprechenden Merkmal zugeordnet werden. Beispielsweise wäre eine funktionale Frage: “Was wäre, wenn ich in der Tabelle die Spalten ein- und ausblenden könnte?” und eine dysfunktionale Frage: “Was wäre, wenn ich in der Tabelle die Spalten nicht ein- und ausblenden könnte?” Würde der Nutzer im ersten Fall “Das würde mich sehr freuen” antworten und im zweiten Fall “Das erwarte ich”, dann kann davon ausgegangen werden, dass der Nutzer in diesem Beispiel keine Funktion zum Ein- und Ausblenden der Tabelle erwarten, sich jedoch darüber freuen würde, was wiederum auf ein Begeisterungsmerkmal schließt. Dies kann auch in Form eines Fragebogens mit dem Kunden abgefragt werden oder man stellt sich selbst die Fragen im Team.  

Fragen-Matrix des Kano-Modells (© Grafik von eXXcellent solutions nach Elmar Sauerwein)

So weit, so abstrakt – aber wie können wir jetzt damit arbeiten?

Diagramme und Matrizen sind gut, um ein Problem auseinanderzufieseln. Um nun die Essenz daraus abzuleiten, lohnt es sich die Erkenntnisse in Worte zu übersetzen und einen Point of View zu formulieren. Was sollte die Software aus Sicht des Nutzers erfüllen? Was braucht er oder sie und warum? 

Der Nutzer A braucht Übersichtlichkeit bei der Bearbeitung der Tabelle, weil er sonst unnötig Zeit damit verschwendet, die für ihn relevanten Spalten zu finden.
– Beispiel Point of View

Sobald das Problem klar definiert ist, sind User Stories eine gute Möglichkeit, um die Funktionen und Anforderungen des Produkts festzulegen. Dabei sollte vor allen Dingen das Ziel des Nutzers im Auge behalten und verstanden werden. Neben dem Ziel und dem Weg dorthin betrachtet man auch die möglichen Probleme, warum ein Nutzer aktuell nicht zu seinem Ziel kommt.  

Als Tabellenpfleger wünsche ich mir, dass ich nur das sehe, was in dem Moment für mich relevant ist, um effizienter arbeiten zu können.
– Beispiel User Story

Im nächsten Schritt werden Anforderungen formuliert. Letztendlich sind es die Benutzer, die über Erfolg oder Misserfolg eines Produkts entscheiden. In diesem Fall wäre die Anforderung eine Funktion zum Ein- und Ausblenden der Spalten in der Tabelle. 

Tadaa! Aus Feedback wurde Feature    

Weitere Informationen:

Über die Autor:innen: