The Evidence Register
One row per claim about users or the product that somebody would act on.
The template
The Evidence Register
Most companies re-learn the same thing every planning cycle because nobody owns what they know. The register is the fix: one place, one row per thing you have learned, with the strength of the evidence and an expiry date attached. It is unglamorous and it compounds, which is a rare combination.
What goes in it
One row per claim about users or the product that somebody would act on.
In: what people do, what they will not do, what they will pay for, where they get stuck, what they think a word means, which failure they forgive.
Out: opinions with no source, feature requests, decisions (those go in decision records), and metrics dashboards (those are instrumentation, not evidence).
The test for a row: if this turned out to be false, would we have built something different? If no, it does not belong here.
The schema
| Field | What goes in it |
|---|---|
| ID | Sequential. Referenced from briefs and decision records. |
| Claim | One sentence, falsifiable, in plain language. |
| Strength | Anecdote / pattern / tested. See below. |
| Source | Where it came from, specific enough to re-open. |
| Date | When the evidence was gathered, not when the row was written. |
| Expires | When this should be re-checked or assumed stale. |
| Owner | A person. Not a team. |
| Used in | Decision records and briefs that leaned on it. |
| Status | Live / stale / overturned. Overturned rows stay, with a pointer. |
The three strengths
Be honest here. Inflated strength is how a register becomes worse than no register, because now the bad claim has a citation.
Anecdote. One or two instances. Real, and not yet a pattern. Useful for generating questions, not for settling arguments. Most of what a team believes lives here and is treated as though it lived two rows down.
Pattern. Repeated across several independent sources, or visible in behavior across a meaningful slice of usage. Good enough to design against, not good enough to bet the quarter on alone.
Tested. Someone deliberately tried to falsify it and it survived. A test, an experiment, a structured study. The rarest row and the only kind that should end an argument.
The upgrade path matters as much as the label. An anecdote that gets repeated enough becomes a pattern. A pattern somebody tests becomes tested. Write down what would upgrade each row, and half your research agenda writes itself.
Expiry
Every row gets a date. This is the field that keeps a register from turning into folklore.
Rough guidance, and adjust to your product's rate of change:
- Claims about the interface: expire when that interface ships a major change.
- Claims about what people will pay for: shorter than you think, because pricing context moves.
- Claims about the underlying job: long. Jobs move slowly.
- Claims involving what a model can or cannot do: very short. This is the row type that goes stale fastest and the one teams most often treat as permanent.
When a row expires, it does not get deleted. It gets marked stale, and the next person who wants to use it knows it needs re-checking rather than assuming it still holds.
The template
E-000
Claim: <one falsifiable sentence>
Strength: anecdote | pattern | tested
Source: <interviews, dates, sample, link>
Date:
Expires:
Owner:
Would upgrade if: <what evidence would move it up a level>
Used in: DR-000, brief-000
Status: live
The rules that keep it alive
One owner for the register itself. Not a rotating duty. A named person who reviews it monthly and marks things stale. Without this the register decays in about a quarter and joins the list of tools your team tried once.
Every brief cites it. If a brief makes a claim about users, it links a row or it says "assumption, untested," which is fine and honest. This is the habit that makes the register load-bearing rather than optional, and it takes about two months to stick.
Overturned rows stay. With the evidence that overturned them and a pointer forward. The most valuable rows in a mature register are the ones that turned out to be wrong, because they show the team's blind spots.
No row without a source you can re-open. "From customer calls" is not a source. "Six onboarding calls, March, mid-market, notes linked" is.
What it prevents
Three specific wastes, all of which are expensive and none of which feel expensive at the time:
The same discovery run twice because the first one lives in someone's notes app.
A decision made on an anecdote everybody remembers as a study.
A new hire spending a quarter learning what the team already knew and could not hand over.
The one thing to do this week
Write the ten rows your team already believes. Not new research, just what is already in people's heads. Mark each one honestly with its real strength. The uncomfortable part is how many land in "anecdote," and that discomfort is the whole value of the exercise.
From "Evidence as an Asset", chapter 16 of The Design Operating Model. falkster.com/design/evidence-as-an-asset