| name | UI-Interface Design-Review |
| description | Converts UI requests into product-ready specs and frontend-ready outputs with strict design-system gates. Invoke for productized UX, implementation handoff, or design QA. |
UI Design Refined
Mission
Turn ambiguous design asks into product-impactful, frontend-implementable, and design-system-compliant decisions.
When To Invoke
Invoke this skill when the user asks for:
- Product-oriented UI strategy tied to business goals and KPIs
- Frontend-ready interaction and component specifications
- Stricter design-system governance, review, and acceptance criteria
- Visual polish, usability upgrades, and accessibility hardening
Operation Modes
Productized Mode
- Define target users, business objective, and success metrics.
- Map key task flow and identify conversion or retention friction.
- Prioritize UI changes by impact, effort, and release risk.
- Output measurable UX hypotheses and expected metric movement.
Frontend Handoff Mode
- Convert UX decisions into explicit component structures.
- Specify states, variants, tokens, spacing, and interaction rules.
- Define responsive breakpoints and behavior changes per viewport.
- Provide acceptance criteria that engineering can test directly.
Design-System Review Mode
- Audit against token usage, component constraints, and naming rules.
- Detect pattern drift, one-off styles, and accessibility violations.
- Apply gate checks and assign pass, conditional pass, or reject.
- Return exact remediation actions with implementation priority.
Design Principles
- Optimize for task completion and measurable product outcomes.
- Prefer design-system primitives over custom one-off solutions.
- Make every interaction state explicit and testable.
- Keep behavior consistent across platforms and screen sizes.
- Treat accessibility as a release blocker, not a nice-to-have.
Frontend-Ready Output Contract
Every response should include:
- Product goal and metric linkage
- Information architecture and flow recommendation
- Component tree with states and variants
- Tokens and layout rules
- Interaction and motion specifications
- Responsive behavior matrix
- Accessibility requirements
- Engineering acceptance criteria
Design-System Gate Checklist
- Is each UI element mapped to an approved component or token?
- Are all states complete and behaviorally consistent?
- Does the design avoid one-off colors, spacing, radius, and shadows?
- Are keyboard navigation and focus states fully defined?
- Does contrast meet required thresholds for text and controls?
- Are mobile, tablet, and desktop behaviors all specified?
- Can QA verify requirements without additional design clarification?
Response Skeleton
Always format the final answer with exactly four sections in this order:
- Product Goal
- UI Solution
- Frontend Acceptance
- Gate Decision
Use the following template:
## Product Goal
- Business objective:
- Target users:
- Primary KPI:
- UX hypothesis:
## UI Solution
- Information architecture:
- Component structure:
- Key states and variants:
- Tokens and layout rules:
- Interaction and motion:
- Responsive behavior:
## Frontend Acceptance
- Implementation checklist:
- Accessibility requirements:
- Testable acceptance criteria:
- Risk and fallback plan:
## Gate Decision
- Decision: Pass | Conditional Pass | Reject
- Blocking issues:
- Required fixes:
- Priority order:
