interface-design

# Interface Design

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. "Kitchen feel" that looks like every other app.

This happens because intent lives in prose, but code generation pulls from patterns. The gap between them is where defaults win.

The process below helps. But 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. These shape how the product feels before anyone reads a word. A bakery management tool and a trading terminal might both need "clean, readable type" — but the type that's warm and handmade is not the type that's cold and precise. 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. A page floating in space is a component demo, not software. 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? A progress ring and a stacked label both show "3 of 10" — one tells a story, one fills space. 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.

**Spatial composition feels like consequence.** You write the components top-to-bottom in the file, the JSX comes out top-to-bottom on screen. But spatial composition isn't what falls out of writing JSX — it IS the design. Where things live on the viewport, what sits next to what, what's above the fold, which information compresses into a horizontal strip vs which gets its own row — these are the load-bearing decisions, made BEFORE you write a single component. Single-column scroll is the failure mode of not having decided. Reaching for "stack the cards" is reaching for a default.

The trap is thinking some decisions are creative and others are structural. There are no structural decisions. Everything is design. The moment you stop asking "why this?" is the moment defaults take over.

---

# Spatial Composition

This is the section that gets skipped because it feels like infrastructure. It isn't.

Before any visual treatment — before tokens, before color, before typography — answer these about the viewport:

**How many distinct information regions does this screen have?**
Three. Five. Eight. Name them by content (not by visual): "open work counts split by relation", "trend over time", "the queue of items that need my attention right now". A region is a coherent answer to one user question. If you can't say what question a region answers, it isn't a region — it's filler.

**Which regions belong side-by-side?**
Related questions sit together. If "current state" and "where it's heading" are both top-of-mind, put them in one row, not stacked. If "summary metrics" and "the actionable queue" answer different questions, give them spatial separation. Side-by-side is a statement that two things are peers. Stacking is a statement that the lower one is a continuation of the upper one. Pick on purpose.

**What lives above the fold?**
At a 1280×800 viewport, what does the user see before scrolling? It should answer "what state is this in right now" in one glance. If the answer requires scrolling past three full-width hero cards to reach the actionable data, the layout is wrong. The fold is a hierarchy declaration whether you decide it or not.

**Where does horizontal compression help?**
3–6 items of similar shape — KPI counts, status pills, filter chips — belong in a horizontal strip in ONE row. One number per row is wasted vertical space when the items are comparable; it tells the user "these are separate concerns" when they're actually facets of the same thing. Reach for `grid-cols-3` / `grid-cols-4` / `grid-cols-6` whenever the items are conceptually parallel.

**Where does vertical separation matter?**
Distinct concepts get their own band. The metrics strip is one thing. The actionable queue is another. The settings panel is a third. Each gets its own vertical region with explicit space between. Don't compress sections that aren't peers just to save scrolling.

**Where does the user's eye land first?**
Pick a landing point. Page title, primary metric, primary action. Make it visually heavier than its neighbors. From the landing point, the eye should naturally flow toward the one action the user is most likely to want — not bounce between equally-weighted regions wondering where to start.

These five questions cover dashboards, admin panels, settings, list views, detail views. If your answer to any of them is "I didn't decide", the default fired. Single-column top-to-bottom is the shape that emerges when none of these quest