/design-webapp

name: design-webapp
description: "Use when building or extending a dashboard, SaaS screen, or any authenticated app surface — use design-web instead for a marketing site."
when-to-use: "Building or extending a dashboard, SaaS product screen, or any authenticated app surface (not a marketing site — see design-web for that)."
keywords: webapp, dashboard, density, states, data-table, dataviz, auth, settings, onboarding, corpus, je-reproduis
priority: critical
related: design-method, design-system, design-web, design-motion, design-review

<objective> Builds logged-in web apps under register `product` — dashboards, auth flows, settings, onboarding, data tables, command palettes, modals, toasts. Optimizes for density and glance-speed over marketing polish: no hero, no scroll-reveal, no CTA-tricks.

Requires every data surface to explicitly cover empty, loading, and error states (never a silent blank default), and applies preattentive-processing rules to tables and dataviz (right-aligned numbers, sticky headers, bar/line over pie, consistent category-to-color mapping).

Reuses `design-web`'s general component guides (buttons, cards, grids, icons) rather than duplicating them — this skill only adds what's specific to apps.

Sources craft from the local corpus's two application interfaces (`reve`, `linear`) — no sector browsing — and declares the three reproduced elements (`Je reproduis`) that `design-review` verdicts. </objective>

Design Webapp — Dashboards, Density, States

When

After `design-system` tokens exist and `design-method`'s Gate 0 has locked register `product` (dense, predictable, motion stays discreet). Read `design-method`'s routing table first — if the surface is a marketing/landing page instead, use `design-web`.

Input

• `design-system.md` — OKLCH palette, typography, spacing density, the 3 dials.
• `design-method/references/register/product.md` — the Domain-Specificity Floor and the

Product Furniture table (generic KPI ribbon, marketing triad reused in-app, cookie-cutter empty state, undifferentiated settings list, generic nav vocabulary).

• The corpus's two application interfaces, both under

`../design-web/references/refs-design/` — `reve-recode/` (`tokens-reve.md` §3 surface hierarchy, §4 application UI patterns) and `linear-recode/` (`tokens-linear.md` §6 masking/light, §7 button architecture), plus each folder's `design-system.md`. Loaded once per task (step 11).

• The specific page/pattern being built (dashboard, auth, settings, data table, etc.).

Steps

1. **Register `product` ≠ marketing register.** No hero, no scroll-reveal, no CTA-tricks — this register optimizes for glance-speed, not first impression. Density is a feature: Enterprise Dense / Standard spacing profile (`design-system/references/spacing-density.md`), `MOTION_INTENSITY ≤ 4` by default (`design-motion/references/motion-performance.md`). The Focal-Block Floor and Signature Dominance from `design-web` do not apply here (`register/product.md` §4) — several equal-weight blocks in one viewport is correct, not a defect.

2. **Pick the page pattern** from `references/layouts/pages/` — dashboard, auth-login, auth-register, onboarding, profile, settings, error-pages. Each is a starting structure, not a template to copy verbatim — adapt density from `design-system.md`, and run the Domain-Specificity Floor test on it: would this page's copy/icons/grouping look native dropped unedited into an unrelated product in the same category? If yes, it's furniture — name the product's real entities instead (`register/product.md` §2-3).

**This is where app structure comes from — not from the page-structure banks.** Page structure in this plugin now comes from a *matched pair* of files, and both are marketing instruments: a hero treatment from `../design-method/references/macrostructure-bank.md` (eight treatments of the first screen) **and** a body sequence from `../design-method/references/body-sequence-bank.md` (fifteen sequences read off shipped code). Naming one without the other is an incomplete plan — *there*.

Neither applies to an app surface, and this is a real difference, not a shortcut: an app has no first screen to compose and no scroll narrative to order. It has a persistent shell, a task, and the data that task needs; the reader arrives mid-session with an intent, not at a pitch. So the banks are **not** consulted here, and a webapp plan that names a hero treatment or a body sequence has mis-routed. There is exactly one case where both picks are still required — a marketing-adjacent page inside the app shell — and that page routes to `design-web` anyway (step 11).

What *does* transpose from the banks is their underlying rule, which holds in every register: a structure is chosen for the principle it serves on this subject, never adopted because it is the common shape. The `product` equivalent of "don't reach the canon by omission" is the Domain-Specificity Floor above — reaching a settings page's shape by omission is the same defect wearing different clothes.

3. **Pick the interaction pattern(s)** from `references/layouts/patterns/` — data-table, command-palette, modal-dialog, toast-notifications, empty-state. Apps lean on these far more than marketing sites do.

4. **Cover every state explicitly — empty, loading, error, populated.** Never a blank or silent default:

• **Loading** — skeleton rows/cards, never spinner-only (`layouts/patterns/data-table.md`

— NNG: skeletons perceived 9-12% faster than spinners).

• **Empty** — name the actual object type and the actual first action ("No invoices yet

— create one from a quote" beats "No data yet", `register/product.md` §3 Cookie-cutter empty state).

• **Error** — actionable message + retry affordance, never a raw stack trace or generic

"Something went wrong."

• For data tables specifically, this extends