You spend a session getting an order form right. One page, not three steps. A review summary before submit. Delivery date where people actually look for it. Then a new prompt regenerates the form, and the agent goes back to a three-step wizard, because nothing told it why you chose otherwise.
The agent kept the code. It did not keep the reasons.
Design Decision Method handles this with step 4 of its workflow: the decision record.
For a choice that would be costly to undo, the method asks you (or your agent) to record: It also asks you to judge effort in a specific way: compare the effort to read, remember, enter, navigate, and recover, rather than counting clicks or visible elements. A three-step flow has fewer fields per screen. That does not make it less effort if people have to go back to check what they entered on step one.
Two more rules keep the record honest:
Say you run a small print shop at example.com, and you ask your agent to build the order form. This is an illustration of how the procedure applies, not a case study or a measured result.
The decision row looks like this:
| Decision | Frequency | Familiarity | Error cost | Device | Pattern chosen | Reason |
|---|---|---|---|---|---|---|
| Order form layout | Occasional, once per order | Mostly first-time customers | Medium: a wrong size or quantity means a reprint | Phone first | One page, grouped sections, review summary before submit | Customers need to see size, quantity, and price together to catch mistakes. Splitting them across steps adds recall effort at the point of decision. |
If a source you cite recommends a different pattern for this form, that is where an adaptation line goes, in the same three-part form. The record also carries a short validation status, because step 6 of the method asks for an honest evidence label on each result: proposed, heuristic review, automated check, manual test, or user research. For this form it might read:
Untested stays untested. The record says so instead of implying the form works.
Next week you ask the agent to add a "rush delivery" option. The following prompt starts from that record. The agent can see the form is one page for a reason, and that the reason is error cost, not taste. It adds the option inside the existing structure instead of reinventing the flow.
A person still checks the result. The method does not measure how many prompts that removes, and whether it saves time has not been measured.
The decision record is proportional. A small change gets a few lines. The repo's design record template is a scaffold, not mandatory overhead. Save the record with the work (as docs/design/<slug>.md) when your project keeps design records, or deliver a compact record inline with the change when it does not.
You do not need a record for every edit either. The method is a shared procedure, not mandatory for every small edit. Record the choices you would be annoyed to re-argue.
The decision record is step 4 of six: establish context, choose the visual system, map objects before layout, write a decision record, structure each view, then deliver and validate.
Design Decision Method is a lightweight design decision workflow for developers building interfaces with AI agents. It follows the open Agent Skills format and is MIT licensed. Install paths for Claude Code, Cursor, Gemini CLI, and Codex are in the README.