Six constraints that fixed most of the AI-generated UI I reviewed
Once I understood that the system was missing behavioral constraints, I started logging AI-generated UI mistakes instead of quietly fixing them.
After a few dozen screens, the failures stopped feeling random. The same problems kept returning.
The rules below belong to one design system. The useful part is the method: identify repeated failures, then write the smallest constraint that prevents each one.
1. The accent color became a paint bucket
The brand color appeared in headers, sidebars, section titles, buttons, and icon backgrounds at the same time.
The reason was understandable. The token was called primary, so the model treated it as the default.
The fix was to define a color budget. In our system, the accent covers roughly ten percent of a screen. It can highlight the main action or active state, but it cannot become a structural surface.
The negative rule mattered most: never use the accent as a page or card background.
2. Cards disappeared into the canvas
The system had several neutral colors, but it did not explain their relationship. AI selected valid gray values for both the canvas and the cards, leaving no visible separation between them.
I named three surface levels: canvas, panel, and card. Each one needed a distinct treatment, and a card could never reuse the canvas background.
This sounds obvious when looking at a finished product. It is less obvious when the only guidance is a list of neutral tokens.
3. Every action looked equally important
Some generated cards contained several filled buttons. Each action was valid, but the interface gave users no clue where to begin.
The rule became simple: one primary action per card. Secondary actions use a quieter treatment.
If two actions genuinely need equal weight, the card may be trying to do two different jobs.
4. Disabled states relied on opacity
Reducing opacity is a quick way to make something look unavailable. It is also unreliable. Text can fall below contrast requirements, and disabled elements become muddy when placed on colored surfaces.
The system now uses explicit muted foreground and background tokens for disabled states. Opacity is not part of the treatment.
One sentence removed a repeated accessibility problem.
5. Interaction states were being invented
Hover behavior changed from one component to another. Some elements gained shadows. Others became lighter or scaled slightly. Focus rings were often missing.
I replaced the ambiguity with a small state table. Each state had one defined visual change.
Focus received its own rule because it was the easiest state to lose and one of the most important for people navigating without a mouse.
6. Information looked interactive
Status labels and category chips were frequently shown in the brand color. That made passive information look clickable or urgent.
The rule now separates information from action. Informational chips stay neutral. Brand color is reserved for the few statuses that require attention.
The format mattered as much as the rules
I originally documented these ideas in paragraphs. They were easy to skim and easy to reinterpret.
Tables worked better. Do and don't. State and visual change. Element and allowed color.
The structure forced me to be more precise too. Phrases such as “generally prefer” look obviously weak inside a table cell. A constraint needs to say what should happen.
I also learned not to document every isolated mistake. A few early rules were responses to one unusual screen and added more noise than value.
Logging the failures first made the recurring patterns visible. Frequency showed me what was worth constraining.
The goal is not to control every pixel. It is to prevent the small set of mistakes that repeatedly pull the product away from its intended design.
