Iterative Design Loop¶
Three-step process for handling new information that impacts the design: scan, analyze, route.
The product design workflow supports iteration at any point. When new information arrives -- usability test results, stakeholder feedback, technical constraints, or market intelligence -- these three commands detect, assess, and route you back to the right phase.
The loop¶
New Input --> /pd-inbox-scan --> /pd-analyze-changes --> /pd-route-decision
|
Return to pd-1, pd-2, pd-3, etc.
Step 1: Inbox Scan¶
Command: /pd-inbox-scan
Scans the 00-Inbox/ folder for files newer than the last scan. Each item is
classified by type and urgency:
| Type | Urgency | Example |
|---|---|---|
| Usability test results | HIGH | usability-test-results.pdf |
| Stakeholder feedback | MEDIUM | stakeholder-review-notes.md |
| Technical constraint | HIGH | api-feasibility-report.md |
| Scope change request | HIGH | change-request-new-feature.md |
| Market intelligence | LOW | competitor-analysis.md |
| User research | MEDIUM | interview-transcript-05.pdf |
Updates .design-state.yaml with pending items and their urgency levels. HIGH
urgency items require immediate analysis before continuing current phase work.
Step 2: Analyze Changes¶
Command: /pd-analyze-changes
Reads each pending item, extracts findings, and applies the impact matrix to determine which artifacts are affected:
| Change type | PRD | Prototype | SPECchen | Return to |
|---|---|---|---|---|
| Usability test (critical) | -- | HIGH | -- | pd-3 |
| Stakeholder feedback (scope) | HIGH | HIGH | HIGH | pd-2 |
| User research (invalidating) | HIGH | HIGH | HIGH | pd-1 |
| Tech constraint (breaking) | HIGH | HIGH | HIGH | pd-2 |
| Bug report (prototype) | -- | HIGH | -- | pd-3 |
When multiple items have different recommendations, the earliest affected phase wins (pd-1 < pd-2 < pd-3 < pd-4).
Produces an impact report with aggregated recommendations and multiple routing options.
Step 3: Route Decision¶
Command: /pd-route-decision [--option N | --continue]
Presents the routing options from the analysis and captures your decision:
- Return to recommended phase -- Full or targeted rework
- Return to alternative phase -- Address subset of issues
- Split into parallel tracks -- Quick fixes vs. larger changes
- Continue current phase -- Defer items to backlog
- Manual override -- Custom routing
Upon selection:
- Increments the iteration counter in .design-state.yaml
- Resets quality gates for the target phase and all subsequent phases
- Bumps artifact versions for affected deliverables
- Logs the decision in iteration history
- Launches the target phase skill automatically
When to check for iterations¶
The design state should be checked:
- Before starting each phase (built into every /pd-* skill)
- When usability tests reveal issues
- When stakeholder feedback arrives
- When technical constraints are discovered
The .design-state.yaml file tracks the full iteration history, artifact hashes,
quality gate status, and all routing decisions for process learning.