Aus Kunden-Feedback Lernen


Post Image

Sie haben den Anwender bereits 10 mal erklärt wie die Funktionalität Y funktioniert, und trotzdem stellt er alle paar Monate immer wieder die selbe Frage.

Statt sich zu ärgern sollten Sie vielleicht mal darüber nachdenken warum das so ist.

Die typische Reaktion ist “Schon wieder? Der versteht nichts”, aber eigentlich ist das Problem auf der anderen Seite. Ja genau, bei Ihnen. Wenn ein Kunde Feature Y nicht bedienen oder verstehen kann, dann haben Sie nicht genug über die User-Experience, das Feature selbst oder das Produkt allgemein nachgedacht.

Sehen Sie die Sache mal anders herum. Wir haben im Office eine Mikrowelle stehen, die wirklich niemand bedienen kann. Sogar wenn man es kurzzeitig versteht, vergisst man es beim nächsten Mal wieder. Man fragt sich wie diese Mikrowelle jemals das Designlabor, geschweige denn die Fabrikhalle verlassen konnte. Und doch dachte sich ein ganzes Team an Entwicklern, Produkt Managern sowie Designern (vermutlich waren das auch Techniker), dass das eine gute Idee ist.

Erwarten wir als Anwender nicht, dass die Dinge einfach zu bedienen und sofort verständlich sind?

Der User ist nicht an Komplexität interessiert.

Man kann sich schon gut vorstellen wie die Produktentwicklung abgelaufen ist und noch besser die Reaktionen des Teams auf etwaiges Kundenfeedback. “Ach die User, die verstehen nichts. Ist doch sonnenklar was die Tasten bedeuten”. Leider ist es nicht sonnenklar, was diese Tasten bedeuten. Vor allem ärgerlich wenn man durch experimentieren herausfinden muss, wie man die gerade eben gekaufte Lasagne aufwärmen kann.

Die gute Nachricht ist, dass wir eine zweite Mikrowelle in der Küche stehen haben, die wir auch hauptsächlich verwenden. Die Bedienung ist sehr einfach – mit ein, zwei Tastendrücken erledigt Sie bereits Ihre Arbeit.
Bei der zweiten Mikrowelle hat sich jemand über den “User” Gedanken gemacht, zumindest wirkt das so.

Aber jetzt wieder zurück zu unserem Ausgangsszenario. Genau, das mit dem Kunden, der noch immer nicht verstanden hat wie Funktionalität Y funktioniert.

Sinnvollen Feedback erkennen

Die bessere Reaktion wäre gewesen “Ach, ist das noch immer nicht klar genug? Da müssen wir noch nachbessern oder das ganze neu überdenken”.
Was aber vermutlich passiert, ist folgendes: “Diese User verstehen einfach nichts”. Dann dreht man sich um und diskutiert stundenlang was die “User eigentlich wollen”. Klingt als wäre das frei erfunden, aber so läuft Produktentwicklung in der Realität häufig ab.

Fragt man nach, wer denn diese sogenannten “User” eigentlich sind, erhält man so viele verschiedene Antworten wie die Anzahl der Personen im Raum.

Keine Sorge, ich werde Ihnen nichts über Personas erzählen, ich gehe davon aus, dass Sie welche entwickelt haben und wenn Sie es bisher nicht getan haben, sich dazu bewusst entschieden haben. Wenn nicht, dann würde ich Ihnen detaillierte Personas empfehlen, aber das nur so am Rande.

Wichtiger als Personas ist aber die Fähigkeit die richtigen Signale zu deuten. Das ist nicht einfach und braucht sowohl sehr viel Offenheit als auch einen klaren Fokus auf das Produkt, die Vision und das Ziel.
Genau dieser Kunde gibt Ihnen bereits wichtige Insights und Informationen über Ihr Produkt.

Ihre erste Reaktion ist eventuell gleich eine neue User-Story in das Backlog einzuwerfen.
Vergessen Sie mal die User-Stories in ihrem Backlog. Jeder kann User-Stories schreiben, vor allem jene in dem Format ich als X brauche Y damit ich Z machen kann.

Achten Sie lieber auf die Message, dahinter verstecken sich sehr interessante Details. Jemand sagt Ihnen gerade, dass dieses Feature nicht so funktioniert wie es angedacht war.

Die gute Nachricht ist, dass diese Funktionalität tatsächlich verwendet wird und nicht zu den anderen 80% der Features gehört, die niemals Gebrauch finden. Vor allem die Tatsache dass sie immer wieder zu Kundenfeedback führt, deutet darauf hin das sie gut in die 80/20 Regel reinfällt. Die 80/20 Regel besagt lediglich dass 80% der Benutzer nur 20% der Funktionalität verwenden. Und genau diese gilt es ja zu identifizieren.

Wenn Sie mal zu dieser Erkenntnis gekommen sind, stehen Sie dann aber vor weiteren, neuen Herausforderungen. Wie kommen Sie nun an die relevanten Informationen, die Ihnen weiterhelfen könnten bzw. was muss entweder an Feature Y oder an dem Workflow verändert werden?
Ist wirklich Feature Y das Problem oder bieten Sie einfach zu viele Optionen und Möglichkeiten an, die 1. Ihr User-Interface kompliziert machen (denken Sie an die Mikrowelle) und 2. die Kernfunktionalitäten überschatten?

Handlungen ableiten

Sie sehen schon, dass Sie nicht unbedingt komplizierte Meinungsumfragen durchführen müssen um herauszufinden was Ihre Kunden brauchen. Im Gegenteil, gerade solche Methodik führt häufig zu den falschen Ergebnissen. Schlussendlich können Sie nicht einfach fragen “Was brauchen Sie als Benutzer?”.
Der Benutzer will mit Ihrer Software möglichst einfach eine Aufgabe erledigen. Unsere Aufgabe als Produktentwickler wiederum ist es herauszufinden, was und wie sich diese mit einfachsten Mitteln erledigen lässt. Dabei genügt es eben nicht, die Welt aus Entwicklersicht zu sehen. Genau das führt häufig zu unbrauchbaren Produkten, weil sich das Team mit “Was-wäre-wenn-Fragen” anstatt mit dem “Warum” beschäftigt.

Bei 25th-floor stellen wir zuerst Fragen. Diese Fragen führen zu neuen, besseren Fragen und die wiederum führen dann zu ersten Lösungsansätzen. Das ist ein Prozess, der sich nicht einfach mit einzelnen Kundengesprächen und Brainstorming-Sessions abbilden lässt.

Die dabei entstehenden Lösungsansätze versuchen wir dann in der Realität zu testen. Zum Beispiel implementieren wir eine rudimentäre Funktionalität, ohne diese bis zum Ende durch zu denken. Wie auch? Wie können wir jene zu Ende denken. Gerade der agile Ansatz ermöglicht uns schnell Dinge auszuprobieren um an neue und bessere Fragen zu gelangen. Diese führen zu Erkenntnissen, die wiederum neue, nicht bedachte Funktionalitäten hervorbringen könnten. Frei nach dem Motto “Try – Learn – Adapt”.

User-Stories und Backlogs sind, aus meiner Sicht, nicht das fundamentale an der agilen Produktentwicklung, auch wenn es manche als die Grundlage sehen. Sie sind eine Implementierungsoption, um mit dem Kunden und dem Team auf einer einheitlichen Ebene zu kommunizieren. Viel interessanter ist die Ausgangshaltung, dass man das “Warum” verinnerlicht hat und das “Wie” auf einer Feedbackschleife basiert, die immer wieder aufs Neue auf Ausprobieren und daraus lernen abzielt.

Oder betrachten Sie es mal von diesem Blickwinkel. Bis der iPod veröffentlicht wurde, zeichneten sich die meisten MP3-Player dadurch aus, eine komplexe Bedienerführung und eine Vielzahl von Features zu besitzen. Sie unterschieden sich nur durch die Anzahl der Funktionalitäten voneinander, die meistens sowieso niemanden interessierten. Wir alle wollen den iPod für unseren Markt entwickeln.

Dafür braucht es Offenheit und eine Portion Selbstreflexion. Desto vorgefertigter Ihre Meinung über Ihr Produkt ist, vor allem wie diese vom Benutzer zu bedienen ist, desto schwerer wird Ihnen diese Art der Entwicklung fallen. Sie werden am Schluss vermutlich einen dieser vielen MP3-Player bauen.

Lassen Sie sich zumindest schrittweise auf die Idee ein, dass man nicht alles planen kann und dass manchmal ein halbleeres Backlog ein gutes Indiz ist, kein schlechtes. Damit sind Sie wirklich agil und schaffen Raum für Feedback, das wiederum in Ihren Produktentwicklungsprozess zurückfließt. Und vergessen Sie nicht, dass auch nicht vorhandenes Feedback eigentlich Feedback ist. Im Idealfall wird Sie dieser Kunde nie wieder fragen, wie Funktionalität Y eigentlich funktioniert.