Product Workflow
Complete product design workflow: Requirements Analysis → Swimlane Diagram → Prototype Design.
When to Use
- User provides a requirements document or feature list
- User needs to analyze and refine requirements
- User needs swimlane diagrams for business processes
- User needs wireframes or prototypes
- User wants complete product design workflow
Workflow Overview
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Requirements │ ──► │ Swimlane │ ──► │ Prototype │
│ Analysis │ │ Diagram │ │ Design │
└─────────────────┘ └─────────────────┘ └─────────────────┘
Phase 1: Requirements Analysis
Objective
Transform vague requirements into validated, actionable specifications.
Analysis States
| State | Name | Symptoms | Actions |
|---|---|---|---|
| RA0 | No Problem Statement | Starts with "I want to build X" | Identify the actual problem |
| RA1 | Solution-First Thinking | Describes implementation, not needs | Extract functions, remove solutions |
| RA2 | Vague Needs | "Users should be able to..." without specifics | Add specificity, acceptance criteria |
| RA3 | Hidden Constraints | Discovering blockers mid-implementation | Create constraint inventory |
| RA4 | Scope Creep | Requirements expanding without priority | Apply MoSCoW prioritization |
| RA5 | Validated | Clear problem, testable requirements | Ready for design phase |
Key Questions
Problem Discovery:
- What's the problem you're solving?
- Who has this problem? (Be specific)
- What do they do today without this solution?
- Why hasn't this been solved before?
Need Clarification:
- What must the solution accomplish?
- How would you know if it's working?
- What's the minimum viable version?
Constraint Discovery:
- What's your actual time/skill budget?
- What must this integrate with?
- What assumptions haven't been validated?
Scope Definition:
- What's in V1 vs. later?
- What would you cut if forced?
- What's explicitly NOT in scope?
Output Artifacts
-
Problem Statement Brief
- Core problem description
- Target users
- Current alternatives and their limitations
-
Need Hierarchy
- Must-have (V1)
- Should-have
- Could-have
- Won't-have (deferred)
-
Constraint Inventory
- Real constraints (budget, time, skills)
- Assumptions (validated vs. unvalidated)
- Dependencies
-
Validated Requirements Document
- Testable requirements
- Acceptance criteria
- Priority ranking
Phase 2: Swimlane Diagram
Objective
Visualize business processes across multiple actors/roles.
Diagram Structure
┌─────────────────────────────────────────────────────────────────┐
│ SWIMLANE DIAGRAM TEMPLATE │
├────────────┬────────────┬────────────┬────────────┬─────────────┤
│ Role 1 │ Role 2 │ Role 3 │ Role 4 │ System │
├────────────┼────────────┼────────────┼────────────┼─────────────┤
│ │ │ │ │ │
│ [Step 1] │ │ │ │ │
│ │ │ │ │ │ │
│ ▼ │ │ │ │ │
│ │ [Step 2] │ │ │ │
│ │ │ │ │ │ │
│ │ ▼ │ │ │ │
│ │ │ [Step 3] │ │ │
│ │ │ │ │ │ │
│ │ │ ▼ │ │ │
│ │ │ │ │ [Step 4] │
│ │ │ │ │ │ │
│ │ │ │ │ ▼ │
│ │ │ │ [Step 5] │ │
└────────────┴────────────┴────────────┴────────────┴─────────────┘
Mermaid Syntax
flowchart TB
subgraph Actor1["👤 Actor 1"]
A1[Action 1]
A2[Action 2]
end
subgraph Actor2["👥 Actor 2"]
B1[Action 3]
B2[Action 4]
end
subgraph System["⚙️ System"]
S1[Process 1]
S2[Process 2]
end
A1 --> A2
A2 --> B1
B1 --> B2
B2 --> S1
S1 --> S2
Diagram Elements
| Element | Symbol | Description |
|---|---|---|
| Start | ([Start]) | Process beginning |
| End | ([End]) | Process completion |
| Action | [Action] | Activity or task |
| Decision | {Decision?} | Branching point |
| Database | [(Database)] | Data storage |
| Document | [[Document]] | Document output |
| Manual | [[Manual]] | Human task |
Best Practices
- One process per diagram - Keep focused
- Consistent lane order - Same roles across diagrams
- Clear flow direction - Top to bottom or left to right
- Label all elements - Descriptive action names
- Show decision points - All branches visible
- Include error paths - Exception handling
- Number steps - Easy reference
Phase 3: Prototype Design
Objective
Create wireframes and prototypes for user validation.
Design Process: Double Diamond
┌─────────────────────────────────────────────────────────────┐
│ DISCOVER │
│ Diverge: Research, explore, understand the problem │
└──────────────────────────┬──────────────────────────────────┘
│
┌──────────────────────────▼──────────────────────────────────┐
│ DEFINE │
│ Converge: Synthesize, insights, problem statement │
└──────────────────────────┬──────────────────────────────────┘
│
┌──────────────────────────▼──────────────────────────────────┐
│ DEVELOP │
│ Diverge: Ideate, prototype, test solutions │
└──────────────────────────┬──────────────────────────────────┘
│
┌──────────────────────────▼──────────────────────────────────┐
│ DELIVER │
│ Converge: Refine, build, launch │
└─────────────────────────────────────────────────────────────┘
Wireframe Components
Layout Components:
+----------------------------------+
| HEADER |
| [Logo] [Nav] [Nav] [Nav] [CTA]|
+----------------------------------+
+----------------------------------+
| HERO SECTION |
| |
| [Headline] |
| [Subheading] |
| [CTA Button] |
| |
+----------------------------------+
+-------+ +-------+ +-------+
| | | | | |
| Card | | Card | | Card |
| | | | | |
+-------+ +-------+ +-------+
+----------------------------------+
| FOOTER |
| [Links] [Links] [Social] [Legal] |
+----------------------------------+
Form Elements:
[Input Field Label]
[___________________]
[Dropdown Label]
[Select ▼]
[Radio Options]
( ) Option 1
( ) Option 2
(•) Option 3
[Checkbox Options]
[✓] Option A
[ ] Option B
[Button] [Secondary Button]
Design Principles
- Hierarchy - Visual weight guides attention
- Consistency - Reuse patterns and components
- Feedback - Acknowledge user actions
- Accessibility - Color contrast 4.5:1 minimum
Fidelity Levels
| Fidelity | Purpose | Time | Use Case |
|---|---|---|---|
| Low-Fi | Quick exploration | Minutes | Brainstorming |
| Mid-Fi | Flow validation | Hours | Team alignment |
| High-Fi | Dev handoff | Days | Implementation |
Deliverables
- Wireframes - ASCII or visual layout
- Component Specs - Sizes, states, behaviors
- Interaction Notes - Click, hover, swipe actions
- Responsive Breakpoints - Mobile, tablet, desktop
- States - Default, loading, error, empty, success
Complete Workflow Execution
Input
Requirements Document / Feature List / XMind Export
Step 1: Analyze Requirements
1. Identify problem statement
2. Extract core needs
3. Discover constraints
4. Define V1 scope
5. Create validated requirements
Step 2: Create Swimlane Diagram
1. Identify all actors/roles
2. Map process steps to lanes
3. Add decision points
4. Include error paths
5. Validate with stakeholders
Step 3: Design Prototype
1. Create information architecture
2. Design low-fi wireframes
3. Add interaction notes
4. Define responsive behavior
5. Document all states
Output
├── requirements/
│ ├── problem-statement.md
│ ├── need-hierarchy.md
│ ├── constraints.md
│ └── validated-requirements.md
├── diagrams/
│ ├── swimlane-main.md
│ ├── swimlane-[feature].md
│ └── flow-[process].md
└── prototypes/
├── wireframes/
├── components/
└── interactions/
Anti-Patterns
| Anti-Pattern | Problem | Solution |
|---|---|---|
| Solution-first | Building before understanding | Start with problem statement |
| Vague requirements | Can't test or validate | Add specific acceptance criteria |
| Missing constraints | Late blockers | Create constraint inventory early |
| Scope creep | Never finishing | Define explicit V1 boundary |
| No error paths | Incomplete diagrams | Always include exception handling |
| Over-detailed wireframes | Slow iteration | Start low-fi, refine later |
Quick Reference
Requirements Analysis Commands
- "Analyze this requirements document"
- "What's the core problem here?"
- "Identify hidden constraints"
- "Define V1 scope"
Swimlane Diagram Commands
- "Create swimlane diagram for [process]"
- "Map the user journey across roles"
- "Show the approval workflow"
- "Diagram the order fulfillment process"
Prototype Design Commands
- "Create wireframe for [screen]"
- "Design the user flow for [feature]"
- "Show responsive breakpoints"
- "Document component states"