Design System Interview

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: 
My recommendation: 
Why it fits: 
Choose:  /  / 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.

1. Propose a fork. Give two brief-compatible outcomes that would look or behave

materially differently. Recommend one and name its trade-off.

1. Turn language into consequences. Translate “clean,” “premium,” or “bold” into

hierarchy, density, material, type, color, or rhythm. Do not debate adjectives.

1. Record the decision. Mark it committed, assumption awaiting confirmation, or

blocked by contradiction, with the evidence that earned it.

1. 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: " — , , , , signature = ."

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](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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: KyaniteLabs
• Source: KyaniteLabs/tastecheck
• License: MIT
• Homepage: https://kyanitelabs.github.io/tastecheck/

Install and usage instructions live in the source repository linked above.