Progressive choice
Put the consequential decision in view, and hold supporting detail nearby rather than making people remember it across a journey.
Web development / full-stack engineering
Draft the system before the screen.
A field guide for turning product questions into sturdy web decisions: boundaries, interfaces, pathways, release habits, and the small artefacts that make a build understandable.
Plain language, practical prompts, and deliberate trade-offs — assembled for teams working in the open.
draft board / 01not to scale
IntentWhy now?
BoundaryWhere does it stop?
ContractWhat travels?
InterfaceWho touches it?
ReleaseHow is change seen?
01 / Position
The working premise
A site is a living agreement between people, data, devices, and time.
Build the visible surface with the invisible system in view. Good engineering is not a performance of certainty; it is a record of sensible decisions.
02 / Orientation
Start with a site map that admits the real work.
A durable brief names the journey, the actors, the data that matters, and the constraints worth protecting. It does not pretend that a page list is an architecture.
ORIENTATION CARD
Four questions before a component.
- What decision should this part help a person make?
- Which source has authority for the information here?
- What changes when the request is slow, absent, or wrong?
- What future editor or maintainer needs to understand?
03 / System layers
Select a layer. Read the questions behind the implementation.
This board refuses the default tab set. Move through the system from the human-facing edge to the operation that keeps it honest.
The edge
The interface is a promise in public.
Use names that match a person’s task. Give every control a purpose, a state, and enough space to be used without precision. Content structure should survive a different screen, a different input method, and a different moment of attention.
InputPurposeful controls
CopyHelpful words
StateVisible feedback
ShapeFlexible layout
The flow
Model the wait, not only the answer.
Every request has a beginning, a pause, a possible detour, and an outcome. Treat loading, permission, absence, retry, and recovery as designed routes rather than incidental exceptions. The interface becomes calmer when its states are named early.
StartAsk
PauseWait
DetourExplain
ReturnContinue
The core
Keep rules close to their evidence.
Choose a source of truth, describe the shape of what crosses a boundary, and make invalid states difficult to represent. A useful model explains both what is stored and what is deliberately not inferred.
SourceAuthority
ContractShape
RuleValidate
RecordTrace
The care layer
Prepare for the next change while making this one.
Release notes, practical logs, accessible markup, and a clear hand-off are acts of maintenance. Make it possible to see what changed, reason about why, and recover without relying on memory alone.
SignalObserve
ContextExplain
ChangeRecord
RepairRecover
Keep diagrams as prompts for conversation, not props for authority.
04 / Workshop board
A working board has edges, not just boxes.
Use a construction-board approach when a system feels too large: place the big pieces, draw the hand-offs, note the assumptions, then test the gaps. The board does not need to be beautiful; it needs to invite correction.
For every block, add one verb: reads, writes, checks, prepares, queues, publishes, or explains. Verbs reveal whether an apparent component is actually a service, a policy, or a task in disguise.
See interaction patterns05 / Interaction patterns
Choose patterns that leave room for a person to think.
A component is more than its styling. It is behaviour, keyboard path, language, consequences, and a piece of the page’s social contract.
Useful absence
An empty state should say what is missing, why it matters, and one clear next action — without feigning activity.
Recoverable work
When an action cannot finish, preserve the person’s context and provide a route to try again with an explanation.
06 / Boundaries
The boundary is where trust becomes a technical choice.
What crosses this line?
- Identify the information, instruction, or authority that moves.
- Name the party that can change it and the condition for accepting it.
- Describe the smallest useful contract in ordinary words before formalising it.
What happens when it does not arrive?
- Decide whether the person can wait, continue, save, or return later.
- Surface a meaningful state without leaking implementation detail.
- Keep a record that helps the next engineer reconstruct the route.
07 / Local review
A checklist that stays in this browser.
Tick what you have reviewed. The count is stored only in local browser storage and can be cleared without sending anything anywhere.
System draft review
0 of 6 reviewed08 / Build rhythm
A short loop beats a long assumption.
Keep the loop legible enough that a new collaborator can join it without learning a private language.
01
Frame the decision
Write the question, the limits, and the condition that would change your mind.
Decision note
02
Make the smallest demonstrable path
Build enough of the path to test the important hand-off, including an unhelpful response.
Working slice
03
Observe and amend
Record what was surprising, then amend the model before adding comfortable complexity.
Changed draft
09 / Engineering posture
Make the considerate path the normal path.
Accessibility, performance, security, and maintainability should appear in the first sketch, not as a final inspection queue.
Reachable by design
Semantic structure, visible focus, readable content, and generous controls help many people without asking them to identify themselves.
Careful by default
Minimise what crosses a boundary, validate at the appropriate edge, and explain the consequence of consequential actions.
Maintainable in daylight
Give names to the seams, leave a useful trail of choices, and prefer understandable forms over impressive contortions.
10 / Reading shelf
Keep a shelf of questions, not a cabinet of prescriptions.
These cards suggest what to explore when a design or build conversation gets stuck. They are prompts for inquiry, not a substitute for context.
Journey framingFind the decision a page is actually helping with.OpenBoundary languageDescribe contracts before the implementation vocabulary takes over.OpenReview promptsUse a short local pause before the next interface pass.OpenDraft exchangePrepare a local email draft with a question for the guide.Open
Begin with the decision a person or organisation is trying to make, rather than with a preferred framework or database. Then identify the information needed, who may alter it, and what happens when it is absent or late. This creates a shared map before teams debate the individual technologies that might serve it.
Early detail should be sufficient to expose the meaningful boundaries and test a difficult path, not so exhaustive that it impersonates certainty. Use sketches, example data, and plain-language contracts. If a draft makes it harder to question an assumption, it may be too polished for the stage of work you are in.
It adds a disciplined attention to meaning, input, feedback, contrast, order, and error recovery. Those concerns improve the experience for people navigating by keyboard, touch, assistive technology, a smaller screen, a temporary limitation, or simple distraction. Accessibility is therefore part of the system model, not a layer painted onto finished pages.
Capture the smallest useful record near the work: the question, the chosen direction, the important limitation, and the condition that would reopen the decision. A concise note at a boundary or release point is usually easier to maintain than a distant document. Documentation becomes lighter when it is written as part of making a change.
12 / Send a note
Turn a question into a browser-local draft.
This form does not submit data to a service. With both fields filled, it prepares a mailto draft addressed to [email protected]; you choose whether to open and send it from your email application.
