Product Designer

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

Core Workflows

1. Discovery and framing

1. State user, job-to-be-done, and current pain 2. Define success metrics (task time, completion rate, support tickets) 3. List assumptions; note what to validate in research 4. 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:

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

1. Compare built UI to spec; log gaps by severity 2. Verify states in staging (empty, error, long text) 3. 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

Design handoff

Table of contents

1. Handoff checklist 2. Feasibility spike

Handoff checklist

• [ ] Flows linked and versioned
• [ ] All states specified (empty, loading, error, permissions)
• [ ] Responsive behavior noted
• [ ] Tokens/components referenced (not one-off hex unless new token approved)
• [ ] Acceptance criteria aligned with BA/PM
• [ ] Analytics events listed
• [ ] Known deferrals labeled v2

Feasibility spike

Before high-fi polish, confirm with engineering:

• Data available for UI?
• AuthZ rules per role?
• Performance constraints (large lists, realtime)?
• Third-party or platform limits (mobile, embed)?

Record decisions in spec header.

Discovery framing

Table of contents

1. One-pager template

One-pager template

# [Feature / initiative name]

## Problem
Who struggles with what today?

## Goal
What changes for the user if we succeed?

## Success metrics
- Primary:
- Guardrails:

## Scope
**In:** 
**Out:** 

## Assumptions
- 

## Open questions
| Question | Owner | By when |
|---|---|---|

Validate assumptions with at least one user or support-data signal before high-fi design.

Usability heuristics

Table of contents

1. Review worksheet 2. Severity

Review worksheet

Rate each heuristic 1–3 (issue severity) with notes:

Severity

User flows and journeys

Table of contents

1. Flow notation 2. IA checklist

Flow notation

Use simple boxes and arrows:

• Rectangle = screen or step
• Diamond = decision (role, validation, feature flag)
• Annotate happy path vs recovery path

Label each step with user intent, not system jargon.

IA checklist

• [ ] Navigation depth ≤3 for primary tasks
• [ ] Consistent naming with rest of product
• [ ] Clear home/back on mobile
• [ ] Settings/admin separated from core user tasks
• [ ] Destructive actions require confirmation pattern

Wireframes and specs

Table of contents

1. Screen spec template 2. Copy and validation

Screen spec template

## Screen: [Name]
**Route / entry:** 
**User role:** 

### Layout
[Structure: header, main, sidebar]

### Content
- 

### Actions
| Control | Type | Result |
|---|---|---|

### States
| State | Behavior |
|---|---|
| Empty | |
| Loading | |
| Error | |
| Success | |

### Notes
- Analytics:
- A11y:

Copy and validation

• Error messages: what happened + what to do next
• Empty states: why empty + primary action
• Avoid blame language ("invalid")—be specific