design-system-interviewlisted

# 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: ```markdown 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 awa