Zusammenfassung
Research-Timing folgt drei Phasen entlang der Produktreife: Generativ (vor dem Code) validiert das Problem, Formativ (während des Designs) entrisikt die Umsetzung bei niedrigen Kosten, und Summativ (nach dem Launch) misst den Erfolg durch Benchmarking. Die Kosten der Problembehebung eskalieren mit jeder Phase: Ein 50-€-Fix in Figma wird zu 5.000 € im Code.
Die Frage „Wann sollten wir Research machen?" hat eine einfache Antwort: immer. Die praktische Antwort lautet: Research muss zur Reife Ihres Produkts passen.
Warten Sie nicht auf die Beta. Bis dahin sind die teuren Entscheidungen bereits gefallen.
Die drei Phasen der Research
Research ist nicht eine einzelne Aktivität, sondern drei verschiedene Aktivitäten mit unterschiedlichen Zielen, Methoden und ROI:
| Phase | Zeitpunkt | Ziel | Primäre Methoden |
|---|---|---|---|
| Generativ | Vor dem Code | Das Problem validieren | Interviews, Contextual Inquiry, Diary Studies |
| Formativ | Während des Designs | Probleme früh finden | Usability Testing, Prototyp-Evaluation |
| Summativ | Nach dem Launch | Ergebnisse messen | Benchmarking, Analytics, A/B Tests |
Für den Teamfundament-Kontext, der Timing-Entscheidungen formt, siehe Research-Timing und Teamfundament: Wann forschen und wer forscht.
Phase 1: Der „teure Fehler" (Konzeptphase)
Generative Research findet statt, bevor eine einzige Zeile Code geschrieben wird. Sie entrisikt Ihre gesamte Strategie.
Die Regel
Validieren Sie das Problem, bevor Sie die Lösung gestalten.
Teams überspringen diese Phase häufig, weil sie den Druck spüren, „etwas zu bauen". So perfektioniert man eine wunderschöne Lösung für ein Problem, das niemand hat.
Was Sie lernen
| Frage | Warum sie wichtig ist |
|---|---|
| „Haben Nutzer*innen dieses Problem tatsächlich?" | Verhindert das Bauen ungewollter Features |
| „Wie lösen sie es heute?" | Deckt Wettbewerbslandschaft und Workarounds auf |
| „Was würde sie zum Wechsel bewegen?" | Identifiziert Must-have-Anforderungen |
| „Wer genau ist die Zielgruppe?" | Verhindert Design für das falsche Publikum |
Die Kosten des Überspringens
| Szenario | Kosten |
|---|---|
| Falsches Problem in der Konzeptphase entdeckt | 10.000 € (Strategiepivot) |
| Falsches Problem nach der Entwicklung entdeckt | 100.000 € (Neubau) |
| Falsches Problem nach dem Launch entdeckt | 1 Mio. €+ (Marktversagen, Reputationsschaden) |
Methoden für diese Phase
- User Interviews: Aktuelle Verhaltensweisen und Pain Points verstehen
- Contextual Inquiry: Nutzer*innen in ihrer natürlichen Umgebung beobachten
- Diary Studies: Verhalten über die Zeit erfassen
- Wettbewerbsanalyse: Bestehende Lösungen verstehen
Wann es ansteht
- Vor dem Schreiben eines PRD oder Product Briefs
- Vor dem Einsatz von Engineering-Ressourcen
- Beim Eintritt in einen neuen Markt oder ein neues Nutzersegment
- Bei einem Strategiepivot
Phase 2: Die „Kurskorrektur" (Prototypphase)
Formative Research findet während des Designs statt. Sie entrisikt Ihre Umsetzung, indem sie Probleme findet, solange sie günstig zu beheben sind.
Der ROI
Ein Usability-Problem in Figma zu beheben kostet 50 €. Dasselbe Problem im Code zu beheben kostet 5.000 €.
Das ist keine Übertreibung, sondern die Ökonomie der Veränderung:
| Phase | Änderungskosten | Was sich ändert |
|---|---|---|
| Skizze/Wireframe | 10 € | Radiergummi |
| Designdatei (Figma) | 50 € | Designer-Zeit |
| Prototyp (klickbar) | 100 € | Designer-Zeit + Iterationen |
| Code (vor Release) | 5.000 € | Engineering Sprint + QA |
| Code (nach Release) | 50.000 €+ | Hotfix + Kundensupport + Reputation |
Was Sie testen
| Prototyp-Fidelity | Was Sie lernen | Einschränkungen |
|---|---|---|
| Papier/Skizze | Informationsarchitektur, Navigationskonzepte | Interaktionen nicht testbar |
| Low-fi Wireframe | Layout, Inhaltshierarchie, Flow-Logik | Visuelles Design nicht testbar |
| Mid-fi interaktiv | Task Flows, Interaktionsmuster | Performance nicht testbar |
| High-fi Prototyp | Visueller Feinschliff, Micro-Interactions | Kann falsche Erwartungen wecken |
Der Iterations-Trigger
Führen Sie einen formativen Test durch, wenn:
- Eine wichtige Designentscheidung getroffen wurde
- Sich ein Cluster wichtiger Fragen angesammelt hat
- Sie kurz vor der Übergabe an Engineering stehen
- Stakeholder zwischen zwei Ansätzen debattieren
Methoden für diese Phase
- Usability Testing: Aufgabenbasierte Evaluation von Prototypen
- A/B Preference Testing: Designalternativen vergleichen
- First-Click Testing: Navigationsentscheidungen validieren
- Cognitive Walkthroughs: Expertenbewertung der Erlernbarkeit
Phase 3: Der „Realitätscheck" (Live-Phase)
Summative Research findet nach dem Launch statt. Sie misst, ob Sie erfolgreich waren.
Die Metrik
Nutzen Sie Benchmarking, um Verbesserung über die Zeit zu verfolgen.
Standardisierte Instrumente wie die System Usability Scale (SUS) ermöglichen es Ihnen:
- Ihr Produkt mit Branchenbenchmarks zu vergleichen
- Verbesserung über Releases hinweg zu verfolgen
- Den Impact von Designänderungen zu quantifizieren
| Metrik | Was sie misst | Benchmark-Vergleich |
|---|---|---|
| SUS | Gesamte Usability-Wahrnehmung | Branchendurchschnitt: 68 |
| NPS | Weiterempfehlungswahrscheinlichkeit | Variiert nach Branche |
| Task Success Rate | Effektivität | Ziel: >85 % für kritische Flows |
| Time on Task | Effizienz | Vergleich mit Baseline |
Die Feedbackschleife
Summative Research schließt den Kreis und startet den nächsten:
Methoden für diese Phase
- Benchmarking Surveys: SUS, NPS, CSAT in regelmäßigen Intervallen
- Analytics Review: Funnel-Analyse, Drop-off-Punkte
- A/B Testing: Impact spezifischer Änderungen messen
- Supportticket-Analyse: Wiederkehrende Probleme identifizieren
Wann es ansteht
- In festen Intervallen (quartalsweise, nach großen Releases)
- Beim Vergleich vor/nach einem Redesign
- Wenn Stakeholder fragen „Funktioniert es?"
Research an Produktreife anpassen
Die richtige Research hängt davon ab, wo Sie stehen:
| Produktphase | Primäre Research | Sekundäre Research |
|---|---|---|
| Neue Idee | Generativ | — |
| Früher Prototyp | Formativ | Generativ (Validierung) |
| Später Prototyp | Formativ | — |
| Beta/Soft Launch | Formativ + Summativ | — |
| Live-Produkt | Summativ | Formativ (neue Features) |
| Reifes Produkt | Summativ | Generativ (Innovation) |
Für den eigenen Forschungsplan, den jede Timing-Phase benötigt, siehe Der Forschungsplan: Ihr Blueprint für rigorose Studien.
Den „Nicht jetzt"-Einwand behandeln
Wenn Stakeholder beim Research-Timing Widerstand leisten:
„Es ist zu früh"
Übersetzung: Angst, dass negatives Feedback zu einem unfertigen Prototyp entmutigend wirkt.
Antwort: „Genau deshalb sollten wir jetzt testen. Wenn wir in diesem Stadium ein grundlegendes Problem finden, ist es ein 50-€-Fix. Nach der Entwicklung ist es ein 5.000-€-Fix."
„Das bremst uns"
Übersetzung: Druck, schnell zu liefern.
Antwort: „Research läuft parallel, nicht seriell. Denken Sie an einen Git Branch: die Entwicklung geht weiter, während Research Input für den nächsten Sprint liefert."
„Wir wissen bereits, was Nutzer*innen wollen"
Übersetzung: Überconfidence oder HiPPO (Highest Paid Person's Opinion).
Antwort: „Großartig, dann validieren wir diese Annahme. Wenn Sie Recht haben, haben wir Evidenz, um schneller voranzukommen. Wenn es eine Lücke gibt, fangen wir sie auf, bevor sie teuer wird."
Das Continuous-Research-Modell
Die reifsten Organisationen behandeln Research nicht als Phase, sondern als kontinuierlichen Puls:
| Kadenz | Aktivität | Verantwortlich |
|---|---|---|
| Wöchentlich | Schnelle Usability-Checks neuer Designs | Designer*in + Forscher*in |
| Sprint | Formatives Testing von Sprint-Deliverables | Research-Team |
| Monatlich | Analytics Review + Supportticket-Analyse | Product + Research |
| Quartalsweise | Benchmarking (SUS/NPS) + strategische Planung | Research + Führungsteam |
Was das für die Praxis bedeutet
Passen Sie Ihre Research an die Reife Ihres Produkts an:
- Konzeptphase: Generative Research validiert das Problem (10.000 € für einen Pivot jetzt, 1 Mio. € für einen Pivot später)
- Prototypphase: Formative Research findet Probleme, solange sie günstig sind (50 € in Figma, 5.000 € im Code)
- Live-Phase: Summative Research misst Erfolg und identifiziert das nächste zu lösende Problem
Das Ziel ist nicht, Research an das Produktteam heranzutragen. Es ist, Research mit dem Team zu machen, während der gesamten Reise.
Für verwandte Hinweise, wie Sie Research in den Workflow Ihres Teams integrieren, siehe Aufbau eines UX Insights Repository: Ein ResearchOps-Leitfaden.