Vague[01]
The goal stays a noun.
A theme is not a goal. Without a person and a finish line, every draft can be argued into shape.
See the working note
CHECK 01Can another person see the result?
CHECK 02Is the boundary written down?
A practical publication / field notes
A little clearer.
A lot more
buildable.
Good work begins with a shared understanding. Make the goal clear, name the boundaries, and turn an idea into examples someone can actually check.
Read the field notesCLEAR BRIEFSOBSERVABLE RESULTSNAMED BOUNDARIESFEWER GUESSESCHECKABLE WORKONE SHARED STANDARD
CLEAR BRIEFSOBSERVABLE RESULTSNAMED BOUNDARIESFEWER GUESSESCHECKABLE WORKONE SHARED STANDARD
FIG. 01 / THE WORK BEFORE THE WORKDRAWING NO. 026
01 / The premise
The premise
MOST OF THE WORK IS INVISIBLE UNTIL THE GOAL, THE CONDITIONS AND THE BOUNDARY ARE WRITTEN DOWN.
Good work begins with a shared understanding. Make the goal clear, name the boundaries, and turn an idea into examples someone can actually check.
Read the standards02 / Why briefs drift
Most advice arrives without a check
Design software is powerful but passive. Most planning documents are too. They wait for every instruction, give no advice and cannot tell whether the result arrived, so the repetitive work stays on you.
Open[02]
The edge is never named.
What must never happen, and what is out of scope, arrives only after the work has already gone there.
See the working noteBlind[03]
The result is not observable.
If two people cannot look at the same thing and agree on whether it happened, the brief is not finished.
See the working noteLoop[04]
Review becomes taste.
With no expected, failure or boundary case to check, the last opinion in the room starts to look like the standard.
See the working noteThe whole brief
in one view
Every field note starts from the same drawing: a goal, the conditions around it, and a result another person can observe.
[ Scroll to continue ]01 / GOALWho is this for, and what are they trying to finish?
02 / CONDITIONSWhat must be true? What must never happen?
03 / OBSERVABLE RESULTThe expected, failure and boundary cases.
Drawing No. 026 / scale 1:100
03 / The workbench
Draft the brief before the work.
Write a user goal, the conditions that must hold, and the expected, failure and boundary cases. Preview the Given / When / Then descriptions, then keep the brief as Markdown or JSON. Everything stays in this browser.
Open the builder→Working brief / criteria builderLocal / no account
Goal01
Conditions03
Cases05
ExportMD
Acceptance criteriaView all
□
User goalWhat should be true when this works?
Check◇
Out of scopeWhat must never happen?
Check◎
Expected caseThe ordinary path
Check↺
Failure caseThe honest edge
OpenGiven / When / Then
Given
A new brief is opened and the goal is named.
When
The conditions and boundary are written down.
Then
Another person can test the result.
Always in beta / always checkablewellmadeideas.com
04 / Why us
Built to be checked,
not guessed.
Each note moves in one direction: from a shared goal to a condition another person can inspect. The method is small on purpose. A smaller surface is easier to check.
FIG. 03 / THE STRUCTURE OF A PROMISEELEVATION / EAST
FIG. 04 / FIELD CONDITIONSTHE PEOPLE IN THE MODEL
05 / Use cases
Made for the people who have to check.
Writers
Turn a brief into a shared definition of done before the draft. Read the field notes →
Designers
Name the conditions behind a visual decision, then show the expected and failure cases. Open the rubric →
Researchers
Make the observation checkable by someone who was not in the room. See the method →
Editors
Keep a standard that survives a change of author, not just a change of mood. Browse the notes →
Operators
Put the boundary in the brief before it becomes an incident. Read the boundary note →
Small teams
Use one small artifact to keep the work legible without a process layer. Open the builder →