How Long Is User Research Valid? Insight Decay and When to Re-Run a Study

How long does user research stay valid?

There is no single expiry date, and any team applying one uniformly is either throwing away good evidence or acting on dead evidence. Validity depends on what the finding is about. A finding about the fundamental job a customer hires your product for can stay accurate for a decade. A finding about which competitor a buyer shortlists can be wrong in six months. A usability finding about a specific screen dies the moment you ship the redesign.

The working rule: research decays at the speed of the thing it describes. Classify every insight by what it measures, assign it a half-life, and re-validate on event triggers rather than on the calendar.

What insight decay actually is

Insight decay is the gradual divergence between what a research finding claims and what is currently true. Nothing announces it. The document does not change, the quote is still vivid, the chart still renders — and the team keeps citing it in roadmap reviews eighteen months after the population it described stopped existing.

The failure is structural rather than careless. Research repositories are built to accumulate and preserve; almost none are built to mark things stale. The result is a library where a study from last month and a study from 2023 look identical in the search results, and the one with the better title wins the argument.

A useful analogy comes from the data-quality world, where decay is measured rather than assumed: B2B contact records degrade at roughly 2.1% per month, about 22.5% annually, with some vendor analyses putting real-world decay at 30–40% per year. If the contact details of your research participants rot that fast, the organizational reality those participants described is not standing still either.

A widely used practitioner heuristic is to check for existing research before commissioning new work, treating roughly one year as the review point for evaluative research and about five years for generative research. That is a reasonable default — but the classes below are far more accurate than a single number.

The half-life table: how fast each finding type decays

The most common repository error is filing everything at the speed of the slowest class. The second most common is the reverse: discarding durable generative findings because they are "old", then paying to rediscover the same job to be done.

The five decay triggers

Calendar-based review catches decay late. Event-based review catches it when it happens. Re-validate a finding when any of these fire:

1. Your product changed materially. Any change to the flow the research described. This invalidates evaluative findings immediately and completely.
2. The competitive set changed. A new entrant, a major competitor release, or a category-defining feature shipping elsewhere. Buyer expectations reset against the new best available option, not against your last study.
3. Your user population changed. Moving upmarket, opening a geography, or a growth channel that shifts who signs up. The finding may still be true — about a population you no longer primarily serve.
4. The regulatory or macro context changed. New compliance obligations, budget contraction, or procurement policy shifts alter both behavior and stated priorities.
5. An interaction norm changed. When a dominant platform popularizes a new pattern, expectations about what is "obvious" can shift within a year or two.

Notice that four of the five are external. Teams tend to review research when they ship something and forget that most decay is caused by things happening outside the product.

The refresh protocol

1. Tag every insight with four fields at the time of publication. Not later — later never comes.

• Collected on: the fieldwork date, not the publication date
• Population: the exact cohort, including how they were recruited
• Product version / state: what the participants were actually reacting to
• Decay class: from the table above

2. Run a quarterly staleness sweep. Sort the repository by decay class and fieldwork date and produce three buckets: current, needs review, superseded. Insights marked critical or high severity deserve an annual review at minimum, regardless of class.

3. Never delete — supersede. Deleting old research destroys the ability to see change over time, which is often the most valuable thing a repository holds. Mark the old finding superseded, link it to the new one, and keep both. The delta between waves is itself a finding.

4. Re-validate narrowly. Refreshing does not mean repeating the original study. It means testing the specific claims that matter now, usually a handful of questions against the current population.

5. Publish an explicit confidence label. "Validated Q1 2026, population: SMB admins, decay class: competitive expectations, review by Q3" is a sentence that prevents a stakeholder from confidently citing dead evidence in a planning meeting.

Why teams do not refresh — and what changes it

The honest reason refresh cadence is rare is arithmetic. Under a traditional pipeline, re-running a study costs approximately what the original cost: rewrite the screener, re-recruit, re-schedule, re-moderate, re-transcribe, re-code. Faced with paying full price to possibly confirm what you already believe, teams rationally defer — and the repository quietly ages into fiction.

An AI-native platform inverts that arithmetic, which is what makes refresh cadence practical rather than aspirational:

• Re-running a study is re-launching a brief. In Koji, the study definition — objectives, question set, AI moderator configuration — is reusable. A refresh wave is a relaunch against a fresh cohort, not a rebuild.
• Identical instruments across waves. Koji's six structured question types (open_ended, scale, single_choice, multiple_choice, ranking, yes_no) hold the measurement constant between waves, so a shift in a scale distribution reflects the market rather than a reworded question. This is what makes genuine wave-over-wave comparison possible.
• Consistent moderation removes drift. A human moderator asks the question slightly differently a year later; an AI moderator does not. Between-wave differences are more likely to be signal.
• Cost per wave collapses. When a refresh wave costs a small fraction of the original, quarterly re-validation of your fastest-decaying classes becomes a routine line item instead of a business case.
• Always-on studies replace point-in-time snapshots. Leaving a study running continuously turns the refresh question into a non-question: the finding is never more than a few weeks old.

That last point is where the practice is heading. Teresa Torres defines continuous discovery as, at minimum, weekly touchpoints with customers by the team building the product, conducting small research activities in pursuit of a desired outcome. A team with a genuinely weekly cadence does not need a decay policy for its fastest-moving classes, because nothing in that bucket ever gets old enough to mislead. Legacy tooling makes weekly contact implausible; asynchronous AI moderation makes it a default.

Anti-patterns

• Uniform calendar expiry. Marking everything stale after twelve months discards durable generative insight and creates busywork.
• Refresh theatre. Re-running a study without a hypothesis about what may have changed. If nothing on the trigger list fired, spend the cycle elsewhere.
• Silent citation of undated findings. The most damaging pattern: a slide with a compelling quote and no fieldwork date. Require dates on every cited insight.
• Treating the repository as an archive rather than a live asset. An insight nobody has re-validated in three years is a hypothesis, and should be labelled as one.

Related Resources

• Structured Questions in AI Interviews — holding measurement constant across refresh waves
• How to Build a UX Research Repository — the storage layer that decay metadata plugs into
• Insight Repository Methodology — tagging and activating a research library
• Continuous Discovery Tools 2026 — the stack behind weekly customer touchpoints
• Time to Insight — why cycle time determines refresh feasibility
• Customer Signals — building an always-on insight layer
• Activating Research Insights — turning current findings into decisions

Frequently asked questions

Is there a standard expiry date for user research? No. A common default is reviewing evaluative research at one year and generative research at around five, but decay class is far more accurate than a blanket rule. Usability findings about a screen die when the screen changes; core jobs to be done can hold for a decade.

Should we delete outdated research? No. Mark it superseded and link it to the finding that replaced it. The comparison between an old wave and a new one is frequently more valuable than either wave alone, and deletion makes trend analysis impossible.

How do we know a finding has decayed without re-running the study? You usually cannot, which is why trigger-based review matters. If any of the five triggers fired — product change, competitive change, population change, regulatory change, interaction-norm change — treat the finding as unverified until a narrow re-validation says otherwise.