designing-interfaceslisted

# Designing Interfaces Defines how the software should look and feel before any UI code is written. The orchestrator runs this directly (not delegated) — the work is dialogic, exploring the product's world with the user. **Position:** architecting-software (ARCHITECTURE.md) → designing-interfaces (system.md) → decomposing-work (ROADMAP.md). **Inputs:** confirmed PRD.md and ARCHITECTURE.md, and the user available for dialogue — design direction requires conversation, not assumption. Brownfield also needs the path to existing UI code. **Output:** `.interface-design/system.md` — the persistent design record. Once created, all UI work references it; updates happen through this skill, not ad hoc edits. **Not covered:** UI implementation (developer-agent's job), design compliance review during builds (the design-compliance review perspective), marketing design or landing pages, architecture and technology selection (architecting-software). --- ## The Problem You will generate generic output. Your training has seen thousands of dashboards; you can follow the entire process below — explore the domain, name a signature, state your intent — and still produce a template. Warm colours on cold structures. "Kitchen feel" that looks like every other app. Intent lives in prose, but code generation pulls from patterns, and the gap between them is where defaults win. The process helps; it does not guarantee craft. You have to catch yourself. Defaults disguise themselves as infrastruct