Toolkit / Template
Decision record
Write down a choice, its evidence and what would make you change it. Copy the blank record or use the completed example.
Why I built itOn Parapet I set a quality line before the rebuild, so the decision to stop was already written when no round met it.
- The line was 7.5 out of 10. No scoring round held it.
- Because the test came first, stopping meant reading the result against it.
- The record keeps the choice, evidence and test on one page, so a review three months later checks the call.
You can do this on your own or with a peer. An AI assistant can help draft a counterargument; check its claims before using them.
The blank record
Use one record for a choice with real alternatives.
- Skip fields that do not change the decision.
- The owner keeps responsibility for the call.
# Decision record
Decision owner:
Date:
Status: open | decided | changed after review
Review on:
## Call
What will we do, and what will we leave out?
## Evidence
What did we observe? Include the source and date.
Separate observation, stated opinion, desk research and assumptions.
## Strongest counter
What is the best argument against this call?
What did the person challenging it see that we missed?
## Test and decision rule
Who or what will we test, against which baseline, and on what date?
Write the result that means continue, change, or stop before the test.
Why is this threshold enough for the decision at stake?
## Wrong if
What other observation would make this decision wrong?
## Review result
What happened, what remains unknown, and what is the decision now?
Keep the original rule visible if you change it.
Try it with a peer
- Write separately. The owner writes a call and its evidence. A peer writes the strongest reason it could fail before reading the owner's defense.
- Compare the evidence. Ask which observation each view explains, what is assumed, and what would change either person's mind.
- Make the call. The owner records the counterargument, the decision rule and a review date. Agreement is useful; it is not required.
- Return to the record. Add the result beside the original rule. Explain any change to the decision or the test.
To check whether the exercise helped, look for these:
- Each person can explain the alternative fairly.
- Each person can identify the evidence still needed.
- More confident wording alone is not progress.
Fictional teaching example
A checklist that missed its test
The team, dates and results below are invented. This shows how to complete the record, including a decision that changes after review.
Call
Test a short checklist alongside the current setup page before building a new flow.
Evidence
Observed behavior in a fictional usability study in Aug '26: three of five participants asked where to find the import setting. Support notes also mention the setting, but we have not counted how often.
Strongest counter
The setting's label may be the problem. A checklist could add another thing to read without making the page clearer.
Test and decision rule
Ask six new participants to import the same sample file: three with the current page, three with the checklist beside it. Record unassisted completion and requests for help. Keep the checklist for another test only if all three checklist participants finish without help and fewer than three baseline participants do. Otherwise, remove the checklist from the next prototype and test a clearer label. This rule only chooses the next prototype to test. We accept the risk of discarding a useful checklist because testing a clearer label is a small, reversible next step. Six participants cannot establish a conversion lift.
Wrong if
Participants can find the setting but fail because their files cannot be imported. Then the import flow needs investigation.
Review result
In Sep '26, two of three checklist participants and two of three baseline participants finished without help. One participant in each group asked what the setting label meant. The checklist missed the prewritten rule. Remove it from the next prototype and test the clearer label. We still do not know whether either change improves real onboarding completion.
For a real case with an unfinished test, read why I stopped Parapet.
Still working out the problem?
Start with the user and the task before proposing a solution. The outline asks what people do today, which evidence you have, and what remains an assumption.
# Problem outline
Who encounters the problem, and during which task?
What happens today, including workarounds or doing nothing?
What have we observed? Name the source, date and limits.
What is an assumption that still needs a check?
What decision will this research change?
## Alternatives people use today
| Alternative or workaround | Task it solves | Friction observed | Evidence and date | Still unknown |
|---|---|---|---|---|
| | | | | |
Use it with step 1, Frame the problem ยท Explore the full nine-step cycle