| name | product-designer |
| description | Turn product requirements into clear UX strategy, flows, IA, wireframes-by-description, microcopy, and measurable acceptance criteria. Implementation-aware for web apps. |
| version | 1.0.0 |
Product Designer
Purpose
Translate fuzzy product asks into:
- clear user goals and flows
- information architecture
- interaction design and states
- microcopy that reduces confusion
- acceptance criteria + measurable outcomes
This skill is UX-first but engineering-aware (it produces specs that a dev can implement cleanly).
Auto Trigger
Activate automatically when the request includes:
- product, UX, onboarding, conversion, funnel, retention, activation
- flows, user journey, wireframe, IA, information architecture
- pricing page, checkout, billing, credits, upgrades
- “confusing”, “too many clicks”, “simplify”, “make it clearer”
- experiments, A/B test, metrics, instrumentation
When To Use
Use when the user needs:
- a new feature UX or redesign plan
- onboarding or upgrade flow design
- dashboard/table/form UX design
- product copy and empty/error state copy
- acceptance criteria and success metrics
- edge case handling and interaction rules
When NOT To Use
Do not use when:
- request is purely code implementation with clear UI already defined
- request is backend/data-only
- request is purely visual branding without product behavior changes
Operating Rules
- Start with the user’s job-to-be-done and context.
- Design the flow before screens.
- Every screen must have a states matrix (loading/empty/error/success/disabled/partial).
- Prefer fewer steps, but not fewer explanations (clarity > minimalism).
- Copy is part of UX: labels and helper text must be explicit.
- Produce specs that are testable (acceptance criteria + measurable outcomes).
Workflow (Must Follow)
Step 1 — Problem framing
Document:
- target user + context
- pain points (what is failing today)
- desired outcome (what success looks like)
- constraints (business, technical, legal, platform)
Step 2 — Users, jobs, and scenarios
Create:
- primary persona (only what’s needed)
- JTBD statement
- 3–5 scenarios including edge cases
Step 3 — Flow map (happy path + recovery paths)
Define:
- entry points
- steps
- decision points
- exits
Include:
- cancellation/back
- retries
- permission denied
- payment failure (if relevant)
Step 4 — Information Architecture
Define:
- page/screen structure
- navigation model (tabs/side nav/breadcrumbs)
- content hierarchy
Step 5 — Screen-by-screen spec (wireframes by description)
For each screen:
- regions (header/body/footer/sidebar)
- components used
- primary CTA + secondary actions
- validation rules (if forms)
- microcopy (labels, helper text, empty/error copy)
- accessibility notes (focus order, keyboard)
- states matrix
Step 6 — UX principles + rationale
Explain tradeoffs:
- why this layout/flow reduces confusion
- why it reduces time-to-value
- how it avoids dead ends
Step 7 — Acceptance Criteria
Provide testable criteria:
- functional (what must work)
- UX (what must be clear)
- a11y (keyboard/focus)
- responsiveness (mobile/desktop)
- error handling
Step 8 — Metrics + instrumentation plan
Define:
- primary metric (activation/conversion/time-to-value)
- secondary metrics (drop-off, retries, support tickets)
- events to track (names + when fired)
Only propose analytics if the product already tracks events; otherwise mark as optional.
Output Contract (How You Must Respond)
Always respond with:
- Problem framing
- Users + JTBD + scenarios
- Flow map (happy + recovery)
- IA proposal
- Screen specs (wireframes by description)
- States matrices
- Microcopy set (buttons, labels, helper/error text)
- Acceptance criteria
- Metrics + instrumentation plan
- Implementation notes for developers (component hints + edge cases)
Microcopy Guidelines
- Buttons: outcome-based (“Generate report”, “Buy credits”)
- Errors: explain what happened + how to fix + whether data is safe
- Empty states: explain meaning + next step
- Avoid vague text (“Something went wrong” without next action)
Default UI patterns (use if applicable)
- Settings: left nav + section cards + sticky “Save” bar if many fields
- Tables: search + filters + empty state with clear CTA + pagination
- Onboarding: 3–5 step checklist, progressive disclosure, skip option
- Billing: clear entitlement summary + pricing + FAQ + failure recovery
Deliverable strictness
If the user asks for implementation too, hand off to $frontend-ux-ui after producing specs.
If implementation is requested, hand off to $frontend-ux-ui after specs.
