Interface Design for Dashboards and Apps

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 questions were asked.

Common shapes that emerge from honest answers:

• Sidebar (240–320px) + main content — when secondary navigation or context is a peer concept that should stay visible while the main work happens.
• Top hero strip + horizontal KPI row + actionable queue below — when "what state am I in" must answer in one glance, with the deeper work directly underneath.
• Two-column main area + right sidebar — when the work has a primary focus + a "what should I do next" supporting context.
• Tabs across the top + dense table dominating the body — when one entity has multiple views and only one view should be visible at a time.

None of these is right by default. Pick the one that answers THIS app's questions.

Intent First

Before touching code, answer these. Not in your head — out loud, to yourself or the user.

Who is this human? Not "users." The actual person. Where are they when they open this? What's on their mind? 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. Their world shapes the interface.

What must they accomplish? Not "use the dashboard." 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? 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? Calm like a reading app? The answer shapes color, type, spacing, density — everything.

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.

• Why this layout and not another?
• Why this color temperature?
• Why this typeface?
• Why this spacing scale?
• Why this information hierarchy?

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.

This is not about being different for its own sake. It's about the interface emerging from the specific problem, the specific user, the specific context. 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. Intent is not a label — it's a constraint that shapes every decision.

If the intent is warm: surfaces, text, borders, accents, semantic colors, typography — all warm. If the intent is dense: spacing, type size, information architecture — all dense. If the intent is calm: motion, contrast, color saturation — all calm.

Check your output against your stated intent. Does every token reinforce it? Or did you state an intent and then default anyway?

Product Domain Exploration

This is where defaults get caught — or don't.

Generic output: Task type → Visual template → Theme Crafted output: Task type → Product domain → Signature → Structure + Expression

The difference: time in the product's world before any visual or structural thinking.

Required Outputs

Do not propose any direction until you produce all four:

Domain: Concepts, metaphors, vocabulary from this product's world. Not features — territory. Minimum 5.

Color world: What colors exist naturally in this product's domain? Not "warm" or "cool" — go to the actual world. If this product were a physical space, what would you see? What colors belong there that don't belong elsewhere? 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.

Proposal Requirements

Your direction must explicitly reference:

• Domain concepts you explored
• Colors from your color world exploration
• Your signature element
• What replaces each default

The test: Read your proposal. Remove the product name. Could someone identify what this is for? If not, it's generic. Explore deeper.

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.

Your first output is probably generic. That's normal. The work is catching it before the user has to.

The Checks

Run these against your output before presenting:

• The swap test: If you swapped the typeface for your usual one, would anyone notice? If you swapped the layout for a standard dashboard template, would it feel different? The places where swapping wouldn't matter are the places you defaulted.

• The squint test: Blur your eyes. Can you still perceive hierarchy? Is anything jumping out harshly? Craft whispers.

• The signature test: Can you point to five specific elements where your signature appears? Not "the overall feel" — actual components. A signature you can't locate doesn't exist.

• The token test: Read your CSS variables out loud. Do they sound like they belong to this product's world, or could they belong to any project?

If any check fails, iterate before showing.

Craft Foundations

Subtle Layering

This is the backbone of craft. Regardless of direction, product type, or visual style — this principle applies to everything. You should barely notice the system working. When you look at Vercel's dashboard, you don't think "nice borders." You just understand the structure. The craft is invisible — that's how you know it's working.

Surface Elevation

Surfaces stack. A dropdown sits above a card which sits above the page. Build a numbered system — base, then increasing elevation levels. In dark mode, higher elevation = slightly lighter. In light mode, higher elevation = slightly lighter or uses shadow.

Each jump should be only a few percentage points of lightness. You can barely see the difference in isolation. But when surfaces stack, the hierarchy emerges. Whisper-quiet shifts that you feel rather than see.

Key decisions:

• Sidebars: Same background as canvas, not different. Different colors fragment the visual space into "sidebar world" and "content world." A subtle border is enough separation.
• Dropdowns: One level above their parent surface. If both share the same level, the dropdown blends into the card and layering is lost.
• Inputs: Slightly darker than their surroundings, not lighter. Inputs are "inset" — they receive content. A darker background signals "type here" without heavy borders.