product-designer

这段内容是审核时保存的快照。外部来源才是完整且最新的版本。

---
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
1. Start with the user’s job-to-be-done and context.
2. Design the flow before screens.
3. Every screen must have a states matrix (loading/empty/error/success/disabled/partial).
4. Prefer fewer steps, but not fewer explanations (clarity > minimalism).
5. Copy is part of UX: labels and helper text must be explicit.
6. 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:

1) Problem framing  
2) Users + JTBD + scenarios  
3) Flow map (happy + recovery)  
4) IA proposal  
5) Screen specs (wireframes by description)  
6) States matrices  
7) Microcopy set (buttons, labels, helper/error text)  
8) Acceptance criteria  
9) Metrics + instrumentation plan  
10) Implementation notes for developers (component hints + edge cases)

## Microcopy Guidelines
- Buttons: outcome-based (“Generate report”, “Buy credits”)
- Er