AI Design Generation Automation: From Random “Gacha” Output to a Production Pipeline

1. Why AI-Generated Design Drafts Are Often “Unusable”

Many teams that use large language models to generate UI designs experience the same problem: the more detailed the prompt, the less consistent the output. When the same requirement is generated multiple times, buttons may have different corner radii, shadows may vary in depth, icon styles may clash, and page elements may be placed without a consistent spacing grid. The result is often useful only as an inspiration sketch, not as a design draft that engineers can implement directly.

There are three structural reasons behind this problem:

• Missing constraints: Natural language describes intent, not rules. The model does not know the team’s spacing system, font-size scale, or color semantics, so it can only produce results that “look like design” based on its training distribution.
• Scattered context: Every new conversation starts from zero. If key design-system information is missing, the model will fill the gaps by guessing styles.
• No acceptance criteria: Generated results are not checked against any standard. Whether they are “usable” depends on visual inspection, and problems often surface only during implementation.

This leads to a key conclusion: generative models are good at exploring options, but they are not naturally good at maintaining long-term consistency in uncertain environments. To make their output reliable, the approach must change. Instead of repeatedly asking “why is this output not good enough?”, teams should treat the model like a distributed system: define clear boundaries, contracts, and validation steps, and manage it with engineering thinking.

2. Five Hard Constraints That Keep Model Output Under Control

The most effective approach after a retrospective is to distill the team’s design standards into a small set of hard, testable, reusable constraints, and require the model to follow them in every generation.

Dimension	Problem to Solve	Common Approach	Acceptance Metric
Componentization	Rebuilding wheels, inconsistent implementations	Only reference existing components from the component library; express variants through parameters	Number of custom-built base controls
Visual hierarchy	Confusing shadows and unclear spatial relationships	Use standardized elevation and shadow levels aligned with layout hierarchy	Number of non-standard shadow values
Interaction	Static screens only; missing states and motion	Explicitly annotate interaction states and transition parameters	Interaction-state coverage of key controls
Icon consistency	Mixed icon libraries, inconsistent sizes and stroke weights	Lock to a single icon source and a small set of fixed sizes	Number of icon sources and size variants
Typography	Random font sizes, excessive hierarchy, overly long lines	Use scale-based font sizes, line heights, and weights	Number of font sizes outside the scale; percentage of overly long text lines

1. Componentization: Do Not Rebuild Wheels

Models tend to “implement in place.” As a result, similar elements may differ widely in style and structure. The constraint is:

• Common controls must reference existing components from the design system.
• Differences should be expressed through component parameters, such as size, form, or emphasis level.
• If a required component is genuinely missing, the model should submit a “new component proposal,” and it can be added only after review.

Example:

{
  "type": "button",
  "variant": "primary",
  "size": "md",
  "label": "Submit",
  "icon": "check_circle",
  "iconPlacement": "leading"
}

2. Visual Hierarchy: Use a Unified Elevation and Shadow System

Shadows are not arbitrary blur effects. They communicate how far an element is from the user. Recommended practice:

• Define three or four elevation levels, such as:
  • elevation-1: cards floating above the canvas
  • elevation-2: dropdown panels
  • elevation-3: modal dialogs
• Bind each elevation level to fixed shadow parameters.
• Align elevation with stacking order and canvas layering.
• Do not stack shadows on elements at the same level, because that makes the interface look muddy.

3. Interaction: Put Interaction States into the Design Draft

Static screens cannot answer questions such as:

• What happens after a click?
• How does a disabled control look?
• How does a loading state behave?

Every interactive element should annotate the following states:

• default
• hover
• pressed
• focused
• disabled
• loading

State changes should also specify a consistent transition curve and duration. Focus states are especially important because they help keyboard users understand where they are on the page.

4. Icon Consistency: Lock to a Single Icon System

Mixing icons from different sources often leads to inconsistent stroke widths, corner radii, and visual weight. Even if the styles are similar, the result may still look unprofessional.

The constraint is:

• Use only one global icon source.
• Allow only a few fixed icon sizes, such as 16 px, 20 px, and 24 px.
• Icons should inherit the text color by default.
• Only specify a separate icon color for emphasis or special cases.

5. Typography: Follow a Strict Type Scale

Font size is not about “bigger means more important.” Hierarchy comes from contrast and consistency. Recommended rules:

• Build the type scale from a ratio such as 1.2 or 1.25.
• Bind each font size to fixed font weight, line height, and letter spacing.
• Limit the hierarchy in a single interface to 4–5 levels.
• Keep body text line length between 45 and 75 characters to maintain readable rhythm.

3. Turning Standards into an Executable Skill Package

If these constraints remain only in chat history, every conversation requires repeated explanation. That is inefficient and error-prone. A better approach is to package them into a structured rule set, similar to a “skill” specification in AI coding tools, so that the model can automatically load it when relevant tasks begin.

A minimal rule package can contain three files:

design-system-skill/
├── tokens.json        # Design atoms: colors, fonts, spacing, shadows, radii, etc.
├── components.md      # Component catalog: available components, parameters, composition patterns, examples
└── SKILL.md           # Skill instructions: when to apply, generation flow, quality checklist

tokens.json: Define the “Atoms” of Design

All colors, font sizes, spacing values, corner radii, and shadows should be declared as semantic variables. The model may reference these variables, but it should not write magic values directly.

Example:

{
  "color": {
    "text": {
      "primary":   { "light": "#1F2329", "dark": "#F2F3F5" },
      "secondary": { "light": "#646A73", "dark": "#BBBFC4" }
    },
    "bg": {
      "canvas": { "light": "#FFFFFF", "dark": "#17171A" },
      "surface": { "light": "#F7F8FA", "dark": "#1E1F22" }
    }
  },
  "font": {
    "scale": [12, 14, 16, 20, 24, 32],
    "lineHeight": { "sm": 1.4, "md": 1.5, "lg": 1.6 },
    "weight": { "regular": 400, "medium": 500, "semibold": 600 }
  },
  "space": [0, 4, 8, 12, 16, 24, 32, 48],
  "radius": { "sm": 4, "md": 8, "lg": 12 },
  "shadow": {
    "elevation-1": "0 1px 2px rgba(0,0,0,0.06), 0 1px 3px rgba(0,0,0,0.10)",
    "elevation-2": "0 4px 8px rgba(0,0,0,0.08), 0 2px 4px rgba(0,0,0,0.06)",
    "elevation-3": "0 12px 24px rgba(0,0,0,0.12), 0 4px 8px rgba(0,0,0,0.08)"
  }
}

components.md: Capture Proven Composition Patterns

Besides listing available components and their parameters, this file should provide examples of how to compose them. Common patterns include:

• page shells
• list items
• form rows
• empty states
• feedback messages

When the model follows mature patterns, the output is much less likely to be “plausible but non-compliant.”

SKILL.md: Constrain the Behavior Flow

This file should define:

• when the skill applies
• what steps must be executed and in what order
• what outputs are required
• what must be checked before delivery

A simplified quality checklist can contain six questions:

1. Do all base controls reference components from the component library?
2. Do all colors, spacing values, font sizes, radii, and shadows come from tokens.json?
3. Are shadows limited to the defined elevation levels?
4. Do interactive elements include a complete set of states?
5. Do icons come only from the approved source and approved sizes?
6. Will the longest text overflow when rendered in the narrowest container?

The essence of this rule package is to turn “tacit aesthetic experience” into “machine-readable, executable standards.” This is consistent with the idea of design-system documentation and is a prerequisite for making AI-generated output stable.

4. Common Pitfalls That Require Extra Attention

Even with a rule package in place, several issues are still easy to get wrong during generation.

1. Icon Size Properties Must Be Set Together

Many design tools do not use an open-source line-icon library by default. Instead, they often use a built-in set of geometric, rounded icons. Because models have seen many icon-library conventions during training, they may generate inconsistent icon usage from memory.

More importantly, if only the font size is set without declaring width and height, icons may not display correctly. Icon usage should be standardized into a fixed template:

{
  "type": "icon",
  "name": "search",
  "fontSize": 20,
  "width": 20,
  "height": 20,
  "color": "color.text.secondary"
}

2. Text Must Be Protected from Overflow

By default, long text keeps expanding its container. This can break the layout of buttons, tags, and table cells.

For fixed-width text elements, define a fixed-width growth strategy and use ellipsis when truncation is required. Edge cases should also be tested, including:

• long Latin words
• mixed Chinese and Latin text
• long numeric strings

Extreme placeholder text can be used for stress testing.

3. Reference Colors by Semantic Name, Not Hard-Coded Hex Values

Design drafts usually need to support both light and dark themes. If the model writes hard-coded hexadecimal values, theme switching can produce problems such as black text on a black background or insufficient contrast.

The better approach is to require semantic color variables, such as:

"color": "color.text.primary"

The design tool can then map the semantic variable to the correct value for the current theme.

4. Accessibility Checks Cannot Be Skipped

Accessibility must be part of the acceptance criteria:

• Body text should have a contrast ratio of at least 4.5:1 against its background.
• Large text should have a contrast ratio of at least 3:1.
• Status information should not be conveyed by color alone. Icons, text labels, or underlines should also be used so that color-vision-impaired users can distinguish states.
• Touch targets should be at least 44 × 44 px to ensure usability on mobile devices.

5. Include “Historical Baggage” in the Rule Package

Models do not know the current state of the project. They may add another button component or card component on top of existing pages. Adding a “forbidden list” to the rule package can reduce this problem. The list may include:

• deprecated components
• unused color variables
• obsolete patterns that should no longer be used

This helps prevent old and new styles from coexisting in the same interface.

5. End-to-End Workflow: Embedding Generation into the Design Process

A rule package solves consistency, but delivering usable design drafts also requires a complete pipeline:

Requirement input → Structured task description → Load rule package → Generate screen by screen → Automatic validation → Human review → Asset feedback

1. Structure the Requirement

Break vague requirements into:

• page inventory
• user roles
• core flows
• state lists, such as empty, loading, error, and no-permission states
• acceptance criteria

Only then should the requirement be passed to the model.

2. Generate in Stages

Start with page skeletons and component mapping. After confirmation, add detailed styles. This avoids large-scale rework after generating many pages at once.

3. Run Automatic Validation

Scripts can perform static checks on the generated output. For example:

• colors, font sizes, and spacing values must come from variables
• icon size properties must be complete
• shadows must use elevation levels

Example validation logic:

import re
RADIUS_PATTERN = re.compile(r"radius\.(sm|md|lg)")
def lint_design_json(nodes, tokens):
    radius_values = set(tokens["radius"].values())
    issues = []
    for node in nodes:
        ntype = node.get("type")
        # Icon nodes must define font size, width, and height together.
        if ntype == "icon":
            size_keys = ("fontSize", "width", "height")
            if not all(node.get(k) for k in size_keys):
                issues.append(f"Icon '{node.get('name')}' is missing size properties")
        # Radius values must reference the token scale or an approved radius value.
        if "radius" in node and not RADIUS_PATTERN.fullmatch(str(node["radius"])):
            if node["radius"] not in radius_values:
                issues.append(f"Node '{node.get('id')}' uses a non-standard radius: {node['radius']}")
        # Long text nodes must have fixed-width overflow protection.
        if ntype in {"text", "label"} and node.get("fixedWidth") is False:
            if len(node.get("content", "")) > node.get("maxChars", 20):
                issues.append(f"Text node '{node.get('id')}' has long content without fixed-width handling")
    return issues

4. Human Review

Machine validation can check compliance, but it cannot judge whether the design is actually usable. Information hierarchy, business semantics, and brand tone still require human review.

5. Feed Assets Back into the System

High-quality human-corrected outputs should become new component templates or examples and be written back into the rule package. This creates a closed loop:

generation → validation → correction → knowledge accumulation

6. Industry Impact: Where Designers Add Value

Returning to the original question: how will AI-generated design drafts affect the design profession? Based on the practices above, the impact can be seen at three levels.

1. Execution Work Will Be Greatly Reduced

Repetitive tasks such as building grids, enumerating component variants, adapting designs for multiple platforms, and annotating states can be handled by AI. Design will shift from “pixel-by-pixel drawing” to “defining rules and reviewing output.” Design throughput per unit of time will increase, and the drawing component of junior roles will decline.

2. Role Boundaries Will Be Redefined

Designers will add more value in:

• problem definition
• experience strategy
• information architecture
• design-system governance

The ability to translate business goals into clear constraints, and to define standards that AI can execute correctly, will become a new core competency. Demand for design-system-related roles may increase, while purely visual execution roles may face pressure.

3. Collaboration Will Move to Structured Artifacts

When design drafts carry component parameters and variable references, the deliverable between design and engineering is no longer just “images plus annotation documents.” It becomes structured, verifiable data. Design assets can be managed with version control and automated checks, similar to code review, static analysis, and continuous integration. The collaboration barrier may decrease, but both sides will need a deeper shared understanding of standards.

However, disruption does not mean replacement. Aesthetic judgment, user insight, brand expression, and emotional design still rely heavily on human experience and value judgment. AI can also amplify mistakes. Without review, non-compliant output—such as designs that violate accessibility requirements or brand standards—can be reproduced at scale.

Therefore, a more reasonable positioning is: AI is an amplifier for designers. It amplifies the quality of rules, not the quantity of labor.

7. Conclusion

Making AI produce usable design drafts is fundamentally a problem of constraint design. The model can be guided by five main constraints:

• componentization
• visual hierarchy
• interaction states
• icon consistency
• typography

Standards can be solidified through design tokens, component templates, and skill specifications. Quality can be protected through checklists and automated validation. With this approach, AI-generated design work can move from random “gacha” output to a stable production pipeline.

This method—making tacit experience explicit, and making explicit rules automated—also applies to related scenarios such as UI code generation and front-end component development. For designers, the real challenge is not whether they will be replaced, but whether they can move from being “drawers” to being “rule makers.”