🎨Designing UI With AI
How to get beautiful, consistent interfaces without becoming a designer first.
What you'll get
- Define a design system in plain English
- Use semantic tokens instead of raw colours
- Build a small set of primitives every screen reuses
- Get consistent UI across every page of your app
Most AI-built apps look generic because the prompt was generic. Five extra sentences about your brand turn a template into a product. This guide shows you the exact layered structure professional design systems use — and how to describe it to an AI.
Name the vibe before you build
Before any feature, describe the feeling. 'Editorial, warm, confident. Inspired by Notion and Stripe. Soft pastel backgrounds, deep slate ink, one accent gradient.' This single paragraph does more for visual quality than any later tweak.
Reference real products by name. 'Stripe-like' means more to an AI than 'modern' ever will. Pick two or three references that share a feeling and name them in the brief.
Aesthetic: editorial, warm, confident. Reference: Notion's calm density and Stripe's gradient accents. Avoid: cold tech-bro purple-on-black.
Tokens, not hex codes
A token is a name for a value. Instead of `#7C3AED` scattered through 40 files, you have `--primary` defined in one place. When you change one variable, the whole app updates. When you don't, every redesign is a search-and-replace nightmare.
Ask the AI to define tokens for colour, spacing, radius, and type, and to use those tokens everywhere. Ban raw hex codes from component files.
- `bg-[#7C3AED]` in 40 files
- Every redesign is a global find-and-replace
- Dark mode means rewriting every component
- New screens drift visually from old ones
- `bg-primary` everywhere
- Redesign = edit one CSS variable
- Dark mode = a second token block
- New screens inherit the system for free
Define semantic tokens: --background, --foreground, --primary, --accent, --muted, --border. Use OKLCH. Light and dark variants. All components must use tokens, never raw hex.
Build the primitives once
Once tokens are in place, build a small set of primitive components: a glass card, a gradient button, a section heading, a callout. Build each one once, with proper variants, and ask the AI to compose every new screen from those primitives.
The discipline is what produces consistency. Without primitives, every page invents its own padding, its own card style, its own heading size — and the app feels stitched together from five different products.
Compose, don't redesign
When you ask for a new page, name the primitives. 'Build the pricing page using only GlassCard, GradientButton, and SectionHeading from our component library.' The AI will obey — and the new page will feel like it belongs.
If you ever feel the need to invent a new primitive, do it deliberately. Add it to the library, document it, and use it in two places before considering it official.
Build the pricing page using only GlassCard, GradientButton, and SectionHeading. Three tiers in a responsive grid. No new components.
Accessibility as a constraint
Beauty without accessibility is just decoration. Every design pass should include a contrast and keyboard-nav check. The good news: this is one of the easiest things to delegate to the AI.
Add a self-review prompt at the end of every visual change asking the AI to check WCAG AA contrast and keyboard focus order.
Before and after
A small example of what changes when you treat design as a system instead of a series of one-off prompts.
- Inter, purple gradient, white card
- Each page slightly different
- Random shadows, random radii
- Looks like a template
- Custom typography pairing
- Every page reuses the same primitives
- One shadow scale, one radius scale
- Looks like a product
Prompt examples
Define a soft pastel design system: warm off-white background, deep slate ink, indigo→violet gradient as the primary accent, mint and peach as secondary accents. Use OKLCH tokens.
Build the pricing page using only GlassCard, GradientButton, and SectionHeading from our component library.
Audit this page for WCAG AA contrast and keyboard focus order. List any failures and propose a fix for each.
- Hard-coding hex colours in every component
- Asking for 'modern' without examples
- Letting each new page invent its own spacing
- Skipping accessibility because 'we'll add it later'
- Tokens live in one file. Components consume tokens. Pages compose components.
- Reference real products you admire by name
- Audit every new screen against your existing primitives
- Add a contrast check to your end-of-change ritual
Design changes ship like any other change — but consider taking a screenshot before/after each big design pass so you can show the progress.