Product Discovery bezeichnet den Prozess, vor dem eigentlichen Bauen einer Software Unklarheiten zu beseitigen und Risiken zu reduzieren. Dazu gehören ein gemeinsamer Workshop aller Beteiligten, qualitative Nutzerforschung durch Interviews und Beobachtungen sowie Kreativmethoden zur Lösungsfindung. Frühe Papier-Prototypen ermöglichen schnelles Feedback, bevor eine einzige Zeile Code geschrieben wird.
Das Wichtigste in Kürze
- Product Discovery reduziert das Risiko, falsche Software zu bauen, indem sie Unklarheiten und blinde Flecken klärt, bevor eine einzige Zeile Code geschrieben wird.
- User Research deckt Details auf, die kein Stakeholder-Workshop liefert: Handschuhe an Touch-Oberflächen, enge Arbeitsplätze oder laute Umgebungen, die bestimmte Interaktionsformen schlicht unmöglich machen.
- Was Nutzer sagen, was sie tun, und was sie tatsächlich tun, weicht regelmäßig voneinander ab, weil routinierte Handgriffe so selbstverständlich geworden sind, dass sie im Interview gar nicht mehr erwähnt werden.
- Die Kreativmethode Crazy 8 erzwingt durch extreme Zeitbegrenzung acht Ideen auf einem gefalteten Blatt Papier und verhindert so, dass sich Teams zu früh auf eine einzige Lösung festlegen.
- Klick-Prototypen ermöglichen echtes Nutzerfeedback, bevor Entwicklungsaufwand entsteht, und machen eine Discovery-Phase von zwei bis drei Monaten zur Risikominimierungsmaßnahme statt zum Kostenfaktor.
Was Product Discovery leistet
Product Discovery klärt frühzeitig, ob ein geplantes Produkt das richtige Problem für die richtigen Menschen löst. Software ist teuer, und niemand legt einfach los, ohne Ziele, Budget und Zielgruppe zu kennen.
Die Phase nimmt Unsicherheiten heraus. Was unklar ist, wird so weit wie möglich geklärt, bevor die erste Zeile Code entsteht. Das Ziel: so wenig Fehlentwicklung wie möglich.
Curie Kure, User Experience Designerin, beschreibt Discovery als Vorbeugung gegen das Scheitern. Statt auf Annahmen zu bauen, wird geprüft, was tatsächlich gebraucht wird. Damit liegt der Fokus früh dort, wo er in vielen Projekten zu spät landet: auf der Sicht der Anwenderinnen und Anwender.
Ein festes Vorgehen gibt es nicht, einen bewährten Ablauf schon
Product Discovery folgt keinem fixen Schema, aber einem erprobten Muster. Product Coaches haben über ihre Erfahrung Vorgehensweisen herausgearbeitet, die meistens funktionieren.
Ein typischer Ablauf besteht aus mehreren Schritten:
- Startworkshop: Alles vorhandene Wissen wird gesammelt und sortiert.
- User Research: Die realen Prozesse der späteren Nutzer werden untersucht.
- Problemdefinition: Aus den Erkenntnissen wird das konkrete Problem formuliert.
- Ideation: Im Team entstehen Lösungsideen, grob als UI auf Papier.
- Prototyp und Test: Ein einfacher Klick-Prototyp geht in den Test, um schnell Feedback zu bekommen.
Der Reiz dieses Ablaufs liegt im Tempo. Schon vor jeder Entwicklung lässt sich prüfen, ob eine Idee überhaupt trägt.
Der Startworkshop trennt sicheres Wissen von riskanten Annahmen
Im ersten Workshop wird gesammelt, was bekannt ist, und dann sortiert: Was ist valides Wissen, woran zu glauben ist riskant? Genau diese Unterscheidung macht die blinden Flecken sichtbar.
Dafür kommen möglichst alle zusammen, die am Produkt beteiligt sind. Dazu gehören UX, Entwicklerinnen und Entwickler, Product Owner und weitere Stakeholder, manchmal die Geschäftsführung. Besonders wertvoll sind nutzernahe Rollen aus Support, Feedback-Teams oder Sales, weil sie Kundenkontakt haben. Auch Tester gehören in diese Runde.
Als Methode dient ein Mapping des Nutzerprozesses. Am Beispiel einer Dokumentationssoftware wird durchgespielt, was die Person, die dokumentieren soll, eigentlich tut. Jede Perspektive im Raum ergänzt einen Teil. Am Ende steht eine User Journey, eine Timeline dessen, was dieser Mensch konkret macht.
Technische und regulatorische Rahmenbedingungen gehören früh dazu. Eine große Werkshalle ohne stabiles Internet verändert die Lösung ebenso wie eine zulassungspflichtige medizinische Anwendung mit regulatorischen Vorgaben.
Festgehalten wird das Ergebnis in einem Whiteboard-Tool wie Miro. Workshops finden möglichst in Person statt, danach arbeiten die Beteiligten kollaborativ am digitalen Ergebnis weiter.
Warum der Startworkshop User Research auslöst
Sobald im Workshop erzählt wird, was der Nutzer genau tut, entstehen Lücken. Jeder hat eine andere Sicht, und plötzlich fehlen Antworten. Genau diese offenen Fragen sind der Auslöser für User Research.
Ein Beispiel aus der Praxis: Bei einer Touch-Oberfläche stellte sich die Frage, wann die Nutzer ihre Handschuhe an- und ausziehen. Niemand wusste es genau, dabei ist es ein wichtiges Detail, wenn man Menschen nicht zum ständigen Handschuhwechsel zwingen will.
Ähnlich bei einer Maschine mit physischen Knöpfen, die digitalisiert werden soll. Wofür ist jeder Knopf da, und in welcher Reihenfolge wird er bedient? Viele in der IT kennen den Ablauf grob, aber nicht jeden einzelnen Handgriff. Für die Software zählt aber genau dieser Detailgrad.
Wie User Research abläuft
User Research lernt von den Menschen, die einen Job machen, wie sie ihn genau machen, damit die Software ihn korrekt abbildet. Wenn wenig bekannt ist, helfen vor allem Beobachtungen und offene Interviews.
Vorab entsteht ein Leitfaden aus der bereits gezeichneten User Journey. Er nimmt genau die blinden Flecken mit, die geklärt werden sollen, und bringt die passenden Antworten zurück.
Qualitative Studien führen oft speziell ausgebildete Menschen durch, etwa aus Psychologie oder Ethnologie. Das ist aber kein Hexenwerk. Wichtiger als Perfektion ist, dass es überhaupt stattfindet.
Es ist besser, jemand macht das, als wenn so etwas gar nicht vorhanden ist. — Curie Kure
Jede gewonnene Erkenntnis ist mehr wert als der Wissensstand davor. Du musst nicht in Perfektion sterben. Jeder Input bringt dich weiter, gerade bei Digitalisierung, wo sich die Frage stellt, ob jemand wirklich noch etwas ausdrucken, einscannen und hochladen muss.
Research ist kein einmaliger Akt, sondern wird regelmäßig betrieben
Niemand findet zu Beginn die Wahrheit und befragt alle künftigen Nutzer. Man erfasst immer nur einen Ausschnitt und nimmt ihn mit. Deshalb wird Research regelmäßig fortgesetzt.
Diese Haltung passt zu agilem Arbeiten. Man lernt, entwickelt weiter, schaut erneut und nähert sich dem Ziel in Schritten.
Beobachtung schlägt dabei oft die reine Befragung. Vielen ist ihr Job so ins Blut übergegangen, dass sie selbstverständliche Handgriffe gar nicht mehr erwähnen. Was Menschen sagen und was sie tun, klafft regelmäßig auseinander.
Deshalb lohnt der Blick auf den Arbeitsort. Ist der Platz eng, sind die Wege weit, ist es laut? In einer lauten Umgebung wird eine Sprachaufzeichnung schwierig. Solche Bedingungen lernt man nur vor Ort kennen, und sie sollten die Lösung beeinflussen, ohne dass sich jemand beobachtet oder kontrolliert fühlt.
Erst das Problem schärfen, dann Lösungen finden
Nach der Research werden die Erkenntnisse gemeinsam ausgewertet und die User Journey angereichert. Daraus wird der Bereich bestimmt, den die Software abbilden soll, und das Problem wird möglichst konkret formuliert.
Diese Schärfung ist der Punkt, an dem viele Projekte stolpern. Der Drang, Neues zu bauen und Funktionalität hinzuzufügen, verdrängt die Frage, welches Problem eigentlich gelöst werden soll. Das zeigt sich auch bei KI-Workshops, in denen die Technik gesetzt ist, bevor klar ist, wozu.
Ein Online-Shop löst nicht das Problem, dass jemand keine Kleidung kaufen kann. Er löst kleinere Teilprobleme. Genau diese gilt es herauszuarbeiten, bevor die Ideenfindung beginnt.
Crazy 8 zwingt zur Breite statt zur ersten Idee
In der Ideation kommen Kreativmethoden zum Einsatz. Eine bekannte und leicht ausprobierbare ist Crazy 8.
Dabei faltet man ein DIN-A4-Blatt in acht Kästchen und ist hart getimeboxt. In sehr kurzer Zeit scribbelt man je eine Idee pro Kästchen. Der Zeitdruck führt dazu, dass man Ideen schnell aufs Blatt bringt, statt zu lange nachzudenken.
Das Ziel ist die Breite. Acht Lösungsansätze entstehen, statt sich früh auf eine einzige festzubeißen. Wer sich gedanklich in einer Idee verheddert und neue Anforderungen hineinzwängt, verliert Zeit, ohne zu wissen, ob die Idee überhaupt gut war.
Moderation hilft hier. Mit Triggerfragen wie “denk doch mal in eine ganz andere Richtung” werden die Teilnehmer geführt, ohne dass aus dem Rumspinnen ein Festfahren wird. Danach entscheidet das Team gemeinsam, welche Ansätze vielversprechend sind.
Prototypen liefern Feedback, bevor Code entsteht
Aus der ausgearbeiteten Idee entsteht ein Prototyp, der getestet wird. Bei einfachen Fällen reicht der Paper Prototype direkt aus den gezeichneten Skizzen, bei komplexeren ein digitaler Klick-Prototyp.
Der Kunde ist dabei meist Teil des Prozesses. Mit dem Prototyp geht man zu den Nutzern und validiert, ob die eigenen Annahmen zutreffen oder ob man danebenliegt.
Der Vorteil liegt im Zeitpunkt. Das Feedback kommt früh, bei einem Artefakt, das noch keine Zeile Code enthält. So lässt sich der Kurs korrigieren, bevor er in die falsche Richtung läuft. Viele Projekte bauen zwei Jahre vor sich hin und zeigen das Ergebnis erst dann, wenn der Anwender nichts mehr damit anzufangen weiß.
Wie du Discovery beim Chef durchsetzt
Wenn der Chef Nein sagt, lohnt zuerst die Frage nach dem Warum. Geht es um Zeit und Geld, ist das stärkste Argument die Risikominimierung.
Discovery holt sehr früh Feedback zu Dingen ein, die noch nicht programmiert sind. Das Design-Team arbeitet zwar mit Entwicklern zusammen, um deren Einschätzung und ein gemeinsames Verständnis zu sichern, doch geschrieben ist noch nichts. Genau darin liegt der Hebel: Kurskorrektur, bevor Aufwand verbrannt ist.
Der Return on Investment von UX lässt sich schwer berechnen, weil niemand sagen kann, wie teuer ein vermiedener Fehler tatsächlich geworden wäre. Aber eine Discovery-Phase von zwei bis drei Monaten, klein gehalten, mit etwas Research und einem Minimum an Validierung, lohnt sich.
Auch leichtgewichtig funktioniert das. Manchmal reicht es, dass jemand zum Anwender fährt, sich dessen Arbeit ansieht und Informationen mitbringt. Das kann schon viel bewegen.
