design-validator

name

design-validator

description

Stress-test a feature design or PRD with diverse simulated user personas. Triggers include "validate this design", "stress test this PRD", "run user validation", "user persona feedback", "design review with personas", or when the user has a design document and wants adversarial feedback before committing to implementation. Runs 5 rounds of iterative refinement with an adversarial Skeptic who actively tries to reject the design.

Design Validator

Run simulated user research on any design document. Generates diverse user personas (including an adversarial Skeptic), iterates through 5 rounds of feedback, and produces a validation report showing how the design evolved and where confidence is high or low.

Requires: ruflo MCP (hive-mind).

This is the standalone version of Feature Forge's Phase 1.5. It works on any PRD, design doc, or feature spec — it does not require the full Feature Forge workflow.

Input

The user provides one of:

• A path to an existing document (docs/prd/my-feature.md, or any markdown file)
• A design described inline in the conversation
• A Figma URL or other design artifact to analyze

If the input is a file path, read it. If inline, capture it verbatim.

Workflow

Design Document
       │
       ▼
  1. Generate Personas (5-7, domain-specific)
       │
       ▼
  2. Validation Rounds (up to 5)
     Present → React → Synthesize → Decide → Revise → Convergence Check
       │
       ▼
  3. Validation Report
     Round-by-round evolution, Skeptic's verdict, confidence assessment
       │
       ▼
  4. Offer to update the original document (ask user)

Step 1: Generate Personas

Analyze the design to identify the domain, then generate 5-7 personas from these archetypes. See ../references/user-personas.md for detailed guidance on instantiating each.

Archetype	Role
Power User	Depth, scale, configurability
Newcomer	Discoverability, onboarding, terminology
Skeptic	Adversarial. Must find a reason to reject.
Edge-Case User	Accessibility, i18n, boundary conditions
Reluctant Adopter	Migration path, switching cost
Adjacent Stakeholder	Downstream effects, audit, permissions
Domain Expert	Correctness, standards, professional quality

Give each persona a name, specific role, daily workflow, and success/failure criteria.

Step 2: Validation Rounds

Initialize the hive-mind:

mcp__ruflo__hive-mind_init(queenId: "validator", topology: "mesh")
mcp__ruflo__hive-mind_spawn — one per persona
mcp__ruflo__hive-mind_memory(action: "set", key: "current-design", value: "<design content>")

Each Round

Present — Broadcast the current design (plus what changed since last round):

mcp__ruflo__hive-mind_broadcast(
  message: "Review this design from your persona's perspective. Design: <content>. Changes since last round: <changes>. Provide structured feedback using the template.",
  priority: "high"
)

React — Each persona returns structured feedback:

• First Reaction, What I Like, What Confuses Me, What's Missing, Deal-Breakers, Suggestion
• Skeptic additionally: Reason to Reject (mandatory)

Synthesize — Identify:

• Consensus themes (3+ personas)
• Minority reports (1 persona, potentially important)
• Contradictions (design tensions needing trade-offs)
• Skeptic's rejection (evaluate honestly — highest priority if valid)

Decide — For each theme: Accept (revise), Reject (document rationale), Defer (future), or Investigate (next round).

Revise — Update the design. Record what changed, who triggered it, why.

Convergence Check — Count material changes. Two consecutive rounds with zero → stable, exit early. Round 5 still has changes → flag unresolved tensions.

Persona Rotation (Rounds 3+)

Optionally drop a persona whose concerns are fully addressed and add one that tests a new dimension revealed by earlier feedback.

Step 3: Validation Report

Write to docs/prd/<name>-validation.md (or alongside the input file):

# User Persona Validation Report: <Name>

**Date**: <date>
**Rounds completed**: <N> (converged at round <M> / did not converge)
**Source document**: <path or "inline">

## Personas Used
| Name | Archetype | Context | Rounds Active |
|------|-----------|---------|---------------|

## Round-by-Round Evolution
### Round 1
**Feedback themes**: ...
**Changes made**: ...
**Changes rejected**: ... (with rationale)

## Skeptic's Verdict
<What the Skeptic tried to reject, whether the design survived, and their final assessment>

## Design Changes Summary
| # | Change | Triggered By | Round | Rationale |
|---|--------|-------------|-------|-----------|

## Convergence Analysis
- Stabilized at round: <N>
- Total material changes: <count>
- Change velocity: <trend>

## Confidence Assessment
### High Confidence (strong persona consensus)
### Medium Confidence (some disagreement)
### Low Confidence (unresolved tensions — needs real user testing)

## Recommendations for Real User Testing
<What simulation couldn't resolve>

Step 4: Offer Update

Ask the user: "Would you like me to update the original document with the validated changes, or keep it as-is with the validation report alongside?"

If yes, update the document inline, marking changes with [Validation Round N] annotations.

Reference Files

These are shared with the Feature Forge skill:

• ../references/user-personas.md — Persona archetypes, adversarial Skeptic instructions, feedback template
• ../references/phase1.5-user-validation.md — Detailed loop mechanics, convergence tracking, report format