| name | interface-design |
| description | This skill is for interface design — dashboards, admin panels, apps, tools, and interactive products. NOT for marketing design (landing pages, marketing sites, campaigns). |
Interface Design
Operating contract for crafted product interfaces: dashboards, admin panels, SaaS apps, tools, settings pages, data interfaces, and interactive products. This skill is not for marketing pages or campaigns; route those to /frontend-design.
Invocation Triggers
Use this skill when the user asks to design, build, critique, improve, or systematize:
- Dashboards, admin panels, SaaS apps, internal tools, settings pages, data-heavy screens, and product workflows.
- Navigation, data surfaces, forms, tables, cards, panels, filters, charts, controls, and reusable interface systems.
- Interface craft: visual hierarchy, product-domain expression, typography, spacing, depth, surfaces, tokens, states, and consistency.
.interface-design/system.md creation, use, audit, extraction, or update.
When Not to Use
- Landing pages, marketing sites, campaigns, ads, or brand-only work with no product interface.
- Pure backend, API, data, DevOps, or CLI tasks with no screen or interaction surface.
- Generic frontend implementation when the user only wants mechanical code changes and no interface design judgment.
- Tasks better handled by a more specific skill, unless interface craft is central.
Required Input Contract
Collect or infer:
- Human context: who uses the interface, when, and what they must accomplish.
- Product domain: concepts, vocabulary, materials, data, and operational realities.
- Interface scope: screens, flows, components, states, data density, and constraints.
- Existing design system,
.interface-design/system.md, screenshots, code, or component library.
- Desired feel and product-specific direction, avoiding generic labels like "clean" without specifics.
- Stack and implementation constraints when code will be changed.
- Accessibility and usability requirements.
If intent, user, or task context is too vague to make non-generic choices, ask a focused question or propose a direction with explicit assumptions.
Core Interface Design Workflow
- Inspect existing interface code, screenshots, or
.interface-design/system.md when present.
- Define intent: who the human is, what they must do, and how the product should feel.
- Explore the product domain before choosing visuals.
- Produce the four direction inputs: domain concepts, color world, signature element, and defaults to reject.
- Propose a direction that ties structure and expression back to those inputs.
- Build or critique using a consistent token, spacing, typography, depth, surface, state, and navigation system.
- Validate craft and usability before showing: swap test, squint test, signature test, token test, responsive check, and state check.
- Offer to save durable interface patterns to
.interface-design/system.md when useful.
See design-workflow.md for the full workflow, communication rules, system file behavior, and save criteria.
Interface Quality Constraints
- Every visible choice must have a product-specific reason. "Common", "clean", or "modern" is not enough.
- Typography, navigation, data presentation, token names, colors, and spacing are design decisions, not neutral containers.
- Intent must be systemic: surfaces, text, borders, accents, motion, semantic colors, and component structure should reinforce the same direction.
- Avoid generic dashboard defaults unless the domain, user, and task justify them.
- Use one coherent depth strategy: borders-only, subtle shadows, layered shadows, or surface-color shifts.
- Use systematic tokens and spacing; avoid random hex values, random spacing, and mixed depth strategies.
- Design every state: default, hover, active, focus, disabled, loading, empty, and error.
- Navigation must ground the screen: where am I, where can I go, and what matters most.
See layout-and-components.md for component, token, layout, state, and navigation guidance.
Accessibility and Usability Constraints
- Keep text readable and hierarchy clear at a glance.
- Preserve keyboard focus visibility and logical interaction order.
- Do not rely on color alone to convey meaning.
- Keep controls usable in all relevant states.
- Ensure responsive layouts do not hide content, overlap controls, or create mobile horizontal scroll.
- Use data presentation that clarifies meaning and action, not decorative metrics.
- Respect existing accessibility, validation, and public-safety requirements in the repository.
See accessibility-and-validation.md for validation checks and delivery criteria.
Validation Rules
Before presenting work:
- Run the swap test: replacing typeface, layout, palette, or component treatment with common defaults should change the product feel.
- Run the squint test: hierarchy should remain visible without harsh lines or jarring color jumps.
- Run the signature test: identify concrete components where the product-specific signature appears.
- Run the token test: token names and values should sound like they belong to this product's world.
- Check state coverage, responsive behavior, spacing consistency, and
.interface-design/system.md consistency where applicable.
- If validation fails, iterate before showing the user.
See critique-and-troubleshooting.md for critique protocol and failure modes.
Output Expectations
When proposing direction, include:
Domain: [5+ product-world concepts]
Color world: [5+ domain-grounded colors/materials/light sources]
Signature: [one element unique to this product]
Rejecting: [default] -> [replacement], [default] -> [replacement], [default] -> [replacement]
Direction: [approach tied to the above]
When completing implementation or critique, report:
- Design intent and rationale.
- Files or components changed.
- Validation performed.
- Accessibility/usability risks.
- Whether durable patterns should be saved to
.interface-design/system.md.
Minimal Examples
Design a dense operations dashboard for an incident commander.
Improve this settings page so hierarchy, states, and spacing feel intentional.
Audit this admin table against the current .interface-design/system.md.
Extract reusable interface patterns from these components.
Reference Map
- Full workflow, product-domain exploration, communication,
system.md, and saving rules: design-workflow.md
- Layout, component, token, surface, state, navigation, typography, icon, animation, and chart guidance: layout-and-components.md
- Accessibility, usability, responsive validation, and pre-delivery checks: accessibility-and-validation.md
- Critique protocol, troubleshooting, generic-output failure modes, and repair patterns: critique-and-troubleshooting.md
- Worked public-safe examples and final report patterns: examples.md
Existing Deep Dives
Commands
/interface-design:status - current system state./interface-design:audit - check code against system./interface-design:extract - extract patterns from code.
