You ask your AI agent to add an invoice filter to an existing product. The new screen comes back with pill-shaped buttons, a different type scale, and a new accent colour. The rest of the product still uses square buttons and the original tokens.
You wanted a filter. You got a second visual direction.
That is the problem this illustration starts with, not a claim about every agent. Design Decision Method's second step, choose the visual system, gives the agent a place to check what already exists before proposing something else.
Keep the system the project has
The live docs put the starting point plainly: keep a system the project already has. When it has none, select from the platform.
The agent procedure adds an important qualification: retain and extend a suitable existing system, brand, or platform direction, and verify its actual tokens, components, and supported versions. If the brief explicitly requests a different direction, assess that request first, including accessibility and platform constraints, migration scope, and consequential conflicts.
So this is not a rule against redesign. It is a rule against treating an ordinary feature request as permission to redesign.
A worked example: invoice filters on example.com
Imagine a small invoicing product at example.com. It already has an in-house component library, named colour roles, and a documented type scale. You ask for a filter that lets customers show unpaid invoices.
This is a fictional illustration, not a case study or a measured result. The product details and the following note are invented for the example.
Before building, the agent's note could read:
Existing direction: Keep the product's in-house system. This request adds filtering, not a new visual identity.
Reuse: Use the existing button and select components, the established text styles, and the project's colour roles. Check their definitions and supported states rather than recreating them from a screenshot.
Interaction need: Let someone choose an invoice status and clear the filter. If outside guidance helps with that interaction, adapt the behaviour into the existing components rather than importing another visual identity.
Gap: If a needed state is missing from the component library, flag it and propose an extension. Do not silently introduce a second button family.
Now the review has something concrete to compare against. Did the implementation use the existing components? Is a new style an intentional extension or an unexplained replacement? A polished screenshot alone cannot answer those questions.
An interaction pattern is not a brand
Choosing the visual system and borrowing an interaction pattern are separate decisions in DDM.
A filtering pattern might help organise choices. That does not mean the page needs the source system's colours, typography, or branding. The procedure says to borrow patterns when they solve the task, not to mix competing visual identities on one surface.
In the invoice example, an outside pattern would need a specific reason to be used. It is not a reason to replace the product's visual language. The question is what the interaction helps someone do, then how to express it within the system already chosen.
What if there is no system?
Then the platform matters. DDM's procedure gives selection rules rather than asking the agent to pick a favourite. For other web or cross-platform work with no system, it names Material 3 as the fallback, with implementation support checked.
That is a conditional fallback, not a ranking of design systems or an instruction to replace an existing one. The procedure also recognises documented bespoke or editorial direction. Use the applicable row, and check what the project's stack actually supports.
The accompanying reference asks the agent to inspect tokens, components, screenshots, and installed dependencies. Those are clues to investigate, not substitutes for understanding the project's visual decisions.
Try it
Choose the visual system is step 2 of DDM's six-step workflow. For your next feature request, ask the agent to identify the existing system, what it will reuse, and any gaps before it proposes new styling.
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. The README documents installation for Claude Code, Cursor, Gemini CLI, and Codex.
Top comments (0)