Design Philosophy · Agile UX Research

My UX Approach

Good enough, right now beats rigorous, too late. A research practice built to run at the speed agile teams actually ship at — not the speed research textbooks assume they do.

Method
Dual-track agile research
Best fit
Fast-moving product teams
Cadence
Every sprint, not a single upfront phase
The problem

Rigorous research usually arrives too late to change anything

Most research methods were designed for a world with quarters, not sprints. By the time a "proper" study is scoped, recruited, run, and synthesized, the team has already shipped three iterations on gut feel. The research is thorough — and irrelevant, because the decision it was meant to inform has already been made.

Good enough, right now beats rigorous, too late.
The method

Discovery runs one sprint ahead of delivery

Instead of a single research phase that gates the whole project, discovery and delivery run as two continuous, parallel tracks. Discovery is always working one sprint ahead — validating what delivery will build next — so research never blocks shipping, and shipping never outruns what's actually been validated.

Dual-track agile · continuous, parallel, never blocking
Discovery
Interviews Prototype test Synthesis → backlog
Delivery
Build sprint N Ship Sprint N+1 starts
Findings from Discovery land in the backlog before Delivery needs them — not after.
Principles

What this looks like in practice

01

Validate continuously, not up front

Research is a standing part of the sprint cadence, not a phase that happens once and then stops.

02

Right-size the method to the risk

A 20-minute guerrilla test today beats a three-week study that ships after the decision's already made.

03

Make findings backlog-ready

Insights are framed as decisions and tickets engineering can act on, not research reports that sit unread.

04

Protect the discovery track

It runs far enough ahead that it's never the bottleneck, and never so far ahead it's disconnected from what's actually being built.

Where this doesn't apply

This isn't an argument for skipping rigor — it's for matching rigor to the size of the decision. High-stakes, hard-to-reverse calls — pricing, compliance flows, anything touching sensitive data — still get the slower, deeper treatment. Speed is the default; depth is a deliberate exception, not a compromise.

Curious how this played out on a real project?

See the case study