Product Designer
When to Use
- Frame a user problem and success metrics before UI work
- Map journeys, task flows, and information architecture
- Specify screens, states (empty/error/loading), and interaction behavior
- Prepare handoff for engineering (annotated flows, acceptance notes)
- Critique existing UX with heuristics and prioritized fixes
When NOT to Use
- Formal requirements documents and workshop facilitation →
business-analyst
- React/Next implementation or component code →
senior-frontend-software-engineer
- API/database design →
fullstack-software-engineer
- Marketing copy or long-form docs →
tech-writer-researcher
- Business model, TAM, competitor monetization →
business-model-researcher
Related skills
| Need |
Skill |
| Requirements and user stories |
business-analyst |
| Build UI from specs |
ui-software-engineer |
| Flows, prototypes, UX fixes in product |
ux-software-engineer |
| End-to-end delivery |
fullstack-software-engineer |
| In-product help text |
tech-writer-researcher |
| Canvas, market sizing, unit economics |
business-model-researcher |
Core Workflows
1. Discovery and framing
- State user, job-to-be-done, and current pain
- Define success metrics (task time, completion rate, support tickets)
- List assumptions; note what to validate in research
- Scope MVP vs later—explicit non-goals
See references/discovery_framing.md for one-pager template.
2. Flows and information architecture
entry points → primary path → branches → error recovery → exit/success
- One flow per user goal; avoid mixing admin and end-user paths
- Name screens consistently; show decision diamonds
- Call out permissions and role differences
See references/user_flows_journeys.md for flow notation and IA checklist.
3. Wireframes and interaction spec
For each screen document:
| Element |
Spec |
| Purpose |
What user accomplishes |
| Content |
Headings, fields, primary data |
| Actions |
Primary/secondary/destructive CTA |
| States |
Default, empty, loading, error, partial |
| Responsive |
Mobile vs desktop behavior |
Prefer low-fi structure first; visual polish after flow is stable.
See references/wireframes_specs.md for screen spec template.
4. Usability and accessibility (design)
- Apply Nielsen heuristics for review
- Plan keyboard path and focus order on critical flows
- Check contrast and touch targets against WCAG AA targets
- Do not treat design review as legal compliance sign-off
See references/usability_heuristics.md for review worksheet.
5. Engineering handoff
Deliver:
- Linked flows + screen specs
- Edge cases and validation messages
- Analytics events (name, trigger) if product uses them
- Open questions with owner
Align with business-analyst on acceptance criteria; with engineering on feasibility spike.
See references/design_handoff.md for handoff checklist.
6. Iteration after build
- Compare built UI to spec; log gaps by severity
- Verify states in staging (empty, error, long text)
- Capture follow-ups as tracked design debt or v2
When to load references
- Problem framing →
references/discovery_framing.md
- Flows and IA →
references/user_flows_journeys.md
- Wireframes →
references/wireframes_specs.md
- Heuristic review →
references/usability_heuristics.md
- Handoff →
references/design_handoff.md
1---2name: product-designer3description: Guides product design—problem framing, discovery synthesis, user journeys and flows, wireframes, interaction specs, usability evaluation, and engineering handoff for digital products (web and mobile). Use when designing a new feature UX, mapping flows, creating wireframe or spec narratives, running heuristic reviews, defining states and edge cases for UI, or preparing design-ready acceptance criteria—not for writing BRDs or business process docs (business-analyst), front-end implementation (senior-frontend-software-engineer, fullstack-software-engineer), or production code review (senior-software-engineer). For UI implementation from specs (tokens, states, Storybook), use ui-software-engineer. For interaction specs, coded prototypes, and in-product UX audits, use ux-software-engineer. For human data / labeling platform PM (tasks, quality, workforce), use product-management-human-data-platform. For business model canvas, pricing research, and unit economics, use business-model-researcher.4---56# Product Designer78## When to Use910- Frame a user problem and success metrics before UI work11- Map journeys, task flows, and information architecture12- Specify screens, states (empty/error/loading), and interaction behavior13- Prepare handoff for engineering (annotated flows, acceptance notes)14- Critique existing UX with heuristics and prioritized fixes1516## When NOT to Use1718- Formal requirements documents and workshop facilitation → `business-analyst`19- React/Next implementation or component code → `senior-frontend-software-engineer`20- API/database design → `fullstack-software-engineer`21- Marketing copy or long-form docs → `tech-writer-researcher`22- Business model, TAM, competitor monetization → `business-model-researcher`2324## Related skills2526| Need | Skill |27|---|---|28| Requirements and user stories | `business-analyst` |29| Build UI from specs | `ui-software-engineer` |30| Flows, prototypes, UX fixes in product | `ux-software-engineer` |31| End-to-end delivery | `fullstack-software-engineer` |32| In-product help text | `tech-writer-researcher` |33| Canvas, market sizing, unit economics | `business-model-researcher` |3435## Core Workflows3637### 1. Discovery and framing38391. State user, job-to-be-done, and current pain402. Define success metrics (task time, completion rate, support tickets)413. List assumptions; note what to validate in research424. Scope MVP vs later—explicit non-goals4344**See `references/discovery_framing.md` for one-pager template.**4546### 2. Flows and information architecture4748```49entry points → primary path → branches → error recovery → exit/success50```5152- One flow per user goal; avoid mixing admin and end-user paths53- Name screens consistently; show decision diamonds54- Call out permissions and role differences5556**See `references/user_flows_journeys.md` for flow notation and IA checklist.**5758### 3. Wireframes and interaction spec5960For each screen document:6162| Element | Spec |63|---|---|64| Purpose | What user accomplishes |65| Content | Headings, fields, primary data |66| Actions | Primary/secondary/destructive CTA |67| States | Default, empty, loading, error, partial |68| Responsive | Mobile vs desktop behavior |6970Prefer low-fi structure first; visual polish after flow is stable.7172**See `references/wireframes_specs.md` for screen spec template.**7374### 4. Usability and accessibility (design)7576- Apply Nielsen heuristics for review77- Plan keyboard path and focus order on critical flows78- Check contrast and touch targets against WCAG AA targets79- Do not treat design review as legal compliance sign-off8081**See `references/usability_heuristics.md` for review worksheet.**8283### 5. Engineering handoff8485Deliver:8687- Linked flows + screen specs88- Edge cases and validation messages89- Analytics events (name, trigger) if product uses them90- Open questions with owner9192Align with `business-analyst` on acceptance criteria; with engineering on feasibility spike.9394**See `references/design_handoff.md` for handoff checklist.**9596### 6. Iteration after build97981. Compare built UI to spec; log gaps by severity992. Verify states in staging (empty, error, long text)1003. Capture follow-ups as tracked design debt or v2101102## When to load references103104- **Problem framing** → `references/discovery_framing.md`105- **Flows and IA** → `references/user_flows_journeys.md`106- **Wireframes** → `references/wireframes_specs.md`107- **Heuristic review** → `references/usability_heuristics.md`108- **Handoff** → `references/design_handoff.md`
daemon-blockint-tech