Was ist eine Discovery-Phase und wie läuft sie?

Was ist eine Discovery-Phase?

Maria Rosala von NN/g definiert Discovery als vorbereitende Phase des UX-Design-Prozesses, die den Problemraum erforscht. In dieser Phase rahmen Sie das zu lösende Problem und sammeln genug Belege, um über den nächsten Schritt zu entscheiden.

Man spricht auch von Erkundungsphase. Produktteams nennen dieselbe Arbeit oft „Product Discovery“. Der Name ändert sich, die Frage bleibt: Lösen wir das richtige Problem?

Das wichtigste Ergebnis der Discovery ist eine Entscheidung. Laut GOV.UK Service Manual entscheidet das Team am Ende dieser Phase, ob es in die nächste Phase geht, die Alpha.

Wann braucht man eine Discovery?

Laut Rosala braucht es eine Discovery immer dann, wenn es viele Unbekannte gibt. Auch wenn sich das Team über die Ziele nicht einig ist, hilft sie.

Typische Auslöser bei Rosala sind: ein neuer Markt, eine Fusion, eine neue Regulierung, eine neue Unternehmensstrategie. Auch Probleme, die seit Langem ungelöst sind, stehen auf der Liste, etwa dauerhaft niedrige Verkäufe. Eine Bank, die wegen einer neuen Regulierung ihren Kundenablauf ändern muss, ist ein typisches Beispiel.

Trotzdem lassen manche Organisationen diese Phase ganz weg. In einer NN/g-Umfrage vom Oktober 2019 mit 436 Personen nannten 35 % der Befragten aus Organisationen ohne Discovery Zeitdruck als Grund. Die Stichprobe ist nicht zufällig, lesen Sie die Anteile deshalb als Tendenz.

Für agile Teams fasst Anna Kaley von NN/g ihre Empfehlung kurz: „scale it, not skip it.“ Lassen Sie die Discovery also nicht weg, verkleinern Sie sie. Kaley empfiehlt, kurze Forschungsschritte auf ein oder zwei kritische Fragen zu begrenzen.

Das Ziel der Discovery

Rosala erwartet von einer Discovery vier Dinge:

• Nutzer, ihre Bedürfnisse und die Wirkung des Problems auf sie verstehen.
• Ursachen, Ausmaß und Chancen des Problems verstehen.
• Bestehende Geschäftsprozesse, Lösungen und verfügbare Technik verstehen, also die Einschränkungen.
• Mit Stakeholdern ein gemeinsames Bild davon schaffen, welches Ergebnis gewünscht ist und wie Erfolg aussieht.

GOV.UK teilt Einschränkungen in zwei Arten. Harte Einschränkungen wie Gesetze ändern sich kaum. An weichen Einschränkungen wie bestehenden Prozessen arbeiten Sie, um sie zu ändern.

Eines tun Sie nicht. Der Satz von GOV.UK ist klar: „You should not start building your service in discovery.“ In der Discovery beginnt niemand, das Produkt zu bauen.

Was in der Discovery-Phase passiert

Die Reihenfolge hängt vom Projekt ab. Ich gehe meist in dieser Reihenfolge vor, weil jeder Schritt die Fragen des nächsten schärft.

Ziel und Problembeschreibung

GOV.UK empfiehlt, zuerst ein Ziel für die Discovery festzulegen. Das Ziel bestimmt den Umfang und sagt, wann die Arbeit fertig ist.

Oft kommt das Team schon mit einer fertigen Lösung: „Bauen wir einen Chatbot in die App.“ GOV.UK empfiehlt, diese Lösung zu hinterfragen und als Problem neu zu formulieren. Auch Rosala rät, vor der Forschung einen Problemsatz zu schreiben und keine Lösung hineinzulegen.

Stakeholder-Interviews

Stakeholder ist jede Person, die ein Interesse am Projekt hat oder mit der Sie zusammenarbeiten müssen, um die Arbeit abzuschließen. Sarah Gibbons von NN/g empfiehlt, den Leitfaden um vier Themen zu bauen: Erfolgskriterien, Prioritäten, Geschichte und Fachwissen, Prozess und Arbeitsablauf.

Die wertvollste Frage ist für mich: „Haben Sie das schon einmal versucht, und warum hat es nicht geklappt?“ Gibbons empfiehlt, Interviews einzeln zu führen und am Ende zu fragen: „Mit wem sollte ich noch sprechen?“ Je früher, desto besser.

Vorhandene Daten und Analytics

Schauen Sie auf das, was Sie haben, bevor Sie neu forschen. Mayya Azarova von NN/g nennt das Sekundärforschung (secondary research) und sieht sie als üblichen ersten Schritt gründlicher Forschung.

In Organisationen gibt es meist alte Forschungsberichte, Ergebnisse von Beratern, Protokolle aus dem Kundenservice und Suchprotokolle. Ich ergänze Analytics: Auf welcher Seite wird abgesprungen, bei welchem Schritt das Formular abgebrochen? Auch Sitzungsaufzeichnungen aus Werkzeugen wie Clarity und Hotjar helfen hier.

Azarova warnt auch: Sekundärforschung ersetzt keine Primärforschung. In meiner Erfahrung sagen Daten, was passiert, aber oft nicht, warum.

Nutzerforschung

Nutzerforschung in der Discovery ist erkundend. Als häufigste Methoden nennt Rosala Nutzerinterviews, Tagebuchstudien und Feldforschung. Für eine größere Gruppe erwähnt sie auch Umfragen. Laut Rosala prüft eine Discovery meist keine Hypothese und bewertet keine Lösung.

Am häufigsten greife ich zum Nutzerinterview. Ich höre zu, wie die Person die Aufgabe heute erledigt, wo sie hängen bleibt und welche Notlösungen sie nutzt.

GOV.UK empfiehlt einen weiten Blick: was vor und nach der Aufgabe passiert, Bedarf an Barrierefreiheit, digitale Fähigkeiten und Internetzugang. Auch Offline-Kanäle gehören zum Prozess, sprechen Sie deshalb auch mit dem operativen Team.

Blick auf Wettbewerber

Nutzer vergleichen Sie mit anderen Produkten. Machen Sie in der Discovery eine kurze UX-Wettbewerbsanalyse: Probieren Sie dieselbe Aufgabe bei zwei oder drei Wettbewerbern von Anfang bis Ende aus.

In der NN/g-Umfrage waren die häufigsten Tätigkeiten der letzten Discovery Nutzerinterviews (62 %) und Stakeholder-Interviews (60 %). Wettbewerbsanalyse und Auswertung von Analytics folgten mit je 49 %.

Annahmenliste und Risiken

Das günstigste Ergebnis einer Discovery ist die Annahmenliste. Alle im Team schreiben auf, was sie zu „wissen“ glauben. Dann schauen Sie gemeinsam, worauf sich jede Aussage stützt.

Kaley beschreibt dafür die CSD-Matrix: Gewissheiten (Certainties), begründete Vermutungen (Suppositions) und Zweifel (Doubts). Laut Kaley geht es darum, verschiedene Sichtweisen zu sammeln und zu ordnen. Alle müssen nicht einer Meinung sein. Ziel ist, Vermutungen und Zweifel so weit wie möglich in Gewissheiten zu überführen.

Um die Liste zu ordnen, stellt Rosala zwei Fragen. Was ist am wichtigsten, um das Problem zu lösen? Was birgt ein großes Risiko, wenn es falsch angenommen wird? Ich reduziere das auf zwei Achsen: Wie sicher bin ich, und was passiert, wenn es falsch ist?

Annahmen, bei denen Sie wenig sicher sind und die das Projekt erschüttern, falls sie falsch sind, werden zuerst getestet. Im Beispiel unten können Sie das selbst ausprobieren.

Annahmenkarte

Die Matrix zeigt die Ausgangsverteilung der Beispielannahmen. Mit JavaScript können Sie jede Karte selbst einordnen.

Wenig sicher

Sehr sicher

Falls falsch: hohe Wirkung

Falls falsch: geringe Wirkung

Zuerst testen (2)Priorität

Sie sind wenig sicher, und liegt es falsch, wackelt das Projekt.

• A1 Termin per App
• A2 Monatsabo

Beleg aufschreiben (1)

Sie sind sicher, aber ein Irrtum wird teuer.

• A3 Kalender am Handy

Später prüfen (2)

Sie wissen es nicht, aber ein Irrtum ist leicht zu beheben.

• A4 Erinnerung wirkt
• A5 Ohne Schulung

Annehmen (1)

Sie sind sicher, und das Risiko ist gering. Weiter.

• A6 Zahlung im Salon

Im Feld Zuerst testen liegen 2 Annahmen: A1, A2.

• A1 Kundinnen und Kunden wollen den Termin per App buchen, nicht per Telefon.

  Wenig sicher · Hohe Wirkung · Feld: Zuerst testen

• A2 Salonbesitzer zahlen für diese App eine monatliche Abogebühr.

  Wenig sicher · Hohe Wirkung · Feld: Zuerst testen

• A3 Salons verwalten den Tageskalender auf dem Handy.

  Sehr sicher · Hohe Wirkung · Feld: Beleg aufschreiben

• A4 Eine Erinnerung senkt die Zahl der Kunden, die nicht zum Termin kommen.

  Wenig sicher · Geringe Wirkung · Feld: Später prüfen

• A5 Mitarbeitende können die App ohne Schulung nutzen.

  Wenig sicher · Geringe Wirkung · Feld: Später prüfen

• A6 Kunden zahlen lieber im Salon als in der App.

  Sehr sicher · Geringe Wirkung · Feld: Annehmen

Die Termin-App „Termino“ und ihre sechs Annahmen sind von mir erfundene Beispiele. Ihre Auswahl wird nirgendwohin gesendet.

Annahmenkarte: Jedes der vier Felder nennt den nächsten Schritt. Annahmen, bei denen Sie wenig sicher sind und ein Irrtum viel bewirkt, werden zuerst getestet.

Die Verteilung in der Matrix beginnt die Diskussion, sie beendet sie nicht. Antworten zwei Personen auf dieselbe Annahme unterschiedlich, ist dieser Unterschied selbst ein Zweifel. Schreiben Sie ihn, wie Kaley empfiehlt, als Frage auf und fügen Sie ihn der Spalte Zweifel hinzu.

Umfang und Ergebnisse

Rosala warnt: Eine Discovery macht man nicht, um Dokumente zu produzieren. Trotzdem braucht es für die Entscheidung einige Unterlagen. Ohne diese drei schließe ich keine Discovery ab:

• Problembeschreibung. Ein oder zwei Sätze dazu, wer in welcher Situation was nicht tun kann. Ohne Lösung.
• Erfolgskriterien. GOV.UK verlangt, in dieser Phase zu planen, welche Daten Sie sammeln und welche Leistungskennzahlen Sie nutzen. HEART-Metriken sind dafür ein guter Ausgangsrahmen.
• Fahrplan. Was Sie als Nächstes in welcher Reihenfolge ausprobieren. GOV.UK erwartet etwas Ähnliches: eine Liste von Ideen für die Alpha und eine Einschätzung, welche zuerst getestet wird.

Bei Bedarf kommen eine Customer Journey Map, eine Persona oder ein grober User Flow dazu. Auf Rosalas Liste möglicher Ergebnisse stehen auch grobe Konzepte und Wireframes. Alles dient der Entscheidung.

Manchmal lautet das Ergebnis „Wir machen nicht weiter“. Laut GOV.UK ist es kein Scheitern, nach der Discovery aufzuhören, wenn die Forschung das zeigt. Für mich ist das Budget, das nicht in das falsche Produkt fließt, der greifbarste Nutzen einer Discovery.

Dauer und Team

Eine feste Dauer gibt es nicht. GOV.UK schreibt, dass 4 bis 8 Wochen typisch sind. Ein nie erforschtes Problem kann länger dauern, eines, das das Team gut kennt, kürzer.

In der NN/g-Umfrage gaben 58 % der Befragten an, dass ihre letzte Discovery höchstens zwei Wochen dauerte. Laut Rosala sind zwei Wochen zu kurz, außer der Zugang zu Nutzern ist leicht und der Problemraum klein.

Begrenzen Sie die Dauer von Anfang an. Rosala erinnert daran, dass Teams die Dauer von Aufgaben unterschätzen, das nennt man Planungsfehlschluss. Kaley empfiehlt, die Dauer der Discovery nicht an die Sprintlänge zu binden.

Das Team sollte klein und interdisziplinär sein. Rosala hält 3 bis 7 Personen für ideal: eine Person aus der Forschung, eine Moderation, eine verantwortliche Person mit genug Einfluss, um Türen zu öffnen, und eine Person aus der Technik. Lassen Sie die Technik nicht weg, sie sieht Einschränkungen oft als Erste.

Double Diamond und Product Discovery

Ich sehe die Discovery als erste Raute des Modells Double Diamond. Der Design Council baut diese Raute aus den Phasen Discover (Entdecken) und Define (Definieren). Erst erforschen Sie das Problem breit, dann verengen Sie es auf eine einzige Problembeschreibung.

In der Product Discovery ist die Arbeit nicht einmalig. Kaley beschreibt, wie agile Teams Discovery fortlaufend in kleinen, iterativen Schritten betreiben. Eine vollständige Phase für ein neues Produkt, laufende kleine Discoveries für ein bestehendes: So sehe ich den Unterschied.

Warum Agenturen die Discovery getrennt bepreisen

Dieser Abschnitt ist meine Meinung. Bietet Ihnen eine Agentur oder eine freie Designerin die Discovery als eigenen Posten an, gibt es dafür einen guten Grund.

Vor der Discovery kennt niemand den Umfang der Arbeit. Ein Designpreis ohne Problembeschreibung ist eine Schätzung. Die Schätzung wird entweder aufgebläht oder endet mitten im Projekt in einer Diskussion über Nachträge.

Die Discovery abzutrennen, schützt beide Seiten. Sie klären das Problem mit einem kleinen Budget. Das Angebot für Design und Entwicklung stützt sich dann auf einen echten Umfang.

Außerdem öffnet sich ein Ausgang. Nach der Discovery können Sie entscheiden, mit jemand anderem weiterzumachen oder gar nicht. Problembeschreibung und Kriterien bleiben bei Ihnen.

Bereite ich ein Angebot für ein Festpreis-Projekt vor, stelle ich mir zuerst dieselbe Frage: Ist der Umfang klar genug? Die Preismodelle beschreibe ich im Ratgeber Designabo oder Festpreis.

Meine Notiz

Der häufigste Fehler in einer Discovery ist eine Studie, deren Ergebnis von Anfang an feststeht. Das Team hat sich auf eine Lösung festgelegt und nutzt die Forschung, um sie absegnen zu lassen. Auch in der NN/g-Umfrage schrieb jemand, dass Discovery manchmal nur dazu dient, die erste Idee bestätigen zu lassen.

Am einfachsten verhindern Sie das, indem Sie die Annahmenliste am ersten Tag schreiben. Besprechen Sie auch vorab, was Sie tun, wenn eine Annahme im Feld „Zuerst testen“ widerlegt wird. Lautet die Antwort „Wir machen es trotzdem“, ist die Entscheidung schon gefallen, und es braucht keine Discovery.

In einem kleinen Team ist eine vollständige Phase nicht nötig. Schon ein paar Interviews und eine ehrliche Annahmenliste sind besser, als ohne Forschung loszuzeichnen.