Summary
Research timing follows three phases aligned to product maturity: Generative (before code) validates the problem, Formative (during design) de-risks execution at low cost, and Summative (after launch) measures success through benchmarking. The cost of fixing issues compounds at each stage—a €50 fix in Figma becomes €5,000 in code.
The question "When should we do research?" has a simple answer: always. The practical answer is that research must match your product's maturity.
Do not wait for the beta. By then, the expensive decisions have already been made.
The Three Phases of Research
Research is not a single activity—it is three distinct activities with different goals, methods, and ROI:
| Phase | Timing | Goal | Primary Methods |
|---|---|---|---|
| Generative | Before code | Validate the problem | Interviews, contextual inquiry, diary studies |
| Formative | During design | Fix issues early | Usability testing, prototype evaluation |
| Summative | After launch | Measure outcomes | Benchmarking, analytics, A/B tests |
For the team foundation context that shapes timing decisions, see Research Timing and Team Foundation.
Phase 1: The "Expensive Mistake" (Concept Stage)
Generative research happens before you write a single line of code. It de-risks your entire strategy.
The Rule
Validate the problem before you design the solution.
Teams often skip this phase because they feel pressure to "build something." This is how you perfectly engineer a beautiful solution to a problem nobody has.
What You Learn
| Question | Why It Matters |
|---|---|
| "Do users actually have this problem?" | Prevents building unwanted features |
| "How do they solve it today?" | Reveals competitive landscape and workarounds |
| "What would make them switch?" | Identifies must-have requirements |
| "Who exactly is the target user?" | Prevents designing for the wrong audience |
The Cost of Skipping
| Scenario | Cost |
|---|---|
| Discovering wrong problem at concept stage | €10K (pivot strategy) |
| Discovering wrong problem after development | €100K (rebuild) |
| Discovering wrong problem after launch | €1M+ (market failure, reputation damage) |
Methods for This Phase
- User interviews: Understand current behaviors and pain points
- Contextual inquiry: Observe users in their natural environment
- Diary studies: Capture behaviors over time
- Competitive analysis: Understand existing solutions
When to Do It
- Before writing a PRD or product brief
- Before committing engineering resources
- When entering a new market or user segment
- When pivoting strategy
Phase 2: The "Course Correction" (Prototyping Stage)
Formative research happens during design. It de-risks your execution by finding problems while they are cheap to fix.
The ROI
Fixing a usability issue in Figma costs €50. Fixing the same issue in code costs €5,000.
This is not an exaggeration—it is the economics of change:
| Stage | Change Cost | What Changes |
|---|---|---|
| Sketch/Wireframe | €10 | Pencil eraser |
| Design file (Figma) | €50 | Designer time |
| Prototype (clickable) | €100 | Designer time + iterations |
| Code (pre-release) | €5,000 | Engineering sprint + QA |
| Code (post-release) | €50,000+ | Hotfix + customer support + reputation |
What You Test
| Prototype Fidelity | What You Learn | Limitations |
|---|---|---|
| Paper/Sketch | Information architecture, navigation concepts | Cannot test interactions |
| Low-fi wireframe | Layout, content hierarchy, flow logic | Cannot test visual design |
| Mid-fi interactive | Task flows, interaction patterns | Cannot test performance |
| High-fi prototype | Visual polish, micro-interactions | May set false expectations |
The Iteration Trigger
Run a formative test whenever:
- A major design decision has been made
- A cluster of important questions has accumulated
- You are about to hand off to engineering
- Stakeholders are debating between two approaches
Methods for This Phase
- Usability testing: Task-based evaluation of prototypes
- A/B preference testing: Compare design alternatives
- First-click testing: Validate navigation decisions
- Cognitive walkthroughs: Expert evaluation of learnability
Phase 3: The "Reality Check" (Live Stage)
Summative research happens after launch. It measures whether you succeeded.
The Metric
Use benchmarking to track improvement over time.
Standardized instruments like the System Usability Scale (SUS) allow you to:
- Compare your product to industry benchmarks
- Track improvement across releases
- Quantify the impact of design changes
| Metric | What It Measures | Benchmark Comparison |
|---|---|---|
| SUS | Overall usability perception | Industry average: 68 |
| NPS | Likelihood to recommend | Varies by industry |
| Task Success Rate | Effectiveness | Target: >85% for critical flows |
| Time on Task | Efficiency | Compare to baseline |
The Feedback Loop
Summative research completes the cycle—and starts the next one:
Methods for This Phase
- Benchmarking surveys: SUS, NPS, CSAT at regular intervals
- Analytics review: Funnel analysis, drop-off points
- A/B testing: Measure impact of specific changes
- Support ticket analysis: Identify recurring issues
When to Do It
- At fixed intervals (quarterly, after major releases)
- When comparing before/after a redesign
- When stakeholders ask "is it working?"
Matching Research to Product Maturity
The right research depends on where you are:
| Product Stage | Primary Research | Secondary Research |
|---|---|---|
| New idea | Generative | — |
| Early prototype | Formative | Generative (validation) |
| Late prototype | Formative | — |
| Beta/Soft launch | Formative + Summative | — |
| Live product | Summative | Formative (new features) |
| Mature product | Summative | Generative (innovation) |
For how each timing phase needs its own research plan, see The Research Plan.
Handling the "Not Now" Objection
When stakeholders push back on research timing:
"It's too early"
Translation: Fear that negative feedback on an unpolished prototype will be discouraging.
Response: "That's exactly why we should test now. If we find a fundamental problem at this stage, it's a €50 fix. After development, it's a €5,000 fix."
"It will slow us down"
Translation: Pressure to ship quickly.
Response: "Research runs in parallel, not in series. Think of it like a Git branch—development continues while research provides input for the next sprint."
"We already know what users want"
Translation: Overconfidence or HiPPO (Highest Paid Person's Opinion).
Response: "Great—let's validate that assumption. If you're right, we'll have evidence to move faster. If there's a gap, we'll catch it before it's expensive."
The Continuous Research Model
The most mature organizations do not treat research as a phase—they treat it as a continuous pulse:
| Cadence | Activity | Owner |
|---|---|---|
| Weekly | Quick usability checks on new designs | Designer + Researcher |
| Sprint | Formative testing of sprint deliverables | Research team |
| Monthly | Analytics review + support ticket analysis | Product + Research |
| Quarterly | Benchmarking (SUS/NPS) + strategic planning | Research + Leadership |
What This Means for Practice
Match your research to your product's maturity:
- Concept stage: Generative research validates the problem (€10K to pivot now, €1M to pivot later)
- Prototype stage: Formative research finds issues while they are cheap (€50 in Figma, €5,000 in code)
- Live stage: Summative research measures success and identifies the next problem to solve
The goal is not to do research to the product team. It is to do research with them, throughout the entire journey.
For related guidance on building research into your team's workflow, see Operationalizing Research: Building a Sustainable Practice.