Kundenzentrierung in der Produktentwicklung wird schnell mehr zur Last als zum Erfolgsfaktor. Das passiert immer dann, wenn sich Teams davor scheuen, dass die Entwicklung gemeinsam mit ihren Kunden und Usern auch mal weh tun soll – und das gleich an zwei Stellen: Zum einen, wenn man ganz bewusst Ergebnisse zeigt, mit denen sie nicht komplett zufrieden sein sollen und zum anderen, wenn man bewusst nicht das tut, was ein User sagt.
Wie sieht es aus, wenn man vermeidet, dass es an diesen Stellen weh tut? User werden gar nicht erst gefragt, bevor man nicht angefangen hat zu entwickeln – schließlich darf man ja nicht mit leeren Händen ankommen. Oder auch: Reviews zum Produkt werden dann erst eingestellt, wenn man selbst sicher ist, dass es ist, was die User wollen – wäre ja sonst peinlich. Dann kommt meist jedoch heraus, dass die User ein bis einundzwanzig Aspekte eher schlecht finden. Und im schlimmsten Fall gipfelt diese Talfahrt dann darin, dass das User-Feedback relativ unreflektiert, schnellstmöglich umgesetzt wird. Nur um damit manchmal wieder gnadenlos danebenzulanden, weil die User eben doch nicht ganz genau das wollen, was sie gesagt haben. Doof.
Dabei wäre alles ein wenig weniger schlimm, wenn man einfach von vorneherein voll in diese „Schmerzen“ hineingeht: Ja, User werden mal unzufrieden sein. Und ja, User wollen letztendlich nicht immer, was sie sagen. Frei nach dem Motto „Pick your battles“ kann man jedoch gut beeinflussen, wann man mit diesen Themen im Entwicklungsprozess konfrontiert ist – und damit viel Mehrwert fürs Produkt generieren. Impulse, wie das funktionieren kann, finden sich beim Reinhören in den Podcast mit Pia Betton zum Thema User Centric Design. User Centric Design bedeutet eine Produktentwicklung schon mit den Nutzerbedürfnissen im Blick zu beginnen und die Nutzererfahrung auch konsequent im Mittelpunkt zu behalten. Pia Betton sieht dabei im Produkt-Design einen von drei wichtigen Pfeilern, die jede erfolgreiche Produktentwicklung braucht:
1. Das Produktmanagement, welches Bedarfe aufnimmt und Produkte vertreibt 2. die Entwicklung, welche im Falle von IT gut funktionierenden, fehlerfreien Code bereitstellt und 3. eben das Design, welches sicherstellt, dass das Ergebnis auch gut nutzbar ist. Heißt konkret an einem Beispiel aus dem Podcast: Es geht nicht nur darum, wenn man hungrig ist, eine tolle App zu haben, um Essen zu bestellen. Es geht auch nicht nur darum, dass die Bestellung ans Lieblings-Restaurant durchgeht. Es zählt eben auch ein großes Stück das Design, also dass der Bestellvorgang nicht 20 Minuten und mehrere graue Haare kostet.
Soweit so simpel. Und in dem, wie simpel es oft scheint zu erahnen, was ein User möchte, liegt auch ein Problem. Häufig überschätzt man im Produktteam, wie gut man die eigenen User oder auch Kunden kennen kann. Interviews, Prototypen oder Persona-Entwicklungen werden eingespart und durch eigene, isolierte Überlegungen ersetzt. Mit ihren Einschätzungen liegen die Teams dann meist dem auf, was in der Psychologie auch als „Curse of Knowledge“ bezeichnet wird: Das eigene Wissen und die Vertrautheit mit einer Sache abschalten geht einfach nicht ganz. Und selbst wer bewusst dran denkt, die eigene Einschätzung zum Produkt irgendwie um diesen Faktor zu korrigieren, liegt meist trotzdem ein gutes Stück daneben. Ist eben doch meist nicht so simpel, wie zu wissen, dass niemand 20 Minuten lang jeden Bestandteil des Salats inklusive Dressing einzeln auswählen will.
Das heißt also für die Praxis: Ohne Userfeedback liegt man eigentlich immer falsch. Beeinflussbar ist nur, wie viel Zeit man ins „falsch-liegen“ und damit weiterarbeiten investiert. Es muss sich also getraut werden auch früh mit Usern zu sprechen, wenn noch keine nutzbare Lösung da ist, die sie 100% zufrieden machen kann. Das dürfen dann auch Kritzeleien, krakelige Konzeptentwürfe und das explizite Anfragen von Kritik sein. Was früh in der Produktentwicklung zählt, ist eben noch nicht immer etwas zu liefern, was ein Userbedürfnis komplett befriedigt. Es geht darum, etwas zu liefern, womit beide Seiten das Bedürfnis besser verstehen. Und das ist bestenfalls beiden Seiten zu jeder Zeit komplett bewusst.
Praktisch ist dann allerdings auch klar: Selbst mit User-Feedback liegt man manchmal falsch. Ein Bedürfnis zu verstehen ist keine Sache einer einmaligen Abfrage. Es ist schließlich nicht die weltgegebene Aufgabe eines Users, zu wissen, was für ihn oder sie entwickelt werden soll. Es ist nicht mal die Aufgabe, ganz genau zu wissen, was sie selbst brauchen. Deshalb darf es auch mal „weh tun“, wenn man als Produktteam nicht exakt das umsetzt, was man als Feedback bekommt. Damit letztendlich trotzdem alle zufrieden sind braucht es aber – um Pia Bettons Worte zu nehmen – ganz viel Übersetzungsleistung.
Was in dieser Übersetzungsleistung alles drinsteckt – das geht vom Verständnis des Problems, zum Verständnis des Umfelds bis hin zum Ziehen von konkreten Konsequenzen im Produktentwicklungsteam. Und wem das noch zu theoretisch ist, der wird auch hierfür im Podcast einige Tipps und Tricks finden. Viel Spaß beim Hören!
