design-system-interview

name	design-system-interview
description	Design-system interview before new frontend builds or redesigns. Use for vague site/app/landing/dashboard requests, generic-looking UI, direction-setting, aesthetic choices, type/color/density decisions, and DESIGN-SYSTEM.md tokens.

Design System Interview

Turn a vague frontend brief into decisions a builder can use. The interview should feel like a sharp creative director at the table: it studies the evidence, recommends a point of view, and asks only questions that materially change the build.

Start with a direction, not a questionnaire

Inspect the product job, audience, content, existing marks, constraints, locales, and any visual references before asking a question. Then open with:

What I see: <the strongest signal in the brief>
My recommendation: <a specific direction>
Why it fits: <the product consequence>
Choose: <fork A and trade-off> / <fork B and trade-off> / redirect me

Ask one high-consequence fork at a time. Combine questions only when one answer genuinely settles several decisions. After each answer, reflect the decision back in one line so the user can correct it without rereading the conversation.

The interview loop

1. Read the room. Separate current evidence from historical residue. If an existing direction already covers five dimensions, confirm it and ask only for the gaps.
2. Propose a fork. Give two brief-compatible outcomes that would look or behave materially differently. Recommend one and name its trade-off.
3. Turn language into consequences. Translate “clean,” “premium,” or “bold” into hierarchy, density, material, type, color, or rhythm. Do not debate adjectives.
4. Record the decision. Mark it committed, assumption awaiting confirmation, or blocked by contradiction, with the evidence that earned it.
5. Stop when the system is buildable. All nine dimensions are decided, explicitly delegated to the recommendation, or blocked. Then write the artifact and handoff.

Use 4–10 exchanges for a full interview. For urgent internal work, offer the recommended direction as a short approval pass. In a one-shot or interrupted run, save the decision snapshot and name the first question needed to resume; do not present assumptions as approval.

Decisions to close

Use these adaptively; references/interview-contract.generated.md is the canonical session/dimension authority. Examples teach format, never taste.

Canonical ID	Close with
reference	a real artifact and what it earns
personality	a chosen pole, not a middle
aesthetic	one concrete phrase predicting hierarchy/material
type	binding evidence, display/body stance, language/measure risk
color_mode	dominant hue, accent job, and light/dark commitment
density_shape	density, numeric radius range, elevation
structure_rhythm	composition, motif, and sectional cadence
signature	one memorable move
imagery_iconography	source/treatment or absence; one icon system

Optionally set motion level for products.

What the user receives

Write DESIGN-SYSTEM.md from assets/DESIGN-SYSTEM.template.md, then give the user a short handoff they can approve or build from immediately:

1. Direction: one sentence that predicts the interface.
2. Decisions: the completed decision map.
3. Refusals: three to five defaults this product will not use.
4. Build contract: semantic tokens, structural rhythm, and responsive/accessibility constraints.
5. Next move: the first implementation step, or the exact blocker and owner.

Read references/session-protocol.md for readiness and resume rules.

| Dimension / conflict | Evidence | Decision or assumption | Consequence | Confirmation / owner |
| --- | --- | --- | --- | --- |
| Alert hierarchy | ... | committed / assumed / blocked | ... | ... |

Use approved only when the direction is confirmed and buildable. Use approval-ready when recommendations and tokens are complete but await confirmation; do not hand that state to implementation. Use blocked when a contradiction or missing authority prevents a safe recommendation. Each non-obvious choice cites its source; each token has a real build job.

The committed direction in one line: "<source-derived aesthetic phrase> — <chosen
hierarchy>, <color role>, <type stance>, <shape/density>, signature = <specific move>."

Hand off hue to color-system, type to web-typography, modes to theming, tokens to implementation skills, and the completed spec to deslop-ui for audit. Preserve a single DESIGN-SYSTEM.md as the source of truth.

Reference files

• references/interview-bank.md — forks and abstention guidance; read while interviewing.
• references/structure-and-rhythm.md — composition and rhythm; read before committing structure.
• references/tokens.md — token architecture; read when writing the artifact.
• references/decision-records.md — novel cases.
• references/session-protocol.md — shortcut, headless, contradiction, and resume states.
• references/interview-contract.generated.md — generated session and dimension authority.

Ready-to-build check

Report these rows with direct evidence, reason, remediation, and pass/fail/n/a.

Check	Status	Evidence / provenance	Reason	Remediation
Nine required dimensions decided
Existing-direction shortcut or full interview justified
Contradictions and trust-critical rationale resolved
DESIGN-SYSTEM.md and canonical token block complete
Downstream handoff is explicit

The interview is build-ready only when every row passes and the artifact is approved. An approval-ready or blocked output is a resumable checkpoint: name the unresolved owner and next confirmation, but do not start implementation. Deliver the one-line direction first, link the artifact, then state the next allowed action.

Contract (generated)

Canonical detail: contract.json.

• Route: A new interface or redesign lacks a committed visual direction (+1 in contract.json); avoid: An existing site has sufficient evidence to improve without a new direction interview (+1 in contract.json)
• Exclude: Do not begin implementation before direction is resolved or explicitly assumed (+1 in contract.json)
• Stop / handoff: Pause when contradictory or trust-critical direction is unresolved (+1 in contract.json); receives [none] -> sends [art-direction, color-system, component-states, data-viz, deslop-ui, empty-states, form-ux, humanize-copy, micro-motion, responsive-layout, spacing-system, tasteroll, theming, web-typography]
• Output: A decision-complete design-system artifact with explicit assumptions and readiness state
• Evidence: table_with_evidence with status, reason, remediation, evidence, provenance.