interface-design

Interface Design

Build product interfaces with the craft of a top design team — Linear, Vercel, Stripe, Apple. The difference between those and generic output is not talent. It is that every decision was decided, the hierarchy is unmistakable, and a hundred small details are correct at once. This skill is how you get there.

Scope

Use for: Dashboards, admin panels, SaaS apps, tools, settings pages, data interfaces.

Not for: Landing pages, marketing sites, campaigns, brand-only work. Use a marketing/frontend design skill for those.

This skill is self-contained: direction, visual hierarchy, design-system architecture, and the polish and motion essentials needed to ship production-grade UI all live here.

---

The Problem

You will generate generic output. Your training has seen thousands of dashboards, and the patterns are strong. You can follow this entire process — 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 helps, but it doesn't guarantee craft. You have to catch yourself, and you have to know the concrete moves that defaults don't.

The bar: If another AI, given a similar prompt, would produce substantially the same output, you have failed. Not different for its own sake — different because the interface emerged from this user, this task, this world. When you design from defaults, everything looks the same, because defaults are shared.

---

Where Defaults Hide

Defaults disguise themselves as infrastructure — the parts that feel like they just need to work, not be designed.

• Typography feels like a container. But type isn't holding your design, it is your design. The weight of a headline, the personality of a label, the texture of a paragraph shape how the product feels before anyone reads a word. Reaching for your usual font means you're not designing.
• Navigation feels like scaffolding. But navigation is the product — where you are, where you can go, what matters. A page floating in space is a component demo, not software.
• Data feels like presentation. But a number on screen is not design. What does it mean to the person looking? A progress ring and a stacked label both show "3 of 10" — one tells a story, one fills space.
• Token names feel like implementation detail. But --ink and --parchment evoke a world; --gray-700 and --surface-2 evoke a template. Someone reading only your tokens should guess what product this is.

There are no structural decisions. Everything is design. The moment you stop asking "why this?" is the moment defaults take over.

---

Intent First

Before touching code, answer these. Keep it a compact working brief unless the direction needs user confirmation.

• Who is this human? Not "users." The actual person. Where are they when they open this? What did they do 5 minutes ago, what will they do 5 minutes after? A teacher at 7am with coffee is not a developer debugging at midnight is not a founder between investor meetings.
• What must they accomplish? The verb. Grade these submissions. Find the broken deployment. Approve the payment. The answer determines what leads, what follows, what hides.
• What should this feel like? 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? Calm like a reading app? This shapes color, type, spacing, density — everything.

If the prompt is too vague to identify the human, task, and feel, ask one concise question. If context allows a responsible assumption, state it briefly and proceed.

Intent must be systemic. Saying "warm" then using cold colors is not following through. If the intent is warm: surfaces, text, borders, accents, semantic colors, type — all warm. If dense: spacing, type size, information architecture — all dense. Check every token against the stated intent. For every choice — layout, color temperature, typeface, spacing scale, hierarchy — you must be able to say why. "It's common" or "it works" means you defaulted.

---

Product Domain Exploration

This is where defaults get caught — or don't. Generic path: Task type → visual template → theme. Crafted path: Task type → product domain → signature → structure + expression. The difference is time spent in the product's world before any visual thinking.

Produce all four before proposing any direction:

• Domain — concepts, metaphors, vocabulary from this product's world. Not features — territory. Minimum 5.
• Color world — what colors exist naturally here? Not "warm" or "cool" — go to the actual world. 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 with the product name removed. Could someone identify what it's for? If not, explore deeper.

---

Render It When You Can

If an inline visual-rendering tool is available in the session (e.g. a show_widget / visualize tool that renders HTML or SVG inline in the conversation), prefer showing the design over describing it. A direction trapped in prose is a fraction as useful as one the person can look at. This is conditional: when no such tool is present (CI, headless agents, plain terminals), fall back to code, tokens, and a written proposal. Never assume the tool exists; check, then use it.

Render at three moments:

1. Proposing a direction. Alongside the Suggest + Ask block, render a small live specimen: the palette as actual swatches, the type scale in the real typeface, the surface-elevation steps as stacked cards, the signature element as a real component. The person should see "warm like a notebook," not read the words.
2. Designing a component. Render the actual component (or a tight before/after, both variants side by side) so the craft decisions — spacing, borders, hierarchy, states — are visible, not asserted. Render the real states (default, hover, empty, error) where they matter.
3. Critiquing or auditing. Render the current version and the improved version together so the gap is shown, not narrated.

Rules when rendering:

• The widget shows the visual only. All reasoning, the domain exploration, the rejected-defaults list, and the recommendation stay in your response text — never paste prose into the widget.
• Match the rendering tool's own design-system contract (load its read_me/guidance if it has one). Use its theme variables so the specimen inherits light/dark mode and sits native in the host. Don't fight the host chrome.
• The specimen must still pass the checks below. A rendered default is still a default — rendering is how craft gets seen, not a substitute for it.
• This renders to the conversation, not the project. The actual implementation still lands in the codebase through normal edits.

The point: collapse the loop between "here's my thinking" and "here's what it looks like" into a single message the person can react to.

---

Visual Hierarchy & Composition

The single biggest driver of "this looks designed" versus "this looks generated." Defaults produce flatness — everything the same size, weight, and spacing, so nothing leads and the eye has nowhere to go. Craft produces hierarchy — the eye knows instantly what matters. These are concrete moves, not vibes.

One focal point per view

Every screen has one thing the user came to do. That thing dominates — through size, contrast, position, or the space around it. When everything competes equally, nothing wins and the interface reads like a parking lot. Before building, name the focal element out loud. Then make it win: bigger, higher-contrast, or ringed in whitespace. Demote everything else deliberately.

Type scale is a ratio, and weight beats size

Don't pick sizes by feel. Pick a ratio and step it: ~1.2 (minor third) for dense/calm UI, ~1.25 for most product UI, ~1.333 for expressive. From a 14–16px body that yields a visibly distinct scale, not 15/16/17 mush. A 14px base at 1.25: caption 11 · body 14 · h4 16 · h3 18 · h2 22 · h1 28 · display 44+. Round to whole pixels and to your spacing grid.

The Apple/Linear move: weight and color do more hierarchy work than size. A single 14px size holds three tiers through weight + opacity alone — value: 600 / primary, label: 500 / secondary, meta: 400 / muted — separating more cleanly than two regular weights two points apart. Build from three levers together (size, weight, color/opacity), never size alone. If you squint and can't tell headline from body from label, the hierarchy is too weak.

Worked example — a metric, flat vs decided. Flat: Revenue / $48,200 both 14px regular gray, three identical boxes, no focal point. Decided: REVENUE 11px/500/muted/tracked · $48,200 28px/600/primary/tabular-nums (the hero) · ↑12% 12px/500/success. Same data, opposite legibility — the figure leads through size+weight+one accent, the label is demoted, secondary metrics drop to a lower tier.

Density is a decision, expressed in px

Linear is tight; Stripe is airy. Neither is default — both are chosen, and the choice is the same number repeated everywhere. Decide the density up front and name the values: a tool panel at 12–16px padding feels workbench-tight; the same card at 24px feels like a brochure. The same number can be right in one context and lazy in another. Pick deliberately, then hold it.

Spatial rhythm — breathe unevenly

Great interfaces don't space everything equally. Dense cont

---

Content truncated.