Dt Methods

title: 'Design Thinking Method 7: High-Fidelity Prototypes' description: Design Thinking Method 07 (High-Fidelity Prototypes) for building realistic artifacts for rigorous validation.

These instructions guide coaches through Method 7 of the Design Thinking process, managing the transition from lo-fi constraint discoveries to technical implementation validation while maintaining appropriate fidelity levels and preventing over-engineering.

Method Purpose

Method 7 serves as the Implementation Space entry point, transforming constraint discoveries from Method 6 into technically feasible prototypes. The primary purpose is validating that user-validated solutions can actually be built and deployed under real-world conditions, proving technical feasibility while maintaining scrappy functionality focus.

Method 7 bridges the Solution Space's constraint discovery with the Implementation Space's technical validation, ensuring working systems with real data rather than visual polish. Quality shifts from creative diversity to technical proof while avoiding production-ready refinement.

Sub-Methods Structure

Method 7 uniquely operates through three sequential sub-methods addressing distinct technical validation needs:

Each sub-method represents a distinct technical validation phase with clear transition criteria and specific coaching interventions.

Sub-Method Transition Criteria

7a to 7b transition gate

Advance to prototype construction when technical requirements are mapped from constraints, minimum 2-3 implementation approaches are identified, and environmental constraints are translated to testable specifications. Each criterion receives a status of Pass, Needs Improvement, or Requires Rework.

7b to 7c transition gate

Advance to specification drafting when functional prototypes are tested under real-world conditions, performance data is collected across approaches, and integration points are validated with existing systems. Each criterion receives a status of Pass, Needs Improvement, or Requires Rework.

Three Specialized Hats Architecture

Method 7 requires three specialized hats instead of the standard two-hat pattern due to the unique complexity of bridging lo-fi discoveries to hi-fi technical validation. The three-dimensional nature of this transition (constraint compliance, technical feasibility, and specification clarity) necessitates distinct expertise areas.

Hat Switching Logic

The Fidelity Translator activates when analyzing Method 6 outputs and constraint requirements. The Technical Architect takes primary control during prototype construction and technical validation. The Specification Writer leads when documenting findings and preparing Method 8 handoffs.

Progressive Fidelity Model

Lo-Fi to Hi-Fi Transition Criteria

Prototypes transition from lo-fi (Method 6) to hi-fi (Method 7) status when they meet these quality thresholds:

• Working system with real data integration, not simulated interactions

• Operation validated under actual environmental conditions (noise, lighting, workflow integration)

• Minimum 2-3 technical approaches tested for systematic comparison

• Connection and coordination with existing systems proven

Fidelity Progression Stages

1. Constraint Architecture (7a): technical requirements mapped from environmental and workflow constraints

2. Functional Validation (7b): working prototypes tested under real-world conditions measuring Performance (response time, throughput), User Effectiveness (task completion, errors), Integration (system compatibility), and Technical (resource usage, reliability) metrics

3. Implementation Documentation (7c): technical trade-offs captured with clear user testing preparation

Over-Engineering Prevention Patterns

Recognize over-engineering anti-patterns: visual polish, production-ready interfaces, single implementation paths, ideal-condition-only testing.

When teams drift toward over-engineering, redirect focus to functional core capabilities and comparative technical validation. The over-engineering escalation applies the general Progressive Hint Engine from the coaching identity to Method 7's specific challenge of maintaining functional focus over visual polish.

Use escalation levels: "What's the core technical question?" then "How does this compare to your other approach?" then "What would happen if you tested this with actual environmental constraints?" then "Remember the target is technical proof, not visual design."

Coaching Examples

Fidelity Transition Coaching

Scenario: Team has voice assistant concept validated in Method 6 but struggling with environmental noise constraints.

Level 1 Coaching: "What did your factory testing reveal about voice interaction?" Level 2 Coaching: "You found the 85dB noise challenge. What technical approaches might handle that constraint?" Level 3 Coaching: "Consider industrial-grade microphones with noise cancellation. How would you test different hardware approaches?" Level 4 Coaching: "Test consumer voice recognition in actual factory conditions, then compare with industrial microphone systems measuring accuracy and cost."

Over-Engineering Prevention

Scenario: Team building polished mobile interface instead of functional testing.

Intervention: "I notice you're focusing on visual design. This makes me think we might be getting ahead of Method 7's goal: technical feasibility with scrappy functionality. Want to focus on whether the core system works with real data, or should we keep polishing the interface?"

Specification Documentation Coaching

Scenario: Team completed prototype testing but documenting only the successful approach, omitting trade-off analysis for rejected alternatives.

Level 1 Coaching: "What did you learn about each approach you tested?" Level 2 Coaching: "You have strong data on the winning approach. What about the approaches that didn't work; what did they reveal?" Level 3 Coaching: "The rejected approaches often reveal constraints that Method 8 user testing needs to account for. How would you capture those trade-offs?" Level 4 Coaching: "Document each approach with performance data, failure modes, and constraint discoveries. Include why alternatives were rejected so Method 8 testers understand the full technical landscape."

Output Artifacts

Method 7 produces standardized technical validation artifacts organized under .copilot-tracking/dt/{project-slug}/method-07-hifi-prototypes/:

• technical-approaches/ contains one file per implementation approach, named approach-{name}.md. Each file documents the technical approach, performance data, environmental test results, constraint compliance, and comparison with alternative approaches.

• integration-testing/ contains validation results for system connections, named integration-{system}.md. Each file documents connection setup, coordination testing, compatibility findings, and identified gaps.

• implementation-specs/ contains trade-off documentation and user testing preparation, named spec-{topic}.md. Each file documents technical trade-offs, recommended approaches, rejected alternatives with rationale, and testing scenarios for Method 8 handoff.

Method Integration

From Method 6 (Lo-Fi Prototypes)

• Physical, environmental, and workflow constraint discoveries as technical requirements

• Validated interaction approaches as implementation specifications

• Assumption testing results indicating which core beliefs were proven or disproven

• User behavior patterns observed during real-environment prototype testing

To Method 8 (User Testing)

• Validated implementations ready for formal user comparison testing

• Known capabilities and limitations informing testing scenarios

• Multiple technical approaches for user preference validation

Cross-Method Consistency

Maintains DT coaching principles: end-user validation focus, environmental constraint application, multi-stakeholder perspectives, and iterative "fail fast, learn fast" refinement within technical feasibility constraints.

• All DT coaching artifacts are scoped to .copilot-tracking/dt/{project-slug}/. Never write DT artifacts directly under .copilot-tracking/dt/ without a project-slug directory.