tl;dr: Hör auf, Leute zu fragen, ob sie dein Ding toll finden, um dann überrascht zu sein, wenn sie es nicht benutzen. Exploration ≠ Testing. Meinung ≠ Verhalten. Zustimmung ≠ Evidenz. Und eine Hypothese ist erst dann wirklich interessant, wenn du vorher weißt, was dich dazu bringen würde, sie aufzugeben. 

Validieren ist ja so ein Wort, das im Produktalltag ständig benutzt wird und trotzdem oft ziemlich schwammig ist. In der Praxis heißt „wir validieren unsere Idee“ nämlich meistens: Wir gehen mit einer Idee in einen Test oder in ein Interview und kommen mit einem grünen Haken zurück. Bestätigung eingesammelt, check, weiter geht's im Sprint. Willkommen in der Selbstvergewisserungs-Falle, im Fachjargon bekannt als Confirmation Bias.

Research kann naturgemäß zwei Dinge, nämlich Neues entdecken und bestehende Annahmen prüfen. Meinungen, Erfahrungen und sogar Bauchgefühle können dabei wertvolle Ausgangspunkte sein!  Das Problem beginnt aber, wenn wir beides vermischen, also wenn wir diese Meinungen anschließend als Beleg für unsere Hypothese verwenden.

No pain, no gain, hier stimmt das ausnahmsweise.

Zustimmung bekommst du meist sehr leicht von vielen Menschen, die einfach höflich sein wollen oder sich die Idee grundsätzlich vorstellen können. Ob eine Idee tragfähig ist, zeigt sich aber erst an passender Evidenz, also an tatsächlich beobachtbarem Verhalten, an konkreten Erfahrungen oder an einem Test, bei dem Menschen tatsächlich etwas tun müssen. Das kann wehtun - und genau deshalb bringt es dich weiter.

Erst erkunden, dann prüfen

Research in der Discovery hat also mindestens zwei unterschiedliche Aufgaben:

1. Exploration: Probleme: Bedürfnisse und neue Perspektiven und Möglichkeiten erkunden und verstehen und daraus Hypothesen entwickeln.
2. Evaluation/ Bewertung: Diese Hypothesen mit einer passenden Methode prüfen.

Der Fehler entsteht oft, wenn wir mit einer Meinung oder Überzeugung ins Gespräch gehen und mit deren Bestätigung wieder herauskommen - obwohl wir noch gar nicht geprüft haben, was Menschen tatsächlich tun.

Ein Beispiel: Ihr glaubt: „Unsere Nutzer*innen brauchen einen Dark Mode”. 

Dann fragt ihr ein paar Nutzer*innen in Interviews: „Würdet ihr denn einen Dark Mode nutzen, wenn wir einen hätten?“ (Ich wurde leider bereits öfter als mir lieb ist, Zeuge von genau solchen Fragen!) Einige sagen dann: „Ja, klar.“ - und ihr geht davon aus, dass diese Annahme bestätigt ist: Der Fehler liegt also darin, dass ihr eine geäußerte Zustimmung als Beweis für ein tatsächliches Bedürfnis oder ein späteres Verhalten interpretiert. Die Meinung wird also nicht mehr als Ausgangspunkt für eine Hypothese behandelt, sondern bereits als Beleg für genau diese Hypothese.

Vier Regeln, die dir helfen, aus der Bestätigungsfalle rauszukommen 

1. Sammle unterschiedliche Perspektiven

Am liebsten auch widersprüchliche. Ja, ich weiß, das ist schwer, denn wir mögen Beifall und Zustimmung, wenn uns wer widerspricht, fühlt sich das zunächst oft wie Kritik an uns selbst an. Das heisst in der Praxis: Sprich nicht nur mit deinen liebsten Kund*innen. Menschen, die euch und euer Produkt ohnehin mögen, liefern wichtige Perspektiven – aber wahrscheinlich nicht die stärksten (und wertvollen) Gegenargumente.

Sprich auch mit Menschen,

• die abgesprungen sind,
• die kündigen wollen,
• die eure App einmal geöffnet und danach nie wieder benutzt haben,
• die das Produkt nutzen müssen, obwohl sie es nicht freiwillig gewählt haben,
• oder die eine Alternative gefunden haben.

Auch deren Erfahrungen sind keine Beweise für irgendwas, aber sie können Annahmen infrage stellen, die mit euren zufriedenen Nutzer*innen nie sichtbar geworden wären.

2. Frag, wer im Raum fehlt

Eine Annahme wirkt manchmal nur deshalb gut abgesichert, weil niemand anwesend ist, der sie infrage stellen könnte.: 

Ihr testet mit euren Power-Nutzer*innen. Ihr befragt Menschen, die euch ohnehin schon toll finden. Ihr verlasst euch auf die Perspektiven eures Teams - vielleicht eines Teams, das gesellschaftlich ziemlich homogen ist. Natürlich bestätigt sich dann einiges. 

Aber wer nutzt euer Produkt, weil es notwendig ist und nicht, weil die Person es möchte? Wer hat Deutsch nicht als Erstsprache? Wie wirkt das auf neurodivergente Menschen? Was passiert, wenn das jemand in einer stressigen Umgebung nutzt? Wer ist von der Entscheidung betroffen, ohne selbst Nutzer*in zu sein? Wer muss die Folgen eurer Entscheidung tragen, ohne in der Research überhaupt vorzukommen? 

Es fehlt auch nicht immer nur eine bestimmte Gruppe, die das Produkt/den Service selbst nutzt, manchmal fehlen auch andere Rollen: z.B. Angehörige, Support-Mitarbeitende oder einfach Menschen, die mit den Konsequenzen eures Produkts leben müssen. Auch das gehört zunächst zur Exploration - nur mit einem größeren Radius, aber es ist eben auch ne Riesenchance, weil hier Perspektiven reinkommen, die man sonst nie gehört hätte!

Oft ist eben nicht entscheidend, wer in der Research auftaucht, sondern wer systematisch nicht auftaucht. 

3. Sei ehrlich zu dir selbst und sag laut, wie sicher du dir bist

Bevor ihr testet, schaut euch mal eure Ideen und die Herkunft dieser an. Kommt eine Idee aus einem Kundengespräch von vor zwei Jahren, an das sich noch drei Menschen im Team erinnern? Aus zehn aktuellen Interviews? Aus Nutzungsdaten? Aus einem technischen Problem? Oder aus einem Satz, der in einem Meeting überzeugend klang?

All diese Annahmen werden im Alltag oft mit derselben Selbstsicherheit vorgetragen. Ihre Grundlage ist aber eben nicht dieselbe.

Schreibt deshalb einmal nebeneinander auf:

• die Annahme,
• ihre Quelle,
• die vorhandene Evidenz,
• eure Einschätzung, wie sicher ihr euch dazu seid,
• und was passieren müsste, damit ihr sie aufgebt.

Dafür reicht eine einfache Liste. Ihr seht dann schnell, wo das größte Risiko liegt: meist nicht dort, wo am meisten diskutiert wird, sondern dort, wo am wenigsten dahintersteckt.

Wenn ihr das nur intern macht, könnt ihr euch dabei natürlich immer noch selbst belügen. Eine subjektive Sicherheit ist keine Evidenz. Trotzdem ist eine ehrliche Einschätzung einfach besser als eine Annahme, die unsichtbar bleibt. Diese Methode ist auch bekannt als Kopf-aus-dem-Sand-ziehen. Funktioniert besonders gut mit einer externen Person dabei. Ich kenne da jemanden. 

Ich glaube sogar, das ist der wichtigste erste Schritt, und dabei technisch so einfach - emotional etwas  weniger und genau deswegen superwichtig! Am Ende wisst ihr besser, welche Idee/Annahme zuerst, z.B. einen echten Test oder weitere Exploration verdient.

4. Teste gegen passende Evidenz und nicht gegen weitere Meinungen

Hier passiert der eigentliche Fehler. Ihr habt aus vielen Ideen interessante Hypothesen gesammelt und sauber priorisiert. Dann macht ihr genau dasselbe noch einmal: Ihr fragt Menschen nach ihrer Meinung dazu und nennt das Testen oder “validieren”.

First Rule of Fragetechnik: Verlass dich nie allein auf die Frage: „Würdest du das nutzen?“ Diese Frage ist eine Falle und zwar vor allem für dich und dein Produkt, denn Menschen antworten auf hypothetische Fragen häufig zustimmender, als ihr späteres Verhalten erwarten lässt. Die Leute machen das nicht absichtlich, weil sie z.B. lügen, das Ding ist einfach: Sich etwas vorzustellen ist leichter, als es tatsächlich zu tun. Psycholog*innen nennen das Intention-Behavior-Gap, denn wir sind ziemlich gut darin, uns unser zukünftiges Verhalten auszumalen, und ziemlich schlecht darin, es tatsächlich zu zeigen. Im Kopf sind wir quasi alle die Version von uns, die täglich Sport macht und nie genervt und fluchend in die Tasten haut oder den Drucker anbrült.

So geäußerte rein verbale Absichten können ein Ausgangspunkt für weitere Forschung sein. Sie sind aber kein belastbarer Nachweis dafür, dass ein Verhalten tatsächlich eintreten wird.

Frag deshalb bereits aufgetretenes Verhalten ab und bohre ab da tief:

• „Wann ist dieses Problem zuletzt konkret aufgetreten?“
• „Wie hast du es damals gelöst?“
• „Kannst du mir zeigen, wie du heute dabei vorgehst?“
• „Was hat dich davon abgehalten, es zu nutzen?“

Und wenn es um eine konkrete Nutzungshypothese geht: Beobachte, was Menschen tun. Oder gestalte einen Test, in dem sie unter möglichst realistischen Bedingungen tatsächlich etwas tun müssen. 

Je realer die Nutzungsbedingungen, desto besser! Und die Methode muss vor allem zur Hypothese passen. Für die tatsächliche Nutzung können Feldbeobachtung, Logdaten oder ein Verhaltensexperiment sinnvoll sein, es kommt drauf an. Für Verständlichkeit kann ein Usability-Test die bessere Wahl sein. Für Motive, Erfahrungen und Bedeutungen sind qualitative Gespräche weiterhin wichtig, denn sie helfen uns dabei, neue Perspektiven und Chancen zu entdecken.

Okay. Aber was müsste passieren, damit ihr eure Idee wieder verwerft?

Bis hierhin ging es vor allem darum, wie wir verhindern können, dass Research zur Selbstvergewisserungsmaschine wird. Aber selbst wenn wir unterschiedliche Perspektiven einholen und die passende Methode wählen, bleibt noch eine ziemlich wichtige Frage: 

Woran würden wir erkennen, dass unsere Annahme falsch war?

Aus einer Idee wird eine prüfbare Hypothese

Nehmen wir wieder unsere Annahme: „Unsere Nutzer*innen hätten gerne einen Dark Mode.“

Das ist erstmal eine interessante Beobachtung oder Präferenzannahme. Als Testhypothese ist sie aber noch ziemlich vage. Vor allem ist noch nicht klar, was passieren müsste, damit wir diese Annahme wieder aufgeben, und genau das ist wichtig!

Jahrhundertelang ging man in Europa davon aus, dass alle Schwäne weiß sind - bis in Australien schwarze Schwäne entdeckt wurden. Zack, Theorie tot. Ein einziges Gegenbeispiel reichte aus, um diese universelle Aussage zu widerlegen.

Eine Hypothese wird dann interessant, wenn vorher klar ist, was sie widerlegen würde.

Bei unserer Dark-Mode-Annahme ist das etwas komplizierter. Sie behauptet ja nicht, dass alle Nutzer*innen einen Dark Mode brauchen oder nutzen würden. Wir erwarten eher, dass sich bei einer bestimmten Gruppe oder unter bestimmten Bedingungen ein Effekt zeigt. Ein einzelner Mensch, der den Dark Mode ignoriert, widerlegt die Hypothese deshalb noch nicht. Entscheidend wäre, ob sich der erwartete Effekt insgesamt nicht zeigt.

Die ursprüngliche Annahme „Unsere Nutzer*innen hätten gerne einen Dark Mode“ hat bislang noch kein klares Gegenkriterium. Jemand kann im Interview sagen, dass er keinen Dark Mode möchte. Oder ihn im Test unnötig finden. Dann steht aber weiterhin erstmal nur eine Meinung gegen eine andere - und da liegt das Problem: Ob jemand dazu nickt oder den Kopf schüttelt, sagt uns eben noch nicht zuverlässig, was diese Person später tatsächlich tun wird.

Aus „Unsere Nutzer*innen hätten gerne einen Dark Mode“ müsste also eine konkrete Hypothese werden. Zum Beispiel: „Wenn der fehlende Dark Mode tatsächlich ein relevantes Problem ist, sollten Menschen, die unser Produkt regelmäßig abends nutzen, den Dark Mode aktivieren und dadurch unter diesen Bedingungen häufiger oder länger nutzen“

Jetzt können wir festlegen, was wir beobachten müssten, um diese Annahme zu stützen – oder eben infrage zu stellen:

• Wird der Dark Mode tatsächlich aktiviert?
• Verändert sich die Nutzung in den Abendstunden?
• Gehen weniger Menschen abends während der Nutzung verloren?
• Kehren sie häufiger zurück?
• Berichten sie von geringerer Augenbelastung?
• Zeigt sich ein Effekt im Vergleich zu einer passenden Kontrollgruppe ohne Dark Mode?

Wenn wir alle diese Fragen mit Ja beantworten, ist das ein gutes Zeichen für diese Hypothese – aber noch kein endgültiger Beweis. Vielleicht hat sich gleichzeitig noch etwas anderes verändert, oder Menschen nutzen das Produkt abends grundsätzlich anders als tagsüber. Schaut deshalb auch, ob es andere plausible Erklärungen gibt.

Eine gute Hypothese sollte also so formuliert sein, dass man sie durch Beobachtung abschwächen oder widerlegen kann.

Long story short: Für gute Discovery brauchen wir beides:

• offene Exploration, um Probleme, Perspektiven und Ideen zu verstehen;
• und gezielte Tests, um herauszufinden, welche unserer Annahmen unter welchen Bedingungen durch Evidenz gestützt werden – und welche nicht.

Exploration hilft uns also nicht dabei, möglichst viele grüne Haken für unsere Ideen einzusammeln. Sie hilft uns dabei, überhaupt bessere Fragen und Hypothesen zu entwickeln und das Testing ist nicht dazu da, möglichst viele Menschen zum Nicken zu bringen, sondern um herauszufinden, ob unsere Annahmen auch dann noch funktionieren wenn sie auf etwas treffen, das sie theoretisch kaputtmachen könnte.

Nur bitte, bitte nicht im selben Schritt.

Artikelbild entstand aus „Die Claque“ in Schwetzingen von Guido Messer https://de.wikipedia.org/wiki/Datei:20131118Claque_Schwetzingen1.jpg