Design-Thinking ist nicht evolutionär

Die Menschen, die Design-Thinking »als Bob Ross« erklären – also als ein einfach abzuarbeitendes Rezept, das durch Tricks zu einem anschaulichen Ergebnis führt – behaupten man müsse viele unterschiedliche Ideen verfolgen. Auf der Ebene der Ideen gibt es unterschiedliche Erhebungen. Diese Erhebungen sind die Ideen. Höhere Erhebungen sind bessere Ideen als niedrige. Man »wandert« also in dieser Ideenebene herum bis man an eine Erhebung (eine Idee) anstößt. Jetzt forscht man weiter an dieser Idee, verfeinert sie, probiert sie aus, integriert. Auf diese Weise wandert man »diesen Berg« hinauf. Solange, bis man am Gipfel ankommt, am Ende der Idee. Mehr geht nicht mehr. Die Idee ist vollkommen ausgereizt.

Wenn man Pech hat, dann ist diese Idee keine gute, also ein »niedriger Berg«. Dabei wäre nebenan ein höherer gewesen. Aber den erreichen wir nicht mehr, denn dann müssten wir uns wieder zurückentwickeln (den Berg hinunter) und dann am anderen Nachbarberg wieder hinauf. 

Daher, so diese »Experten« weiter, dürfe man niemals der ersten Idee folgen, sondern müsse sie verwerfen und andere Ideen finden. Viele davon. Das sind alles die Basislager dieser Berge. Wenn man alle Basislager gefunden hat, dann entscheidet man (im Team!) welcher Berg »bestiegen« werden soll – soweit die Theorie der Nicht-Designer.

Freilich, um diese Anzahl Basislager zu finden, nimmt man sich nicht beliebig viel Zeit, sondern macht die Zeit knapp (Achtung: Ironie). Auf diese Weise, so meint man, findet man schnell die wichtigen Berge. Keine Ahnung, warum das Hetzen ein Vorteil sein soll, das wissen die angelernten Design-Thinker.

Café Communications hat dazu ein Experiment durchgeführt, das anschaulich zeigt, welchen Effekt »Time Boxing« tatsächlich hat: der Film Deadlines.

Man entscheidet also erst nach Vorliegen vieler Ideen, welche die beste ist und entwickelt die dann weiter. Damit erhofft man sich den höchsten Berg zu erwischen und nicht in einer ungünstigen Sackgasse (einem niederen Berg) stecken zu bleiben. Denn wir können ja nicht mehr zurück, wenn wir einmal eine Richtung eingeschlagen haben – oder?

Das erinnert mich an Richard Dawkins Vortrag, in dem er über die Evolution des Auges (ab 23:40) vorträgt. In diesem sensationellen Vortrag aus 1991 erklärt er uns, wie die Evolution in Jahrtausenden unser Auge entwickelt hat und warum unterschiedliche Spezies unterschiedliche Augen haben und nicht alle gleich gut sind. Weil die Evolution sich nicht zurückentwickeln kann, sie kann einen einmal eingeschlagenen Weg nicht zurückentwickeln und dann die andere Abzweigung nehmen (siehe bei Minute 28:30). Damit evolutioniert sich ein Organ in eine Richtung und wenn es das Maximum erreicht hat, dann ist es zu Ende. Das Auge des Nautilus kann nicht so gut werden wie das von uns Menschen. Der »Berg« des Nautilus Auges ist niedriger als der unserer Augen.

Aber (1.), wir sind nicht »die Evolution«! Wir probieren nicht zufällig irgendetwas aus und nehmen hin, was herauskommt. Wenn wir Dinge erfinden, dann absichtsvoll und mit bewußter Entscheidung. 

(2.) Wir haben Erfahrung! Wir können uns im Vorhinein den Berg aussuchen. Wir ahnen meistens welcher Berg höher ist und ob eine Idee verfolgenswürdig ist. Das gelingt mit Lebenserfahrung (= Intuition). 

Und (3.) – das ist entscheidend – wir müssen uns nicht zurückentwickeln! Wenn wir am Ende einer Idee erkennen, dass der Nachbarberg (die Nachbar-Idee) besser ist, dann »hüpfen« wir auf den anderen Berg und entwickeln dort weiter. Wir können aus der einen Idee so viel lernen, dass wir den anderen Berg zur Hälfte schon erledigt haben.

Wir können am »Mount Improbable« gelegentlich auch das »sheer luck cliff« hinaufspringen (ab Minute 15:00), wir (Designer, Wissenschafter, Forscher) nutzen dabei diese Erfahrung und Intuition; es ist eine Frage der aktivierten selektiven Wahrnehmung und der zugelassenen Serendipität.

Wir sind Feuerwehrleute

Wir agieren im Design so wie erfahrene Feuerwehrleute. Die kommen auch nicht zur Brandstelle und starten ein Brainstorming, clustern die Ideen, sortieren diese rasch in einem Effort-Impact-Diagramm und probieren dann mit der bestgereihten Idee den Brand zu löschen. Würden die so vorgehen, ist das Haus abgebrannt, bevor sie den Brand angreifen.

Was machen sie stattdessen? Sie sondieren den Status des Brands und Kraft ihrer Erfahrung wählen sie die erstbeste Idee, mit der sie den Brand unter Kontrolle bringen könnten. Dann stürmen sie los und versuchen es. Das ist sozusagen der Prototyp der Feuerwehr. Im Idealfall geht die Strategie auf und der Brand kommt unter Kontrolle. Im ungünstigen Fall gelingt es nicht, die Feuerwehrleute kommen zurück, berichten über neue Erkenntnisse und haben daraufhin eine neue Idee, die sie sogleich wieder ausprobieren. Das geht blitzschnell, aber wohl überlegt, mit viel Erfahrung.

Analog ist es im Design. Wir wählen mit Erfahrung jene Idee aus, die uns am besten für die Lösung des vorliegenden Problems erscheint. Wir prototypisieren sie, testen den Lösungsansatz mit echten Nutzern. Kommen diese damit zurecht, dann sind wir fertig, scheitern die Nutzer an der Aufgabe, ersinnen wir mit den durch den Test erhaltenen neuen Erkenntnisse neue Ansätze. Von »fail often« als Ziel, kann keine Rede sein. Je schneller wir fertig sind, desto lieber. »Fail early« ist auch kein Ziel. Das passiert eventuell nur deshalb, weil wir unsere Thesen frühzeitig testen. Wenn wir uns geirrt haben in unseren Annahmen und es keine ideale Idee ist, dann scheitern wir damit. Doch haben wir ja Erfahrung und Intuition, wir müssen keine evolutionäre zufällige Mutation probieren. Es kommt gelegentlich auch vor, dass wir mit dieser Intuition sofort das passende Ergebnis generieren. Der testende Nutzer würde es beweisen.

»Fail early, fail often« heißt also keineswegs, dass wir im Design-Thinking danach streben, schnell und häufig mit unseren Lösungen zu scheitern. Es wurde ursprünglich etwas unglücklich (vielleicht auch zu reißerisch formuliert). 

In Wahrheit bedeutet es, (a) man möge frühzeitig testen, so früh als möglich, um eigene Denkfehler, die bei uns Menschen immer vorkommen, frühzeitig aufzudecken. Man möge sich weiters nicht davon entmutigen lassen, wenn eine Idee (ein Prototyp) nicht erfolgreich ist, sondern diese Fehlschläge als Erkenntnisgewinne verbuchen. Dieser Spruch soll uns ermutigen, mit Teillösungen unsere Ansätze zu verifizieren. Wir sollen es uns zutrauen, auch mit einer noch nicht bis ins Detail entwickelten Lösung Nutzer zu konfrontieren. Je kleiner diese Schritte sind, desto weniger Annahmen sind notwendig. Wir hanteln uns Schritt für Schritt von einer Annahme (die wir im Test bestätigen lassen) zur nächsten.

Wir testen also so früh als möglich und erklimmen den für den Moment besten, den am höchsten erscheinenden Berg. Sehen wir am Gipfel stehend einen idealeren, höheren Berg, dann springen wir rüber. Wir können eine einmal bei einer Abzweigung getroffene Entscheidung revidieren. Je früher wir den Fehler erkennen, desto weniger weit müssen wir zurücklaufen und desto günstiger wird die Entwicklung. Designer sollten so früh als möglich, am besten bei der Produktidee, involviert werden (vgl. »zumtobel: herbert resch über design als strategie« in Greger, Rudolf. Design im Marketing: Mittel zum Zweck. 1. Aufl. Wien: echomedia buchverlag, 2009.).

Wir sind nicht die Evolution, die alles blind ausprobiert, sondern wir können bewusst aussuchen. Das macht unsere Erfahrung. Wir scheitern, wenn es notwendig ist, aber wir scheitern nicht, um des Scheiterns willen, schon gar nicht häufig. Wir probieren nichts aus, von dem wir schon wissen, dass es nicht gelingt, nur um einem Prozess zu folgen. Wir erkennen den für den Moment und die gegebenen Umstände (Ressourcen, Nachfrage, MAYA*) besten (höchsten) Berg und erklimmen ihn so schnell als möglich. Keineswegs gehetzt und unter Zeitdruck, sondern mit Besonnenheit und Überlegung. Wir treffen Annahmen und verifizieren sie unter möglichst realen Bedingungen (indem echte Nutzer mit Prototypen unterschiedlich detailierter Ausarbeitung hantieren). Wir beobachten und lernen daraus. Wir interpretieren das Verhalten, wir legen es aus (Keyinterpreter) und wir nutzen unser »abduktives Schließen«. Darüber berichte ich demnächst.

*und wenn Sie wollen auch über MAYA – wollen Sie mehr darüber erfahren?

Also published on Medium.