How to Design UI Systems With an Agent

UI system design is the process of turning a component or interface request into a spec that extends the product's existing design system instead of creating another one-off. The work includes requirements, multiple design directions, domain-model checks, token and component reuse, state coverage, accessibility review, and human approval before anything becomes canonical.

The value is consistency. A rushed design can look acceptable in one screenshot while adding a new pattern, a new token, a new state rule, or a new accessibility gap that engineers and users pay for later. A useful process keeps exploration wide, then narrows on a spec that the system can actually absorb.

Why UI one-offs quietly fragment products

Design systems usually break by accumulation, not by one big mistake. A page adds a local dropdown because it is faster. A component grows a boolean prop for one case. Empty, loading, error, disabled, focus, and mobile states are left for implementation. The product still ships, but the next designer or engineer inherits a wider surface with less clarity.

The hidden cost is decision debt. Teams spend review time debating details that should have been encoded in components, tokens, and composition patterns. Users notice the inconsistency as friction: similar controls behave differently, forms recover from errors differently, and keyboard focus becomes unreliable.

What the manual process looks like

A good UI system design process has five steps:

1. Gather requirements: the problem, the caller or user, key operations, constraints, and what the interface should expose or hide.
2. Map visible elements back to the domain model and flag anything the model cannot support.
3. Explore at least three genuinely different directions: minimal surface, flexible surface, common-case optimization, or a borrowed paradigm.
4. Compare the directions on simplicity, depth, system fit, implementation efficiency, and misuse-resistance.
5. Write an annotated spec covering components, tokens, composition pattern, every state, accessibility, keyboard behavior, responsiveness, and any system gaps, then get approval.

The manual version requires discipline because the first plausible design is rarely the best one. The point is not to generate more artifacts. It is to force real alternatives before choosing.

What an agent can automate

The UI Design-System / Interface Designer playbook is useful when the agent is constrained to design, not implement:

• Gather system-aware requirements. The agent captures the problem, callers, key interactions, constraints, exposed concepts, and hidden complexity before drawing the interface.
• Explore distinct directions. It produces at least three different approaches, with each direction shaped by a different constraint. The directions must not collapse into cosmetic variants.
• Compare before synthesis. It evaluates simplicity, depth, general-purpose fit, implementation efficiency, and misuse-resistance, then combines the best ideas into one spec.
• Reuse before adding. It names the existing components and tokens the spec reuses or extends. If a new component or token seems necessary, it flags that as a system gap.
• Audit every state. It checks default, hover, focus, active, disabled, loading, empty, and error states, plus contrast, keyboard behavior, motion, responsiveness, and form validation.

The human still decides whether the direction fits the product and whether any flagged system or domain gap should become real.

The guardrails that make it safe

Design agents need boundaries because they can create convincing artifacts that do not fit the product. The safe workflow keeps the agent in spec mode and routes the final result through approval. When a design tool is connected, the agent works through the browser and pauses before making changes.

The other guardrail is the design-system check. The agent must state what it reused, what it extended, which states are covered, and which gaps remain. If the request conflicts with the domain model or demands a new pattern, the workflow should ask instead of designing around the conflict silently.

Set it up in Task Machine

The UI Design-System / Interface Designer playbook installs the UI Designer, design-interface workflow, goal, and skills for interface design, web interface guidelines, and composition patterns. Setup takes a few minutes. You need a Task Machine workspace and permission to install playbooks (workspace owners have it). Design tool access is not required up front. Until it is authorized, the workflow can work from attached exports, screenshots, and repository context.

1. Find the playbook

Open Playbooks in your workspace and search for "UI design system", or browse the Design category. The card shows the designer agent and the workflow that turns interface requests into approved specs.

2. Preview what it installs

Preview & install shows the UI Designer, the Design interface workflow, the UI extends the system goal, and the three skills that govern interface exploration, web guidelines, and composition patterns.

3. Define the design-system scope

Start setup asks for the product surface, brand direction, component needs, and repository. Use the component needs field for the actual parts the spec must cover, such as filters, tables, empty states, and approval modals.

4. Generate and review

Generate customized playbook turns the scope into the designer instructions, workflow prompts, and goal language. Review the generated records for the important constraints: multiple directions first, existing components and tokens first, every state covered, and approval before the spec is treated as final.

5. Install

Install customized playbook creates the designer, workflow, goal, and skills. One follow-up arrives in your inbox to start Design interface. The first run gathers requirements, explores directions, writes the annotated spec, self-critiques it against system and accessibility rules, and waits for approval.

What good looks like

Three checks show whether the design workflow is producing useful specs:

• The directions are genuinely different. They vary by interface shape and tradeoff, not only by visual treatment.
• The spec extends the system. Existing components and tokens are named, and any new component or token is flagged as a decision.
• States are complete. The spec covers interaction, loading, empty, disabled, error, focus, mobile, motion, and accessibility requirements before approval.

Common questions

Does the agent implement the UI? No. This playbook produces an annotated interface spec and routes it for approval. Implementation is a separate workflow.

Can it work without Figma or another design tool connected? Yes. It can work from attached exports, screenshots, and repository context until browser access to the design tool is ready.

Why require multiple design directions? The first reasonable interface often hides a shallow component shape or a future misuse problem. Comparing distinct directions makes the final spec more deliberate.

What happens if the request conflicts with the design system? The agent should flag the conflict as a system gap or product decision. It should not invent a local workaround and present it as system-consistent.