Web Taste

Web Taste

Taste doesn't start at the pixel level. It starts at "who is this person and what do they need?" The visual refinement is the LAST step. The first step is understanding the user's world deeply enough that the interface design feels inevitable — like it couldn't have been designed any other way.

Your default mode skips straight to layout. It produces technically correct React that looks generic because it was never grounded in a real person's needs — a stack of cards, a sidebar, a settings list. This skill changes the order of operations: think like a designer first, then write code.

Phase 0: The 0.5-Second Test (ORIENT before everything)

Before designing anything, answer ONE question:

**What does the user SEE in the first half-second — before they

read a single word?**

This is not about content. It's about the SHAPE of the screen. Close your eyes and picture it. What dominates?

• A single hero number with a sparkline? → Analytics / metric dashboard
• A gradient card with bold white text? → Status / billing / hero page
• A table with sticky chrome and a search bar? → Data console / admin
• A grid of media cards? → Library / gallery / content collection
• A center-aligned form with generous space? → Sign-up / auth / single-action
• A two-pane list + detail? → Email / inbox / CRM
• A timeline of events? → Activity feed / audit log

If your answer is "a sidebar and some cards in a content area" → STOP. That's a CMS theme, not a product. Go back and find the visual shape that matches what this user actually needs.

Write the 0.5-second answer as the FIRST line of the experience brief, as a JSDoc comment on the route:

// 0.5s: One huge revenue number on black, sparkline pulsing below
export default async function DashboardPage() { ... }

This single sentence anchors every decision that follows. If the code you write doesn't produce that shape, something went wrong.

Phase 1: Design Thinking (Before You Touch React)

Before writing a single line of JSX, answer these questions. Write the answers down as comments or in your thinking. If you skip this phase, your output will look like every other AI-generated UI — correct but soulless.

1. Who is the user?

Not "a SaaS admin." A real person with a context:

• What moment are they in when they open this page? (Triaging the

morning's alerts? Sharing a link in a meeting? Reviewing the quarter before a board call?)

• What did they just do before arriving here? (Clicked a notification

email? Searched? Followed a deep link from Slack?)

• What do they want to accomplish in under 10 seconds?

This shapes EVERYTHING. A user pasted into the page via a Slack deep-link needs a giant headline that reorients them. A user with the page open all day wants quiet chrome and big working space. A user evaluating during a demo wants the value proposition to be visible without scrolling.

2. What should they FEEL?

This is the question that separates designed products from CRUD admin panels. Linear doesn't show you a kanban — it makes shipping feel like an obsession. Stripe doesn't show you payment forms — it makes commerce feel like a solved problem. Every design choice serves that emotional goal.

Before choosing components, decide the emotional intent:

• Focused / Productive → muted palette, monochrome chrome, single

accent color, generous space, Inter or system-ui sans

• Confident / Trustworthy → deeper blues/greens, clear data

presentation, generous whitespace, classical proportions

• Delighted / Premium → unexpected microinteractions, rich

gradients, subtle 3D, considered typography (Söhne, Inter Display)

• Energetic / Bold → high saturation, large display type,

asymmetric layouts, strong photography

• Calm / Editorial → serif typography, narrow text columns, lots

of breathing room, restrained color

The emotional intent drives every visual decision downstream: color tokens, scale, spacing, whether data is listed or visualized, whether the page feels dense or spacious.

3. What are their goals and pain points?

For each page, identify:

• Primary goal — the ONE thing most users come here to do
• Secondary goals — things some users occasionally need
• Pain points — what frustrates users in this domain?

A billing page: the primary goal isn't "see all billing info." It's "change the payment method that just expired" or "download last month's invoice for expense reports." The pain point is wading through plan summaries and feature comparisons to find the one action that needs doing.

4. What features serve those goals?

Map goals to features. Not "what features could this page have?" but "what's the minimum set of features that makes the primary goal effortless?" Every feature that doesn't serve a goal is clutter.

Group features by priority:

• Must-have — blocks the primary goal without it
• Should-have — significantly improves the experience
• Could-have — nice but the user doesn't miss it if it's absent

5. How do features become routes?

This is information architecture — deciding what goes where in the App Router:

• One primary action per route. If a page tries to do two

things, split it into two routes or use a sheet/dialog for the secondary task.

• Group by user intent, not by data type. A user doesn't think

"I want to see my notification settings." They think "I want Slack to stop pinging me during deep work." Group features by the problem they solve, not by their technical category.

• Navigation follows the user's mental model. /settings →

/settings/billing is obvious. /admin/organizations/{org}/members/{member}/preferences/notifications is six levels deep for something the user sets once. Use parallel routes (@modal) and intercepting routes for "open as overlay" patterns when full navigation is overkill.

6. What components serve each feature?

NOW you think about React — but through the lens of user intent:

• Server Component vs Client Component — RSC by default. Use

'use client' only when interactivity is required. Don't ship a hydration boundary for a list that doesn't need one.

• Dialog vs Popover vs Sheet vs Full page — see ux-modality.

Pick the lightest container that fits.

• Form vs separate fields — Server Actions + <form action={}>

for anything that mutates. Standalone fields with useOptimistic for live-saving settings.

• Table vs Card grid vs List — Table when scanning columns is

the job (sortable, filterable, compare values). Card grid for heterogeneous browse. List for homogeneous rows with one primary identifier per row.

• shadcn/ui vs custom — shadcn/ui Radix-based primitives are

the default. Custom components only when no primitive fits.

The component choice IS the design. A <DataTable> with sticky header for a financial dashboard feels precise and bureaucratic. A gradient card grid for the same data feels exploratory and editorial. Neither is wrong — the right choice depends on who the user is and what moment they're in.

Phase 2: Visual Design

After Phase 1, you know who the user is, what they need, how they should feel, and what components serve those needs. Now make it beautiful. The emotional intent from Phase 1 drives every choice here.

1. Hierarchy Through Scale

Not just font weight — dramatic scale contrast. The most important thing on screen should be physically large, not just bold.

• Hero numbers at display scale — a revenue figure, a count, a

percentage should dominate the page. Use text-6xl or text-7xl with font-semibold tracking-tight tabular-nums. Linear's velocity charts use 64-72 px display numbers. Don't shrink important data into a text-sm row.

• Supporting text whispers — everything that isn't the hero

element gets text-sm or text-xs in text-muted-foreground. The contrast between the hero and the support IS the hierarchy.

• Space as luxury — leave empty areas. A number floating in a

sea of background is more powerful than the same number crammed into a dense DataTable. Space communicates importance.

// Hero metric — scale dominates, whisper labels
<section className="p-8">
  <p className="text-sm text-muted-foreground">Net revenue · last 30 days</p>
  <p className="mt-2 text-7xl font-semibold tracking-tight tabular-nums">
    ${(revenue / 100).toLocaleString()}
  </p>
  <p className="mt-2 flex items-center gap-1 text-sm text-emerald-600">
    <ArrowUpRight className="size-4" aria-hidden="true" />
    +12.4% vs prior period
  </p>
</section>

2. Color Is Math, Not Vibes

NEVER pick colors by hand. Color harmony is a solved mathematical problem. This skill bundles a palette generator that computes every color from a single seed hue — analogous harmony, WCAG contrast validated, light and dark mode variants emitted as CSS custom properties and a Tailwind config snippet.

Before writing any view code, run the palette generator:

python scripts/generate_palette.py \
  --seed <hue-degrees> \
  --mode both \
  --items <collection-count> \
  --app "App Name"

Seed hue guide:

• 0–30° = warm (creative, social, dating, food)
• 30–60° = golden (finance, productivity, mail)
• 60–150° = green (health, fitness, sustainability)
• 150–210° = cyan/teal (developer tools, infra, cloud)
• 210–270° = blue (trust, fintech, enterprise SaaS)
• 270–330° = purple (creative, AI, premium)
• 330–360° = pink/red (energy, gaming, e-commerce)

Paste the generated :root and .dark CSS custom properties into app/globals.css, and use ONLY those tokens via Tailwind utilities (bg-primary, text-muted-foreground, border-border). The palette is computed — every color is mathematically related to the seed, contrast ratios are pre-validated, and light/dark variants are included.

Rules that never break:

• One seed hue per app. Everything derives from it.
• Collections use analogous variations (the --items flag),

not random hues. They sit together because they're ±30° of seed.

• Never use raw Tailwind palette classes like bg-blue-500,

text-red-600, border-gray-200 — those don't theme and aren't contrast-audited. Use semantic tokens.

• **Use bg-background, text-foreground, border-border,

text-primary** — not ad-hoc Color(...) calls or arbitrary classes scattered through component code.

3. Show Data, Don't List It

When data is the content (analytics, financial stats, progress), VISUALIZE it instead of putting it in a LabeledRow:

• Sparklines and area charts for trends over time (Recharts,

Tremor, or hand-rolled SVG)

• Gauges and rings for progress toward a goal
• Large hero numbers with delta arrows and percentage chips
• Heatmaps for activity by time-of-day or by-day-of-week
• Color-coded bars for composition (revenue by source, time split)

A <dl><dt>Revenue</dt><dd>$8,432</dd></dl> is information. A large "$8,432" in text-6xl tabular-nums with a sparkline below it is an experience. The emotional intent from Phase 1 tells you which one to use.

4. Card-Based Composition

Don't default to a single bordered container for everything. Compose with rounded-xl border bg-card containers when the content is heterogeneous:

• Cards with rounded-xl border bg-card text-card-foreground p-6
• Each card is a self-contained visual unit with its own hierarchy
• Cards can have gradient backgrounds for visual richness

(think Vercel deployment cards, Linear cycle cards)

• Use CSS grid with auto-rows-fr for equal-height card grids

Tables are for homogeneous scannable data. Cards are for dashboards, overviews, and content-rich pages where each item has its own story.

5. Content Realism

The data IS the design. Every preview tells a coherent story:

• Real names ("Elena Marsh"), plausible numbers ("$47.83", "4.3K"),

varied lengths, temporal realism ("2 hours ago", "Yesterday")

• Data relationships that make sense (Designer → Design dept)
• If your preview data looks fake ("Item 1", "Lorem ipsum",

foo@example.com), your design looks fake

Generate seed data with a coherent narrative — even in fixtures.

6. Restraint

What you leave out defines taste. No instruction headers ("Welcome to your dashboard"). No uniform icon decorations on every row. No tutorial overlays. No demo naming. For every element, ask: "what happens if I remove this?" If nothing — remove it.

7. Craft

The invisible details that feel right:

• tabular-nums on changing numbers so digits don't reflow
• tracking-tight on display headings
• transition-colors duration-150 on every interactive element
• hover: + focus-visible: + active: states on every button
• motion-safe: on transforms (see acc-reduce-motion)
• truncate + line-clamp-N instead of overflow hidden + ellipsis JS
• font-variant-numeric: tabular-nums everywhere numbers tick
• Accessibility as design, not compliance (see web-rules)

8. Character

Each page has a distinct personality. Character comes from:

• Domain-appropriate color palettes (cool blue for fintech, warm

ochre for crafts, vivid green for sustainability)

• Content-specific typography pairings (a serif headline + Inter

body feels editorial; mono in the chrome feels developer-y)

• Cover the navigation bar — can you still tell what app this is?

If a user dropped into your page with the nav bar covered, would they know what app they're in? Linear's character is in its sharp chrome and cycle visualization. Stripe's is in its perfectly-aligned data tables and trust-blue accent. Find yours.

Applying Both Phases

When asked to build a route, layout, or component:

1. Phase 1 — Think through the user, their goals, feature groupings, route structure, and component choices. Write brief notes (as code comments or in your response) showing your design reasoning. This is not optional — it's what separates a designed experience from a decorated layout.

2. Phase 2 — Write the React/Next.js/Tailwind code with all eight fundamentals applied. Start with realistic data and seed fixtures. Build minimal, add only what earns its place, then polish with craft details.

3. Self-check — Before finishing, ask: "Would a real user using this product in the moment I identified in Phase 1 feel like this page was designed for them?" If not, something in Phase 1 was wrong — go back.

No Taste vs Taste — Concrete Examples

For full before/after code (a generic AI-looking dashboard vs a Stripe-inspired revenue page) and the Component Palette Quick Reference table that maps reflex choices to taste-driven ones, read references/code-examples.md.

The short version of the contrast: a "no taste" page jumps straight to layout — instruction header, numbered placeholders, text-gray-* and bg-blue-* hardcoded, generic component naming. A "taste" page opens with a design comment naming the user and emotional intent, puts the most important number at hero scale with tabular-nums, uses semantic tokens (text-muted-foreground, bg-card), and lets a sparkline support the hero rather than compete with it.

Reference apps worth studying: Linear, Stripe, Vercel, Notion, and high-craft consumer apps (Cash App, Things, Arc). Each has a distinct character driven by deliberate choices in chrome, typography, and data presentation.

The Screen Becomes the Content

Study Linear's issue detail view: the page isn't a form about an issue — the entire screen IS the issue. The title is the page heading at hero scale. The description IS the body. Actions live in chrome that fades away. There's no "Edit issue" page; editing happens in place.

This is the highest level of taste: the UI dissolves into the content. The page doesn't frame the data — it becomes the data.

Techniques for this:

• In-place editing — contenteditable on the title and body so

the page IS the editor. Save on blur via Server Action.

• Mono in chrome, sans in content — gives developer tools a

distinct character without making the body unreadable.

• Smart typography in lists — Linear bolds the issue ID prefix

and leaves the title in regular weight. This tiny detail makes identifier-scanning dramatically faster. Find the equivalent typographic hierarchy for your domain.

• Detail views look like read mode — even in edit-able products,

the detail view doesn't show a form UI. The same content reads beautifully and edits in place.

Reference: Web Design DNA

When making specific design decisions, read references/web-design-dna.md in this skill's directory. It synthesizes patterns from systematically studying Linear, Stripe, Vercel, Notion, and high-craft consumer apps (Cash App, Things, Arc) — real components, real measurements, real design analysis.

Key sections to consult:

• Three modes of web app design — Dashboard (data-heavy, dark

chrome), Utility (CRUD-driven, light surfaces), Editorial (content- first, expressive typography)

• Universal measurements — card radius (12-16 px), header height

(56-64 px), content max-width (1024-1280 px)

• Onboarding templates — feature-list vs hero-illustration patterns
• Button hierarchy — filled primary, outline secondary, ghost

tertiary; destructive isolated by position not just color

• Detail-page-becomes-content — the Linear / Notion technique
• Empty states — show structure, not "no data" messages

The Mindset

You are not a developer who can also design. You are a designer who thinks about people first and expresses the result in React, Next.js, and Tailwind. The code is the medium. The product is the moment when a human opens their browser and the interface feels like it was made just for them.

Web Taste

This curated skill mirrors SKILL.md. When maintaining it, keep the trigger language focused on React 19 / Next.js 16 / Tailwind CSS user-facing interface work and keep supporting references in references/.

Sibling skill: skills/.experimental/web-rules/ — the strict-rules companion. web-taste answers what to build; web-rules enforces how to build it correctly.

Web Taste — Code Examples & Component Palette

Concrete before/after examples and the component-choice reference table. Pulled out of SKILL.md to keep the main skill lean.

What "No Taste" Looks Like

// NO TASTE — jumped straight to layout, no user thinking
export default function DemoPage() {
  return (
    <div className="container mx-auto p-4">
      <h1 className="text-2xl font-bold mb-4">Dashboard</h1>
      <p className="text-gray-600 mb-4">
        Welcome to your dashboard! Here you can see all your data.
      </p>
      <div className="grid grid-cols-3 gap-4">
        {[1, 2, 3, 4, 5, 6].map((i) => (
          <div key={i} className="border rounded p-4">
            <h2 className="font-semibold">Item {i}</h2>
            <p className="text-sm text-gray-500">Description</p>
            <button className="bg-blue-500 text-white px-3 py-1 rounded mt-2">
              Action
            </button>
          </div>
        ))}
      </div>
    </div>
  )
}

No user thinking. No goals. Instruction header ("Welcome to your dashboard"). Numbered placeholders. Hardcoded text-gray-* and bg-blue-*. Generic naming. No character.

What Taste Looks Like

// GOLDEN — Stripe-inspired revenue overview
// User: Maya, finance ops, opens this every morning while drinking coffee
// Emotional intent: CONFIDENT — make the number trustworthy, the trend obvious
// Hero: net revenue dominating the top, sparkline whispering below
export default async function RevenuePage() {
  const [revenue, trend, recent] = await Promise.all([
    getNetRevenue(),
    getTrend(),
    getRecentPayments(),
  ])

  return (
    <main className="mx-auto max-w-6xl px-6 py-8 space-y-8">
      <section>
        <p className="text-sm text-muted-foreground tracking-wide uppercase">
          Net revenue · last 30 days
        </p>
        <h1 className="mt-2 text-7xl font-semibold tracking-tight tabular-nums">
          ${(revenue / 100).toLocaleString()}
        </h1>
        <div className="mt-3 flex items-center gap-3">
          <span className={cn(
            'inline-flex items-center gap-1 rounded-full px-2 py-0.5 text-xs font-medium',
            trend.delta >= 0
              ? 'bg-emerald-500/10 text-emerald-700 dark:text-emerald-400'
              : 'bg-destructive/10 text-destructive'
          )}>
            {trend.delta >= 0 ? <ArrowUpRight className="size-3" /> : <ArrowDownRight className="size-3" />}
            {Math.abs(trend.delta).toFixed(1)}%
          </span>
          <span className="text-sm text-muted-foreground">vs prior 30 days</span>
        </div>
        <RevenueSparkline data={trend.points} className="mt-6 h-16 w-full" />
      </section>

      <section aria-labelledby="recent-heading">
        <h2 id="recent-heading" className="text-sm font-medium text-muted-foreground mb-3">
          Recent payments
        </h2>
        <ul className="rounded-xl border bg-card divide-y">
          {recent.map((p) => (
            <li key={p.id} className="flex items-center justify-between px-4 h-14">
              <div className="min-w-0">
                <p className="font-medium truncate">{p.customer}</p>
                <p className="text-xs text-muted-foreground">{p.email}</p>
              </div>
              <p className="font-mono tabular-nums">${(p.amount / 100).toLocaleString()}</p>
            </li>
          ))}
        </ul>
      </section>
    </main>
  )
}

Design comment explains user moment and emotional intent. Hero revenue number dominates the screen (not buried in a <dl>). Tabular-nums keeps digits from reflowing. Semantic tokens (text-muted-foreground, bg-card, border) — no raw grayscale. Sparkline supports the hero number, doesn't compete with it. You know this is a fintech product without reading the title.

Component Palette Quick Reference

When you instinctively reach for a tutorial component, STOP:

Modern stack idioms to reach for: Server Components by default, Server Actions for mutations, useOptimistic for live UI, <Suspense> for streaming, parallel routes (@modal) for overlays with their own loading states, intercepting routes for "open as modal with a real URL".

Reference apps to study: Linear (sharp chrome, cycle visualization, keyboard-first), Stripe (perfectly-aligned tables, trust-blue, generous typography), Vercel (gradient cards, mono in chrome, deployment cards), Notion (in-context editing, content-as-UI), Apple-fueled fintech UI (Cash App, Robinhood, Wealthfront).

Web Design DNA — Cross-Product Synthesis

Patterns extracted from studying Linear, Stripe, Vercel, Notion, Cash App, and Arc as of 2026. Sources: live product UI, public design system docs, component libraries (shadcn/ui, Radix, Tremor), and engineering blog deep-dives.

The Three Modes of Modern Web App Design

Mode 1: Console (Linear, Vercel, Sentry, Stripe Dashboard)

• Background: Near-black in dark mode (#0a0a0a / #131414), off-white

in light mode (#fafafa)

• Chrome: Minimal. Sidebar with subtle dividers, header with sticky

page actions, no big illustrations

• Content: Dense lists of issues / deployments / customers / events
• Data: Inline charts, sparklines, status pills, monospace identifiers
• Emotion: Focused, productive, control. The user is the operator.
• Typography: Inter / Geist / SF Pro — sans-serif workhorse. Monospace

for IDs and code (Geist Mono, JetBrains Mono).

• Navigation: Sidebar primary, keyboard-first (Cmd+K palette mandatory)
• Use when: The app's purpose is operating, monitoring, or managing

ongoing systems

Mode 2: Editorial (Notion, Stripe Marketing, Cash App, Things)

• Background: White or very light surface, generous max-width content

columns (640-720px for prose)

• Chrome: Disappears — only navigation chrome and one action button
• Content: Long-form text, headings, in-place editing, embedded media
• Data: Inline (the data IS the content)
• Emotion: Calm, considered, focused on the single thing you're making
• Typography: Often serif headlines (Tiempos, Söhne, Charter) paired

with sans-serif body. Larger sizes than typical SaaS.

• Navigation: Minimal. Sidebar that hides on focus, or top-only nav
• Use when: The app's purpose is creating, reading, or thinking

Mode 3: Spectacle (Stripe homepage, Linear marketing, Vercel deploys)

• Background: Animated or gradient — the page IS the experience
• Chrome: Almost none — full-bleed visuals, micro-interactions on

every element

• Content: One bold idea per screen; scroll reveals supporting

evidence

• Data: Decorative when present; always with motion
• Emotion: Premium, ambitious, "this product is serious"
• Typography: Very large display sizes (text-7xl, text-8xl),

optical letter-spacing, custom variable fonts

• Navigation: Top nav with scroll-aware blur/shrink
• Use when: Marketing pages, hero feature reveals, deployment

ceremonies (Vercel's "deploying" screen is theater)

Most products MIX modes: Linear is Console (the app) + Spectacle (the marketing site) + Editorial (the issue detail). Pick mode per route.

Universal Design Principles

1. The Page IS The Content

Linear's issue detail is the issue. Notion's page is the document. Stripe's invoice view is the invoice. In none of these does the UI "frame" the data — the content IS the UI surface. Look for opportunities to make the page disappear into its content.

Implementation in Next.js:

// Linear-style issue detail — no "edit" mode, the page IS the editor
'use client'
export function IssueDetail({ issue }: { issue: Issue }) {
  return (
    <article className="mx-auto max-w-3xl p-8 space-y-6">
      <input
        defaultValue={issue.title}
        className="w-full text-3xl font-semibold tracking-tight bg-transparent border-none focus:outline-none"
        onBlur={(e) => updateTitleAction(issue.id, e.target.value)}
      />
      <RichTextEditor
        defaultValue={issue.body}
        onBlur={(body) => updateBodyAction(issue.id, body)}
      />
    </article>
  )
}

2. One Accent Color, Used Sparingly

Linear uses a single brand purple (~#5e6ad2) in:

• Active sidebar item background
• Primary button fill
• Pull-quote borders
• Cycle progress

That's it. Four placements across the entire product.

Stripe uses indigo-blue (#635bff) similarly: primary CTA, link color, active state. Trust + simplicity.

Anti-pattern: rainbow palettes where every section has its own brand color. Use semantic tokens; reserve hue variation for content categorization (chart series, status pills), not for chrome.

3. Card vs Row Grammar

• Card: Used for dashboards, summaries, marketing grids. Self-

contained, rounded corners (12-16px), subtle border or shadow, generous padding (24px). Cards say "here's a snapshot — tap to dive deeper."

• Row: Used for lists where each item has the same shape (issues,

customers, deployments, files). Full-width, divider-separated, compact padding (8-12px vertical). Rows say "here's structured data — scan and act."

The transition from card -> row signals depth level. Dashboard cards link to row-based detail lists.

4. Onboarding: Three Templates

Feature List (Notion, Linear, Vercel):

[Icon — same color, same style for all rows]  Bold Title
                                              Description (1 sentence)
[Icon]  Bold Title
        Description
[Icon]  Bold Title
        Description
        [=== Get started ===]

Hero Illustration (Stripe, Cash App):

[Large custom illustration — brand character]
            Bold Headline
            Body subhead (centered)
[=== Primary CTA ===]      Secondary link

Empty Slate (Linear new workspace, Notion new page):

[Single brand symbol]
"You don't have any X yet"
"X are great for Y."
[=== Create your first X ===]

Use Feature List for "here's what this product does" (3 screens max). Use Hero Illustration for marketing pages. Use Empty Slate for in-app first-run.

5. Button Hierarchy

• Primary: Filled with accent color, white text. One per page.
• Secondary: Outline / ghost in foreground color. Up to 3 per page.
• Tertiary: Text-only link in muted-foreground; underline on hover.
• Destructive: Filled destructive color, isolated by position

(rightmost in dialogs, bottom of "Danger zone" sections), never primary on a page.

shadcn/ui Button variants line up: default, outline, ghost, link, destructive. Use them; do not introduce new variants unless you've fully redesigned the hierarchy.

6. Empty States Show Structure, Not Absence

When there's no data:

• Show the skeleton of what would be there (a dotted card outline,

a faded sample row) so the user understands the shape

• Or show the first step (Linear's "Create your first issue")
• Never show "No data" alone

Stripe's empty payments table shows a faded sample row + arrow pointing to "Test mode" + how to send a test payment. Educational emptiness.

7. Glass-on-Gradient Detail Views

For high-craft detail screens (a deploy detail, a customer profile, a release post):

Layer 0: Full-bleed gradient or accent background
Layer 1: Frosted glass cards (backdrop-blur-xl bg-white/5 dark:bg-white/5)
Layer 2: Strong text contrast on the glass

Vercel's deploy detail does this (gradient + dashboard cards on glass). Cash App's send/receive screen does this (gradient background + frosted card with the amount).

Tailwind recipe:

<div className="relative">
  <div className="absolute inset-0 bg-gradient-to-br from-violet-500/30 via-indigo-500/20 to-blue-500/30" />
  <div className="relative z-10 rounded-2xl backdrop-blur-xl bg-white/40 dark:bg-black/40 border border-white/10 p-6">
    {/* content */}
  </div>
</div>

8. Inline Data Enhancement

Instead of "View metrics →", Linear embeds a sparkline in the cycle card. Instead of "See deploys →", Vercel embeds a heatmap of deployments per day. The preview IS the data — no navigation needed for first-level insight.

Use Tremor, Recharts, or hand-rolled SVG with viewBox to fit the chart into a card. Keep them small (40-80px tall) — they're a hint, not the destination.

9. Keyboard-First Power Patterns

The hallmark of a "Console" app is keyboard mastery:

• Cmd+K palette — every action discoverable by typing. Use cmdk

(the library shadcn/ui ships) or kbar

• Jump nav — Cmd+1..9 for top-level sections
• Vim-style row navigation — j/k to move, Enter to open
• Selection state — keyboard arrows + Shift to multi-select

Linear is the gold standard. If you're building a Console app, ship Cmd+K on day one.

import { Command } from 'cmdk'

export function CommandPalette() {
  return (
    <Command.Dialog>
      <Command.Input placeholder="Type a command or search..." />
      <Command.List>
        <Command.Group heading="Actions">
          <Command.Item onSelect={() => createIssue()}>
            <Plus className="size-4" /> New issue
            <kbd className="ml-auto">⌘N</kbd>
          </Command.Item>
        </Command.Group>
        <Command.Group heading="Navigation">
          <Command.Item onSelect={() => router.push('/inbox')}>Inbox</Command.Item>
        </Command.Group>
      </Command.List>
    </Command.Dialog>
  )
}

10. Typography That Scans

Linear's issue list bolds the issue ID prefix (e.g., ENG-1432) and leaves the title in regular weight. Stripe's customer list bolds the email. Vercel's deploy list bolds the commit message. Each app identifies the MOST LIKELY scan pattern of its content and uses font weight to support it.

For your app: figure out what users scan FOR (a number, a name, a status?) and bold that — let everything else be regular weight.

11. Dark Mode Is the Default for Console, Light for Editorial

Linear, Vercel, Sentry, Datadog, GitHub: default dark. The operator mindset wants quiet chrome. Notion, Stripe Marketing, Substack: default light. The editorial mindset wants paper.

Always ship both. Let users override. Use next-themes with defaultTheme="system".

12. Optimistic UI Is Visible Polish

The difference between Linear's "instant" feel and a typical CRUD app is useOptimistic. Every interaction renders the expected result on the next paint (16ms), then reconciles. The server round- trip is hidden.

Use useOptimistic for:

• Toggling status (mark issue done, like post)
• Reordering (drag a row, drop in new position)
• Quick edits (rename inline, change priority)

'use client'
import { useOptimistic } from 'react'

export function StatusToggle({ issue }: { issue: Issue }) {
  const [optimisticStatus, setStatus] = useOptimistic(issue.status)
  return (
    <button onClick={() => {
      const next = optimisticStatus === 'done' ? 'open' : 'done'
      setStatus(next)
      startTransition(() => updateStatusAction(issue.id, next))
    }}>
      {optimisticStatus === 'done' ? <CheckCircle2 className="text-success" /> : <Circle />}
    </button>
  )
}

Measurements Reference (the de-facto standards)

Apps to Study by Pattern

The Highest Form

The highest level of taste is when the chrome dissolves into the content. Linear's issue page doesn't show an issue — it IS the issue. Notion's page doesn't contain your writing — it IS your writing. Stripe Checkout doesn't frame the transaction — the transaction renders on plain trust-blue space.

This is the goal. Frames are a cost. The product is the moment when the user forgets the UI exists and is just doing the thing.