You ask your AI agent for an account settings screen. It returns a grid of cards, a dark-mode toggle you never mentioned, and a "delete account" control sitting next to a harmless preference. You push back. The next prompt invents a different layout, and a social-login switch the product does not have.

The agent filled gaps. It treated guesses as product rules.

Design Decision Method's first step is there to stop that. Step 1, establish context, asks the agent to read the brief and the product you already have before it decides anything about layout.

What step 1 asks for

The method asks the agent to name:

  • the audience
  • how often the task happens
  • what a mistake costs
  • the device

It also asks the agent to keep what it knows separate from what it assumes, and not to invent rules or capabilities the product lacks.

That is the whole first step. No wireframe yet. No colour palette. A short read of the brief and the existing product, then an honest list of facts and assumptions.

A worked example: account settings on example.com

Say you run a small product at example.com, and you ask your agent for the account settings screen. This is an illustration of how the procedure applies, not a case study or a measured result.

Without the method, the agent invents. It adds toggles, cards, and a delete path because those are familiar from other products.

With step 1 filled in first, the note might look like this:

Audience: Account holders who manage their own profile. Mostly people who signed up themselves.

Task and frequency: Change email or password occasionally. Review notification preferences rarely. Delete the account almost never.

Cost of a mistake: Medium for email or password (lockout or missed mail). High for delete or billing changes.

Device: Phone first; desktop second.

Known: The product has email, password, and three notification toggles. There is no social login. There is no team account.

Assumptions (marked): Offline use was not requested, so none is designed. Billing settings live elsewhere; this screen does not invent them.

Now the agent has somewhere to stop inventing. A dark-mode switch that was never in the product stays out. A delete control does not sit next to a low-cost preference just because other apps do that. Optional additions get labelled instead of smuggled in as facts.

Known versus assumed

The useful part is the split. "Known" comes from the brief, the code, or a screen you already have. "Assumed" is everything else, and it stays marked.

If the agent cannot ask about a gap that would change the design, list the assumption in the deliverable instead of quietly filling it. You can confirm, correct, or reject the guess before layout hardens around it.

Why this matters when you build with agents

Agents are good at completing patterns. They are less good at noticing that your product never offered the pattern. The screen looks finished, and the invented parts are hard to spot until you click them.

Establish context makes the first deliverable a short statement of who the screen is for, how often people use it, what a mistake costs, and which device they are on. Later steps build on that statement. Without it, they decorate a guess.

The method does not claim this saves time. That has not been measured. What it does give you is a place to catch invented rules before they become UI.

Keep it proportional

A small copy change does not need a long context note. The method is a shared procedure, not mandatory for every small edit. When the change could invent a capability, bury a costly action, or import another domain's conventions, spend the few lines.

The design record template has a short Context section for this: audience and roles, primary tasks and frequency, cost of error, device, known facts, and assumptions. Use as much of it as the change needs.

Where this fits

Establish context is step 1 of six: establish context, choose the visual system, map objects before layout, write a decision record, structure each view, then deliver and validate.

Try it

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.