Your AI agent draws a pretty layout. Make it structure the view first.
You ask your AI agent for an order status page. It returns a polished card grid, a sparkline you never asked for, and a primary button that says "Explore insights." The status sits in the middle. There is no empty state.
You ask your AI agent for an order status page. It returns a polished card grid, a sparkline you never asked for, and a primary button that says "Explore insights." The status sits in the middle. There is no empty state. Error is a toast that vanishes. On a phone, cancel is gone.
The screen looks finished. The view was never defined.
Design Decision Method's fifth step is there to stop that. Step 5, structure each view, asks the agent to say what the view is for, what information people need to decide, which actions matter, and which states exist β before it invents a layout.
What step 5 asks for
For each important view, the method asks the agent to state:
- its purpose
- the information required to decide
- the actions
- the states that apply, including loading, empty, and error where they exist
It also asks the agent to keep essential information visible, and to adapt the layout to the device without dropping a capability the task needs.
That is the whole fifth step. A short definition of the view's job, then a layout that still does that job on a phone.
A worked example: order status on example.com
Say you run a small shop at example.com, and you ask your agent for the order status page. This is an illustration of how the procedure applies, not a case study or a measured result.
Without the method, the agent jumps to a familiar pattern: a dashboard-shaped page with charts, because status pages elsewhere often look like that. The order identity is secondary. Loading is a spinner with no context. Empty and error are afterthoughts.
With step 5 filled in first, the note might look like this:
Purpose: Show where one order is, what happens next, and what the customer can do about it.
Information required to decide: Order id, current status, last update, next step, items, and a path to support.
Actions: Track shipment (when a carrier link exists). Cancel while still allowed. Contact support. Back to orders.
States: Loading keeps the order context. Empty says this id has no order and offers a path back. Error keeps the order id visible and offers retry and support. The success path makes status and next step readable without a chart.
Device: Phone first. Cancel and support stay available; do not hide them behind a hover-only control.
Now the sparkline has nowhere to hide. "Explore insights" is out of scope. The layout still has to answer the purpose, surface the decision information, expose the actions, and cover the states.
Purpose before chrome
Agents are good at completing a visual pattern. They are less good at noticing that the pattern belongs to a different job. A monitoring dashboard and an order status page can both show numbers. Only one helps someone decide what to do about a single order.
Write the purpose first and the mismatch is obvious. Decorative metrics need a reason or they stay out. Essential information β status, next step, recovery β stays visible instead of being trimmed for whitespace.
Why this matters when you build with agents
A pretty first draft is easy to accept. The missing pieces are usually the ones that hurt later: empty, error, and the action that disappeared on a narrow viewport.
Structure each view puts those pieces in the first note. You can reject a layout that drops cancel on mobile, or never defines what happens when the order id is wrong.
The method does not claim this saves time. That has not been measured. What it does give you is a view definition you can check before the chrome hardens.
Keep it proportional
A one-line copy fix does not need a full view note. The method is a shared procedure, not mandatory for every small edit. When the change adds a screen, changes what people must see to decide, or could hide an action on a smaller device, spend the few lines.
Earlier steps give you context, a map when relationships matter, and a decision record for costly choices. Step 5 structures the views those decisions imply, instead of starting from a stock layout again.
Where this fits
Structure each view is step 5 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.
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.