vt-c-pd-4-validate¶
Usability testing and validation phase - test prototype with users and iterate based on feedback.
Plugin: core-standards
Category: Product Design Workflow
Command: /vt-c-pd-4-validate
Product Design: Validate¶
Test your prototype with users and iterate based on feedback. This phase ensures the prototype meets user needs before creating detailed specifications.
Workflow Position¶
/vt-c-pd-0-start → /vt-c-pd-1-research → /vt-c-pd-pid → /vt-c-pd-2-prd → /vt-c-pd-3-prototype → /vt-c-pd-4-validate → /vt-c-pd-6-handoff → /vt-c-activate
│
└── You are here
Test and iterate
Invocation¶
/vt-c-pd-4-validate # Show validation overview
/vt-c-pd-4-validate --plan # Create usability test plan
/vt-c-pd-4-validate --analyze FILE # Analyze test results
/vt-c-pd-4-validate --iterate # Start iteration cycle based on feedback
Intent Constraints¶
This skill MUST NOT: - Skip user test evidence to declare validation passed - Override the 80% task completion threshold without user approval - Modify the prototype directly (recommend changes, do not apply them) - Proceed to pd-5-specs or pd-6-handoff without passing the quality gate
This skill MUST STOP and surface to the user when: - Usability test results indicate critical task failures (0% completion on a core flow) - Test participant feedback contradicts PRD assumptions fundamentally - Insufficient test participants (< 5) to draw reliable conclusions
Configuration¶
# Project paths
prototype_path: "04-prototyp/"
prd_path: "03-PRD/PRD.md"
research_output: "02-Knowledge/04-Dokumente/"
Validation Loop¶
┌─────────────────────────────────────────────────────────────────┐
│ VALIDATION LOOP │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ │
│ │ /vt-c-pd-4-validate│ │
│ │ --plan │ │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Conduct │ │
│ │ User Tests │ (5-8 participants) │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ /vt-c-pd-4-validate│ │
│ │ --analyze │ │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌───────┴───────┐ │
│ │ Major issues? │ │
│ └───────┬───────┘ │
│ YES │ │ NO │
│ │ └──────────────────────────────────────╮ │
│ ▼ │ │
│ ┌──────────────┐ │ │
│ │ /vt-c-pd-4-validate│ │ │
│ │ --iterate │ │ │
│ └──────┬───────┘ │ │
│ │ │ │
│ ▼ │ │
│ ┌──────────────┐ │ │
│ │ Update │ │ │
│ │ Prototype │ │ │
│ └──────┬───────┘ │ │
│ │ │ │
│ ╰────────── Repeat until validated ──────╯ │
│ │
│ Then proceed to: /vt-c-pd-6-handoff │
│ │
└─────────────────────────────────────────────────────────────────┘
Iteration Loop Integration¶
Step 0: Check Design State (Before Starting)¶
Before beginning validation work, check the design state:
# Load design state
Read: .design-state.yaml
# Check for pending inbox items
if inbox.pending_items exists:
Run: /vt-c-pd-inbox-scan to process first
If this is an iteration (returning to validation):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Iteration Context: pd-4-validate
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Returning to validation phase (Iteration {n})
Trigger: {trigger from state file}
Reason: {reason from state file}
Previous iteration results:
• Tests completed: {quality_gates.pd-4-validate.criteria.usability_tests_completed}
• Task completion rate: {quality_gates.pd-4-validate.criteria.task_completion_rate}
Focus: Re-validate fixed issues
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Quality Gate: pd-4-validate¶
Mark phase as complete when: - [ ] Minimum 5 usability tests completed - [ ] Task completion rate >= 80% - [ ] Critical issues resolved - [ ] Findings documented
Quality Gate Threshold (Automatic Iteration): If task completion rate < 80%, automatically trigger return to pd-3-prototype.
Update state file on completion:
quality_gates:
pd-4-validate:
passed: true
passed_at: "{timestamp}"
criteria:
usability_tests_completed: 5
task_completion_rate: 0.85
critical_issues_resolved: true
PRD Delta Tracking (Active Throughout Validation)¶
During validation, user feedback and test results often reveal requirement changes. Track these continuously:
-
At validation start: Create
03-PRD/PRD-DELTA.mdif it doesn't exist, with this header: -
After each user interaction: If the user or test results reveal any of the following, append an entry to PRD-DELTA.md:
- Factual corrections ("actually there are 60, not 3")
- Scope changes ("we also need X")
- New requirements discovered during testing
- Assumption corrections from user feedback
- Data/content changes ("the categories are different")
-
Technical constraints discovered during validation
-
Entry format:
Categories: Scope Change, New Requirement, Requirement Update, Assumption Correction, Data Change, Constraint Discovered
- At validation completion: Show summary of accumulated deltas and remind user to review before /vt-c-pd-6-handoff.
Execution Instructions¶
Mode 1: Create Test Plan (--plan)¶
Invokes usability-test-designer agent to create a test plan:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Usability Test Plan - Product Design Phase 4
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Prototype: 04-prototyp/
PRD: 03-PRD/PRD.md
Loading user journeys from PRD Section 3 (Lösungsvision)...
Loading features from PRD Section 4...
Test Configuration:
─────────────────────────────────────────────────────────────────
• Participants: 5-8 (recommended)
• Duration: 30-45 minutes each
• Test type: Think-aloud protocol
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Output: 02-Knowledge/04-Dokumente/usability-test-plan-[date].md
Includes: - Task scenarios derived from PRD user journeys - Success metrics for each task - Moderator script - Observation template - Analysis framework
Mode 2: Analyze Results (--analyze FILE)¶
Analyze usability test recordings/notes:
Produces: - Task completion rates - Issue severity ratings (Critical/Major/Minor/Cosmetic) - Quantitative metrics - Qualitative findings - Prioritized recommendations
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Usability Analysis Summary
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Participants: N tested
Overall success rate: X%
Issue Summary:
──────────────────���──────────────────────────────────────────────
Critical (blocks task completion): X
Major (significant delay/confusion): Y
Minor (noticed but not impeding): Z
Cosmetic (aesthetic/preference): W
Top Issues to Fix:
─────────────────────────────────────────────────────────────────
1. [Critical] [Issue description] - Frequency: N/X users
2. [Major] [Issue description] - Frequency: N/X users
3. [Major] [Issue description] - Frequency: N/X users
Recommendation:
[✓] Ready for specs (minor issues only)
[✗] Needs iteration (critical/major issues found)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Mode 3: Iteration Cycle (--iterate)¶
Start an iteration cycle based on validation findings:
Steps:
1. Load latest analysis from 02-Knowledge/04-Dokumente/
2. Prioritize issues by severity
3. For each Critical/Major issue:
- Propose prototype fix
- Update prototype (using /vt-c-pd-3-prototype --feature)
- Track in iteration log
4. Recommend re-test after fixes
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Iteration Cycle
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Issues to Address:
─────────────────────────────────────────────────────────────────
Priority 1 (Critical):
[ ] [Issue] - Proposed fix: [description]
Priority 2 (Major):
[ ] [Issue] - Proposed fix: [description]
[ ] [Issue] - Proposed fix: [description]
Iteration Plan:
1. Fix Critical issue → Update prototype
2. Fix Major issues → Update prototype
3. Re-test with 2-3 users (quick validation)
4. Proceed to /vt-c-pd-6-handoff when validated
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Validation Checklist¶
Before proceeding to /vt-c-pd-6-handoff:
Validation Readiness Check:
─────────────────────────────────────────────────────────────────
[ ] 5+ usability tests conducted
[ ] Zero Critical issues remaining
[ ] Major issues addressed or documented
[ ] Task completion rate > 80%
[ ] User satisfaction rating > 4/5
[ ] PRD updated with validated requirements
[ ] Prototype reflects user feedback
─────────────────────────────────────────────────────────────────
Output Files¶
| Mode | Output |
|---|---|
| --plan | 02-Knowledge/04-Dokumente/usability-test-plan-[date].md |
| --analyze | 02-Knowledge/04-Dokumente/usability-analysis-[date].md |
| --iterate | 02-Knowledge/04-Dokumente/iteration-log-[date].md |
Integration with Product Design Workflow¶
/vt-c-pd-3-prototype ← Prototype to test
│
▼
/vt-c-pd-4-validate ← YOU ARE HERE - Test and iterate
│
│ Loop until validated:
│ --plan → conduct tests → --analyze → --iterate → re-test
│
▼
/vt-c-pd-6-handoff ← Prepare development handoff
When to Skip Validation¶
Validation can be abbreviated when: - Internal tool (team uses it themselves) - Very small feature addition - Following established patterns users know
Even then, at least 2-3 quick tests are recommended.
Error Handling (context: fork)¶
This skill runs with context: fork — it executes as an isolated sub-agent that returns only its output to the parent conversation. Fork sub-agents CANNOT interact with the user.
Critical rules for fork context:
-
NEVER ask interactive questions. No "Would you like...?", no "Should I...?", no AskUserQuestion calls. The question will be swallowed, the sub-agent will die, and the parent conversation receives no output at all.
-
If a file write fails, report it inline and continue. Use this format:
Warning — file not persisted: Could not write
{filename}. The full content is included in the output above. To persist, copy the content manually or re-run with write permissions. -
Always produce the full formatted output as the primary deliverable. The validation analysis returned to the parent conversation is the primary output. File persistence is secondary. Complete all analysis and recommendations BEFORE attempting any file writes.
-
PostToolUse hook interaction: This skill has a PostToolUse hook that echoes validation guidance after Write|Edit operations. The echo command is read-only and should still execute even when a write is denied. However, the hook's guidance about iteration may reference state that was not persisted — treat this as advisory, not authoritative.
-
Always end with a TL;DR summary. After the full report, output a concise summary as the absolute last output. Nothing may follow it. Max 10 lines between delimiters.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TL;DR
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Tests: [N] completed | Task completion: [X]%
Issues: [N] critical | [N] major | [N] minor
PRD Deltas: [N] recorded
[If critical issues]: Needs iteration — run /vt-c-pd-4-validate --iterate
[If validated]: Ready for /vt-c-pd-6-handoff
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Next Steps After Validation¶
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Validation Complete
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Design validated! Ready for detailed specifications.
NEXT STEPS:
─────────────────────────────────────────────────────────────────
1. Run: /vt-c-pd-6-handoff
Creates implementation-sized feature briefs
2. Run: /vt-c-pd-6-handoff
Prepares development package
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Open Brain Capture (Optional)¶
After completing validation, if the capture_thought MCP tool is available, capture the validation outcome.
When to capture: After every completed validation round.
How:
1. Check if capture_thought tool is available. If not: skip silently.
2. Call capture_thought with: