Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
If an AI coding agent keeps removing important controls, reshuffling a screen, or forgetting choices from earlier prompts, put those decisions in a short project record it can access. Define the user and task, retain the existing design system, specify what each view must contain, and record consequential choices with their reasons. Then ask the agent to work from that record and check the result yourself.
Why the same UI corrections keep coming back
A prompt describes the change you want now; it may not capture the decisions that should govern the whole interface. Without shared context, an agent can satisfy one instruction while overlooking a frequent task, a required action, or a navigation choice made in a prior exchange. Repeating corrections is often a sign that the team has not made those underlying decisions explicit and reusable.
A lightweight design decision workflow can help people and agents reach a shared starting point before implementation. It is a procedure for deciding what a screen needs and why—not a UI library or a new visual standard. The approach described in Stop correcting your AI’s UI on every prompt draws on object-oriented UX mapping, GOV.UK, Carbon, Material 3, platform guidance, and project rules.
Use a decision record before asking for another layout
Keep the record somewhere the coding agent can actually access, such as a project specification or a file included with the task. It need not be long: capture the context, constraints, view requirements, and decisions that would be costly to undo.
#1 Best Overall
1. Establish the context
Record who uses the screen, how often they do the task, what happens if they make a mistake, and which device or form factor matters. Mark what is known separately from what is assumed. This keeps a design choice from quietly treating an unverified guess as a requirement.
2. Choose the visual system
Use the project’s existing design system when it fits. If there is no system, select a suitable platform system; the cited workflow names Material 3 as its fallback for web work. Don’t switch systems merely because a prompt asks for a different look: first decide whether the current system serves the task and users.
Reusable styles, components, and patterns help teams keep services consistent and avoid repeating work. The GOV.UK Design System provides examples, while its getting-started guidance explains that examples include code and information about how and when they have been tested in user research. Community discussion is not equivalent to tested guidance; adapt patterns with care and research where appropriate.
3. Map objects when their relationships affect the interface
Identify the important objects and how they relate before settling on layout if those relationships could change routes, navigation, or screen structure. Skip this step when object relationships would not affect those decisions. The point is to resolve structural questions early, not to add modeling overhead to every small edit.
Rank #3
4. Preserve decisions that are costly to reverse
Write down the choice and its reason—for example, whether a setting belongs on the main screen or behind a secondary route, or why a particular action must remain visible. A rationale helps the next prompt distinguish a deliberate choice from an accidental detail. Keep the record focused on decisions likely to be lost or expensive to revisit.
5. Specify each view’s purpose and states
For every view, state what it is for, what information it must show, and which actions it must support. Include the actual loading, empty, and error states rather than describing only the ideal populated screen. This gives the agent concrete requirements to preserve when it proposes a layout.
6. Deliver and validate honestly
Give the agent the decision record with the implementation request, then inspect the result against it. Label the level of validation accurately: proposed, heuristic, automated, manual, or user research. State what was not tested; do not imply that a screen has been tested with users if it has only been reviewed by the team.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Example: an account-settings screen
Suppose an agent repeatedly returns a grid when you want a simpler settings page, then drops important controls after another correction. Before requesting another redesign, identify who changes the settings, which changes happen often, which mistakes would be costly, and which objects or relationships affect navigation.
Use those answers to specify the page’s purpose, the information and actions it must include, and the real states it needs. Record whether key controls must stay visible or can live behind a route, along with the reason. Then ask the agent to revise the page using that record. The team still needs to check that the implementation follows the decisions and works for its intended users.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to judge a proposed layout
When an agent offers more than one arrangement, compare them against the same criteria instead of choosing by appearance alone:
- Task and context: Does the layout fit the users, device, frequency of use, and cost of error?
- Required content and actions: Are all specified information and controls present?
- Visibility: Are frequent or consequential settings easy enough to find?
- System consistency: Does the proposal use the existing design system appropriately, or is a variation justified?
- States and validation: Does it account for loading, empty, and error states, and is the level of testing described accurately?
These are decision criteria, not a measured ranking of layouts. The DWP Design System guidance recommends starting with standard patterns and components, comparing proposed variants with the standard in research, and continuing user research even when standard patterns are used. A design system is a starting point, not a substitute for understanding the people using the service.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Keep the process proportional
You do not need a full decision record for every small visual edit. Use the workflow when repeated corrections signal that the agent lacks durable context, or when a choice about navigation, visibility, or required content would be costly to reverse. For a narrow change with clear constraints, state the requirement directly and move on.
The workflow is a practical suggestion, not a proven productivity technique. The article describing it says, “Whether it saves time has not been measured.” It also cannot make an agent retain decisions on its own: the relevant record must be available to the tool, and a person must review the output.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
