Du setzt dich in ein Restaurant. Noch bevor du die Speisekarte aufgemacht hast, kommt der Kellner vorbei und serviert dir Pasta. „Ich habe doch noch gar nicht beste…“, willst du sagen. Der Kellner zuckt mit den Achseln und sagt: „Ich gehe selbst oft essen. Ich weiß, was Sie wollen“. Zwei Monate später ist das Restaurant bankrott. Der Kellner wundert sich. Du nicht.
Du leitest ein Team. Ihr baut Software. Ihr habt einen Fachexperten dabei, der „weiß, was der Kunde will“. Vielleicht bist du selbst diese Person. Zwei Monate später floppt eure Software. Du wunderst dich. Du bist der Kellner geworden. Du bist nicht der User. Dein User ist es vielleicht auch nicht.
Jedem ist klar, dass das Restaurant mit diesem Vorgehen nicht erfolgreich sein kann. Wenn ich aber einem Entwicklerteam erzähle, dass das Team nicht der User ist, sieht es ganz anders aus. „Ich bin der User“. Diese Idee ist süßes Gift für das Produkt. Sie macht den Entwicklungsprozess einfacher. Das Team muss nicht erst mit dem User sprechen. Es kann einfach entwickeln. Die Argumentation ist analog zum Kellner, der keine Bestellungen aufnimmt und einfach nur noch serviert, um Zeit zu sparen. Der Gedanke ist aus vier Gründen falsch und lässt sich durch drei UX-Research Methoden korrigieren.
Du warst vor Jahren der User
Je länger es her ist, dass Du der User warst, umsowahrscheinlicher ist es, dass Du im besten Fall mittelmäßige Software bauen kannst. Software-Features, die Dich damals begeistert haben, sind in moderner Software absolute Basics. Hier zeigt Steve Jobs 2007 ein revolutionäres Feature; man kann durch Listen scrollen. Das Publikum applaudiert und johlt. Das, was Du für revolutionär hältst, ist sehr wahrscheinlich Grundvoraussetzung heute und wird niemanden hinter dem Ofen hervorlocken.
Die Lösung: Mach lieber eine KANO-Analyse, um aufzudecken was Deine User begeistert und was absolute Mindestanforderungen an das Produkt sind.Wie das funktioniert, kannst du hier nachlesen.
Du warst gar nicht der User
Wenn der Kellner in einem italienischen Restaurant gerne essen geht, aber bei einem mexikanischen Restaurant arbeitet, ist das schlecht. Noch schlimmer wird es, wenn das italienische Restaurant in der Stadt liegt, und das Restaurant mit mexikanischer Küche außerhalb der Stadt. Auf dem Land ärgert sich der Kunde über wenige Parkmöglichkeiten. Der Kunde in der Stadt hat nicht mal ein Auto. Das, was den User nervt, ist stark von seinem Umfeld und seiner Situation getrieben. Du kennst nur dein Umfeld und deine Situation, nicht den Kontext der User.
Die Lösung: Der beste Weg, das Umfeld und die Situation deines Users kennenzulernen ist, ihn bei seiner Arbeit zu beobachten. Der zweitbeste Weg ist ein Interview.
Du hast nur User-Klassensprecher
Teams verlassen sich gerne auf leicht erreichbare Repräsentanten der User, statt auf den User selbst. Vertriebler, Poweruser oder Fachexperten. Fachexperten und Poweruser können aber nur andere Fachexperten und Poweruser repräsentieren. Der Großteil der User ist weder Fachexperte noch Poweruser. Er ist User. User finden dein Interface an Stellen verwirrend, an denen Poweruser und Fachexperten noch mehr Details einfordern. Fachexperten und Poweruser fordern Features, die dem User egal sind. User wollen Schritte überspringen. Fachexperten wollen alles sehen. Vertriebler wollen möglichst alle Wünsche der Kunden erfüllen. Aber das, was sich der User wünscht, ist nicht das, was der User braucht.
Die Lösung: Schau Usern beim Arbeiten zu. Vor allem denen, die sagen sie seien zu unerfahren, um Feedback zu geben.
Du wirst nicht dafür belohnt, wenn es dem Kunden schmeckt
Wenn du Teil einer großen Firma bist, die dich dafür belohnt, Features zu produzieren, dann bist du der Kellner, der dafür belohnt wird, Gerichte zu servieren. Du weißt unter Umständen sogar, dass der Kunde dieses Gericht nicht bestellt hat oder es ihm nicht schmeckt. Du würdest es auch gerne ändern, aber dafür wirst du nicht bezahlt. Jedes Mal, wenn du zu einem Tisch zurückkehren würdest, um das gewollte Gericht zu servieren, wirst du vom Management dafür getadelt. Du sollst Features produzieren. Dann stellt keiner Fragen. Wenn Du versuchst die Kunden zufriedenzustellen, gerätst du unter Rechtfertigungsdruck.
Die Lösung: Fokussiere dich auf Outcomes, nicht Outputs. Features und Services sind Outputs. Das, was diese Features und Services erreichen sollen sind die Outcomes. Wenn du Erfolg daran misst, dass ein Feature fertig ist, fokussierst du dich nur auf Outputs. Aber dabei ignorierst du, ob das Feature überhaupt sein Ziel erreicht. Ein Feuerwehrmann, der sich nur auf seine Outputs, statt auf seine Outcomes konzentriert, rollt alle Schläuche aus, kontrolliert aber nie, ob er tatsächlich das Feuer gelöscht hat.
Was sollte ich stattdessen tun?
Was solltest du also stattdessen tun? Sprich mit allen Usern, nicht nur den Fachexperten und denen, die auf dich zukommen. Noch besser, schau ihnen beim Arbeiten zu, statt über die Arbeit zu sprechen. Statt User zu fragen, welche Wünsche sie haben, schau dabei zu. Du wirst mit einer Fülle an Problemen zurückkehren, die es zu lösen gilt und Features verbessern oder bauen, die dem User helfen. Wenn du diese Features priorisieren musst, mach eine KANO-Analyse, statt die User direkt zu fragen.
