Nutzer einfach zu fragen, was sie denn gerne hätten, ist wohl der schlechteste Ansatz in der Geschichte des Software Engineerings. Nutzer wissen nämlich nicht, was sie wollen. Es ist unser Job genau das raus zu bekommen. Um diese Frage nach den Nutzerbedürfnissen zu beantworten, bedarf es einer Methodik um Hypothesen systematisch auf ihren echten Nutzen für den User zu durchleuchten und zu überprüfen.

 

Der Nutzer weiss nicht, was er will, bis du es ihm zeigst

Wir kennen alle die Anekdote um Henry Ford, der gesagte hatte: ” Wenn ich die Leute gefragt hätte, was sie denn brauchen, hätten sie gesagt: “schnellere Pferde”. Wir Menschen haben Mühe Wünsche ausserhalb des uns bekannten Rahmens zu formulieren. Was wir nicht kennen, können wir auch nicht als Bedürfnis formulieren. Darum werden wir echte Innovationen kaum aus einer Serie von Nutzer-Interviews gewinnen können. Doch wie kommt man an genau diese Bedürfnisse heran? Wie schafft man Innovationen? Wie realisiert man Produkte jenseits der Rahmen, die wir kennen?

Wir müssen beobachten, ausprobieren, umsetzten und weiterentwickeln. Wir müssen systematisch “experimentieren”.

 

Systematische Nutzerexperimente

An einem Key Note Speech am Swiss Requirements Day formulierte Jan Bosch die These “Optimal User Experience trough Innovation Experiment Systems”. Er legte dar, dass Produkte nur eine erfolgreiche User Experience aufweisen können, wenn sie durch ständige, iterative Experimente entwickelt und weiterentwickelt werden.

Als User Centericity Experts kennen wir vielfältige Methoden, um ein systematisches “Experimentieren” umzusetzen. Die Hypothesen, die wir in der Nutzerforschung über die Bedürfnisse des Nutzers aufstellen, validieren wir bereits frühzeitig mit dem Nutzer z.B. über Prototypen. So können wir verschiedene Features ausprobieren und auf ihren Nutzungsgrad hin bewerten. Google hat in einer frühen Phase mit Nutzern die optimalen Farben für die jeweils erste Zeile eines Suchresultats getestet. Aus 50 verschiedenen Blautönen wurde anhand der Experimente das Blau gewählt, dass heute jedes Kind rund um den Erdball kennt. Wohl etwas übertrieben, aber der Ansatz stimmt.

 

Nach dem Deployment ist vor dem Deployment

Das systematische Exprimentieren geht aber nach dem Release erst recht los. Wir sollten die Akzeptanz des realisierten Features prüfen und Erkenntnisse in die Entwicklung der nächsten Features einfliessen lassen. Es entsteht ein Zyklus von Releases in kurzen Zeitabständen. Jan Bosch plädiert in seinem Vortrag für eine hohe Deployment Frequenz oder wie er es nennt “continious deployment”. Einzelne Features sollen zeitnah ausgerollt werden und sofort auf ihre Akzeptanz überprüft werden. Ein ähnliches Prinzip habe ich im Post “Das Schnellboot-Prinzip” beschrieben.

 

Speed up!

Um ein systematischen Experimentieren in dieser Form überhaupt umsetzen zu können, gibt es nur eine Devise für die Produktentwicklung: Speed up! Was früher mehrere Jahre dauerte, muss heute binnen weniger Monate über die Bühne gehen. In manchen Fällen reden wir sogar von Wochen. Time to market ist das Schlüsselwort.

Wenn wir denken, wir müssten in Klausur gehen und lange und fundiert an der ultimativen Lösung rumdenken, dann kommen wir eines Tages tatsächlich mit der brillanten Idee aus dem Kämmerchen heraus. Das Problem: unsere Idee interessiert mittlerweile niemanden mehr.

Entscheidend für die Entwicklungsgeschwindigkeit und den Innovationsgrad ist natürlich der Entwicklungsprozess. Um einen hohen Deployment-Zyklus aufrecht zu erhalten, ist ein agiles Vorgehen zwingend. Auch die Teamgrösse ist entscheidend. Kleine, selbstbestimmte und eigenverantwortlich handelnde Teams können in kurzer Zeit Innovation kreieren, umsetzen, testen und weiterentwickeln. Jeff Bezos prägte in diesem Zusammenhang den Begriff “2-Pizza Teams”.

 

Fazit

Weil der Nutzer von sich aus nicht weiss, was er braucht oder will, müssen wir es ihm als “User Centered Thinkers” aufzeigen. Wir müssen ihn verstehen, seine Motivationen kennen und seine Denkweise adaptieren. Mit diesem Wissen entwickeln wir Ideen, die seine Bedürfnisse nicht nur befriedigen, sondern darüber hinaus den Rahmen dessen, was er bisher kannte, sprengen. Echte Innovation kann erst dann entstehen, wenn wir sie gemeinsam mit dem Nutzer entwickeln und mit ihm ausprobieren.

Nutzer einfach zu fragen, was sie denn gerne hätten, ist wohl der schlechteste Ansatz in der Geschichte des Software Engineerings. Nutzer wissen nämlich nicht, was sie wollen. Es ist unser Job genau das raus zu bekommen. Um diese Frage nach den Nutzerbedürfnissen zu beantworten, bedarf es einer Methodik um Hypothesen systematisch auf ihren echten Nutzen für den User zu durchleuchten und zu überprüfen.