Interface Design
For interface design — dashboards, admin panels, apps, tools, and interactive products. NOT for marketing design (landing pages, campaigns).
Build interface design with craft and consistency.
Scope
Use for: Dashboards, admin panels, SaaS apps, tools, settings pages, data interfaces.
Not for: Landing pages, marketing sites, campaigns. Redirect those to frontend-design.
The Problem
You will generate generic output. Your training has seen thousands of dashboards. The patterns are strong.
You can follow the entire process below — explore the domain, name a signature, state your intent — and still produce a template. Warm colors on cold structures. Friendly fonts on generic layouts. This happens because intent lives in prose, but code generation pulls from patterns. The gap between them is where defaults win.
Process alone doesn't guarantee craft. You have to catch yourself.
Where Defaults Hide
Defaults don't announce themselves. They disguise themselves as infrastructure — the parts that feel like they just need to work, not be designed.
Typography feels like a container. Pick something readable, move on. But typography isn't holding your design — it IS your design. The weight of a headline, the personality of a label, the texture of a paragraph. If you're reaching for your usual font, you're not designing.
Navigation feels like scaffolding. Build the sidebar, add the links, get to the real work. But navigation isn't around your product — it IS your product. Where you are, where you can go, what matters most. The navigation teaches people how to think about the space they're in.
Data feels like presentation. You have numbers, show numbers. But a number on screen is not design. The question is: what does this number mean to the person looking at it? What will they do with it? If you're reaching for number-on-label, you're not designing.
Token names feel like implementation detail. But your CSS variables are design decisions. --ink and --parchment evoke a world. --gray-700 and --surface-2 evoke a template. Someone reading only your tokens should be able to guess what product this is.
The trap is thinking some decisions are creative and others are structural. There are no structural decisions. Everything is design.
Intent First
Before touching code, answer these. Not in your head — out loud.
Who is this human? Not "users." The actual person. Where are they when they open this? What's on their mind? Their world shapes the interface.
What must they accomplish? Not "use the dashboard." The verb. Grade these submissions. Find the broken deployment. The answer determines what leads, what follows, what hides.
What should this feel like? Say it in words that mean something. "Clean and modern" means nothing — every AI says that. Warm like a notebook? Cold like a terminal? Dense like a trading floor?
If you cannot answer these with specifics, stop. Ask the user. Do not guess. Do not default.
Every Choice Must Be A Choice
For every decision, you must be able to explain WHY. If your answer is "it's common" or "it's clean" or "it works" — you haven't chosen. You've defaulted. Defaults are invisible. Invisible choices compound into generic output.
The test: If you swapped your choices for the most common alternatives and the design didn't feel meaningfully different, you never made real choices.
Sameness Is Failure
If another AI, given a similar prompt, would produce substantially the same output — you have failed. When you design from intent, sameness becomes impossible because no two intents are identical. When you design from defaults, everything looks the same because defaults are shared.
Intent Must Be Systemic
Saying "warm" and using cold colors is not following through. If the intent is warm: surfaces, text, borders, accents, semantic colors, typography — all warm. Check your output against your stated intent.
Product Domain Exploration
Generic output: Task type → Visual template → Theme Crafted output: Task type → Product domain → Signature → Structure + Expression
Do not propose any direction until you produce all four:
- Domain: Concepts, metaphors, vocabulary from this product's world. Minimum 5.
- Color world: What colors exist naturally in this product's domain? If this product were a physical space, what would you see? List 5+.
- Signature: One element — visual, structural, or interaction — that could only exist for THIS product. If you can't name one, keep exploring.
- Defaults: 3 obvious choices for this interface type — visual AND structural. You can't avoid patterns you haven't named.
The test: Read your proposal. Remove the product name. Could someone identify what this is for? If not, it's generic.
The Mandate
Before showing the user, look at what you made. Ask yourself: "If they said this lacks craft, what would they mean?" That thing you just thought of — fix it first.
Run these checks against your output before presenting:
- The swap test: If you swapped the typeface for your usual one, would anyone notice? The places where swapping wouldn't matter are the places you defaulted.
- The squint test: Blur your eyes. Can you still perceive hierarchy? Craft whispers.
- The signature test: Can you point to five specific elements where your signature appears?
- The token test: Read your CSS variables out loud. Do they sound like they belong to this product's world?
If any check fails, iterate before showing.
Craft Foundations
Subtle Layering
Surfaces stack. Build a numbered elevation system — each jump only a few percentage points of lightness. Whisper-quiet shifts that you feel rather than see.
- Sidebars: Same background as canvas, not different. A subtle border is enough separation.
- Dropdowns: One level above their parent surface.
- Inputs: Slightly darker than their surroundings — inset, receiving content.
Borders should disappear when you're not looking for them, but be findable when you need structure. Low-opacity color blends with the background; build a border progression matched to boundary importance.
Infinite Expression
Every pattern has infinite expressions. No interface should look the same. Linear's cards don't look like Notion's. Vercel's metrics don't look like Stripe's. Same concepts, infinite expressions.
Color Lives Somewhere
Every product exists in a world. Your palette should feel like it came FROM somewhere — not like it was applied TO something. Gray builds structure. Color communicates — status, action, emphasis, identity. One accent color, used with intention, beats five colors used without thought.
Design Principles
- Token architecture: Every color traces back to primitives: foreground (4 levels: primary/secondary/tertiary/muted), background (elevation), border (progression), brand, semantic.
- Spacing: Pick a base unit, stick to multiples. Random values signal no system.
- Depth: Choose ONE approach and commit: borders-only / subtle shadows / layered shadows / surface tints. Don't mix.
- Radius: Sharper feels technical, rounder feels friendly. Build a scale; don't mix randomly.
- Typography: Distinct levels via size + weight + letter-spacing combined. Data needs monospace with tabular figures.
- Controls: Native
<select>and date inputs render OS-native — build custom components when styling matters. - States: Every interactive element needs default/hover/active/focus/disabled. Data needs loading/empty/error. Missing states feel broken.
- Dark mode: Shadows less visible — lean on borders. Semantic colors often need desaturation.
Avoid
Harsh borders · dramatic surface jumps · inconsistent spacing · mixed depth strategies · missing states · dramatic drop shadows · large radius on small elements · pure white cards on colored grounds · thick decorative borders · decoration-only gradients · multiple accent colors · different hues per surface (keep hue, shift lightness)
Workflow
Be invisible — don't announce modes. Lead with exploration and recommendation, then confirm direction. If a DESIGN.md exists, read it and apply — decisions are made. Otherwise: explore → propose → confirm → build → evaluate → offer to save patterns back to DESIGN.md.