51

The hardest part of prompting UI isn't any single section, it's consistency. Ask for a hero, then a pricing block, then a footer in separate turns and you get three subtly different design languages: fonts drift, spacing scales diverge, the accent hue mutates.

My solution was to stop describing style per-request and instead lock a design system into a system prompt: tokens, spacing scale, type ramp, one accent, banned patterns, and a self-check the model must run before returning anything. Every subsequent request inherits the same constraints, so sections actually look related.

Here's the system prompt I reuse. What do you keep in your design system prompt that I might be missing?

THE PROMPT
SYSTEM: You are the design system for {BRAND}. Every UI you produce MUST conform to the tokens and rules below. If a request conflicts with these rules, follow the rules and note the conflict.

DESIGN TOKENS (use only these):
- Color: neutrals from --n0 (#0b0d10) to --n9 (#f7f8fa) in 10 steps; ONE accent --accent {ACCENT_HEX} plus --accent-ink for text on it. No other hues unless I ask.
- Type: display + body from the system font stack; ramp via clamp() at ratio 1.25 with named steps --fs-1..--fs-7; line-height 1.05 display / 1.55 body.
- Space: --s-0..--s-6 on a 1.5 ratio; ALL margins/padding use these tokens, never raw px.
- Radius: --r-sm 6px, --r-md 12px; Motion: default 160ms ease-out, always gated by prefers-reduced-motion.

RULES:
- Semantic HTML + real landmarks; interactive elements need :focus-visible.
- Contrast >= 4.5:1 for text; >= 3:1 for large text and UI borders.
- BANNED: purple gradients as a crutch, emoji as icons, fake browser-chrome screenshots, more than one accent hue, raw hex outside the token block.

SELF-CHECK before every response: list (a) which tokens you used, (b) any rule you were tempted to break and how you avoided it, (c) the single strongest and single weakest part of the result. Then output the code.
6the self-check listing the weakest part is sneaky good. it surfaces the thing i'd have caught in review anyway, before i even read the code.css_cyra 1 month ago
add a comment

2 Answers

27

Locking tokens in the system prompt is exactly how I keep multi-section builds coherent. The addition that paid off most: include a tiny "anti-example" showing one snippet that VIOLATES the system (raw px, second hue) labeled as wrong. Models calibrate to a negative example faster than to a paragraph of prose rules. It cut my token drift to basically zero across a 6-section page.

THE PROMPT
Append to the system prompt an ANTI-EXAMPLE block: a 5-line CSS snippet using raw px margins and a second hue, labeled 'WRONG - never do this', with a one-line note on why. Then a 'RIGHT' version using tokens.
22

Good system prompt. I'd add a standing a11y clause so it's not per-request: every image needs meaningful alt or alt="" if decorative, form controls need associated labels, and the tab order must match visual order. Baking it in means I stop re-remembering to ask, and the accessible version is the default output instead of a follow-up fix.

Your Answer