Stop correcting your AI’s UI on every prompt

Your coding agent can build a settings screen in one shot. Then you ask for less clutter, and it invents a different layout. You fix the primary action, and the next prompt drops it.

That loop is common when you ship without a dedicated designer: the agent is fast at drawing, slow at holding the decisions that make a screen fit the job.

The problem

Repeated UI guesswork looks like this:

• starting from a familiar generic layout
• overlooking information the screen actually needs
• adding complexity that does not help the task
• re-deciding the same things on the next project or the next prompt

What Design Decision Method is

Design Decision Method is a lightweight workflow for people and AI agents to decide what a screen needs, how to organize it, and which interactions and visual direction fit — before drawing or coding.

It draws on established guidance (OOUX object mapping, GOV.UK, Carbon, Material 3, platform guidelines, and your project’s own rules). It is not another UI library or visual standard. It does not rank those sources, copy their branding, or claim research or compliance it has not done.

Current release: 2.2.4. MIT License.

How it works

Six steps, in order:

1. Establish context — audience, how often the task happens, what a mistake costs, and the device. Keep known facts separate from assumptions.
2. Choose the visual system — keep what the project already has; otherwise select from the platform (Material 3 is the web fallback when none exists).
3. Map objects before layout — when relationships would change navigation, routes, or structure; skip when they would not.
4. Write a decision record — for choices that would be costly to undo: what you chose and why.
5. Structure each view — purpose, required information, actions, and real states (loading, empty, error).
6. Deliver and validate — ship the screen or spec with the decisions and an honest validation label (proposed, heuristic, automated, manual, or user research), including what you did not test.

It is a shared procedure across products and agents. It is not mandatory for every small edit. Whether it saves time has not been measured.

How this differs from WebHIG

Design Decision Method decides how this particular experience should work. WebHIG defines applicable interface quality requirements. Keep them separate.

A short example

You ask an agent for account settings. It returns a grid of cards. You say it is too much. The next result is a different grid with toggles you did not ask for.

What the method asks first: who changes settings, which ones they change often, and which mistakes are costly (delete account, change billing). Map objects people recognize — account, preference, connected service — before any layout. Record which settings stay visible and which sit behind a further step, and why. The next prompt starts from that record. A person still checks the result.

Get started

Install as an Agent Skills folder named design-decision-method for Claude Code, Cursor, Gemini CLI, or Codex (paths in the README). Or paste SKILL.md into your rules file and keep references/ and assets/ in the repo.

• Docs: https://frozonfreak.github.io/DesignDecesionMethod/
• Repo: https://github.com/frozonfreak/DesignDecesionMethod

Built for independent developers and small teams shipping with AI coding agents — especially when the agent can build the UI, but you keep correcting what it shows and how the flow works.