Design Systems for AI Products: Components That Expect Uncertainty

Most design systems were built for deterministic UIs: forms submit, tables load, buttons do one thing. AI products break that contract. Answers arrive in chunks, citations appear late, tools may fail mid-run, and the same prompt can produce different shapes of output. If your system only has success/error/empty, every AI feature becomes a one-off collage of spinners and apology copy.

Treat model behavior as a first-class state machine

Ship shared states for AI surfaces the way you ship loading and disabled for buttons. Name them in the system: idle, streaming, tool-running, waiting-for-approval, partial-success, refused, and failed-recoverable. Designers and engineers should reuse the same vocabulary in Figma and code. When every squad invents its own "thinking…" treatment, users learn that AI feels unfinished.

• Streaming: progressive text with a stable layout that does not jump when tokens arrive
• Tool-running: named activity ("Checking inventory") instead of a generic pulse
• Partial-success: show what completed and what did not — never imply a full win
• Refused / failed-recoverable: clear next actions, not a dead-end toast

Tokens for trust, not just color

Extend the token set beyond brand and spacing. AI products need tokens for citation chips, source confidence, human-approval badges, and "model suggested / human confirmed" distinctions. If those signals are improvised per feature, users cannot tell what is verified. Make provenance readable at a glance — and make the unverified path look deliberately quieter, not louder.

Citations are UI, not footnotes

Define citation components once: inline markers, source cards, missing-source states, and click-through behavior. Pair them with content rules: no citation chrome when retrieval returned nothing; no fake document titles. A design system that allows decorative "source" pills without data is worse than no citation UI at all.

Compose for non-deterministic content

Layouts must tolerate variable length, missing fields, and structured objects that occasionally fail schema. Prefer resilient composition: reserved space for streaming, collapse rules for empty sections, and typed result cards (summary, list, form draft, action proposal) instead of one free-form blob. When the model returns a structured object, render it through system components — do not drop raw JSON into the page "for now."

• Result cards mapped to schemas your API already validates
• Action proposals that require explicit confirm for irreversible writes
• Diff / before-after patterns for rewrites so users see the change
• Empty and refusal templates that teach the product’s limits without blaming the user

“If your design system cannot express "we’re not sure yet," your AI UI will fake certainty — and users will remember the first wrong answer.”

Motion and feedback with a job

Motion should signal progress through the state machine, not decorate it. Streaming caret or gentle content reveal shows work in flight; a sudden full-block swap feels like a glitch. Keep durations short, respect reduced-motion, and never animate in a way that hides the cancel or stop control. Latency without a cancel affordance is a trap, not a feature.

Governance: AI patterns need owners

Add AI patterns to the same contribution path as buttons and forms: documented anatomy, do/don’t, accessibility notes (live regions for streaming, focus management after tool completion), and coded examples. Review AI UI PRs for system reuse the way you review color hardcoding. At Brutanix Studios we extend design systems for AI the same way we extend APIs — with shared contracts, explicit failure modes, and components that make uncertainty honest instead of ornamental.