---
description: 'Deep expertise for Method 3: Input Synthesis — advanced affinity analysis, insight frameworks, and problem statement articulation'
applyTo: ''
---

# DT Method 03 Deep: Advanced Input Synthesis Techniques

On-demand deep reference for Method 3. The coach loads this file when a user encounters complex multi-source synthesis challenges, struggles to move from observations to genuine insights, needs structured scaffolding for HMW questions, or faces manufacturing-specific synthesis patterns that exceed the method-tier guidance.

## Advanced Affinity Analysis

The method-tier file covers basic affinity clustering by emergent theme. The techniques below handle scenarios where first-pass clustering fails to reveal actionable patterns or where data volume and complexity require structured multi-pass approaches.

### Multi-Pass Clustering

A single clustering pass groups data by the most obvious dimension and buries cross-cutting patterns. Multiple passes through the same data with different lenses reveal distinct insights each time:

* First pass by theme: group observations by the topic or domain they address (information access, safety, training, equipment).
* Second pass by stakeholder: re-cluster the same observations by who raised them (operators, supervisors, engineers, management). Patterns that span multiple stakeholder groups signal systemic issues.
* Third pass by severity or urgency: re-cluster by impact level to distinguish chronic friction from acute failure points.

Each pass produces a different view of the same research data. Insights that appear across multiple passes carry the strongest evidence.

Coaching prompt: "We've grouped these by topic. What happens if we re-sort them by who mentioned each issue instead?"

### Cross-Stakeholder Pattern Detection

Themes that appear independently from multiple stakeholder groups without prompting are the most robust synthesis findings:

* Shared pain points across departments indicate systemic constraints rather than local frustrations.
* Convergent language from different roles (operators and managers describing the same friction in different terms) signals a genuine pattern.
* Divergent interpretations of the same event reveal perspective gaps worth exploring rather than contradictions to resolve.

Coaching prompt: "Three different groups mentioned this without being asked. What does it mean when the same issue surfaces independently?"

### Outlier Investigation

Data points that resist clustering often contain the most valuable insights. Before discarding outliers, investigate what makes them different:

* A single observation that contradicts a strong theme may represent an edge case that breaks the proposed solution.
* An observation with no cluster match may indicate a perspective the research did not adequately cover.
* Contradictions between outliers and majority themes reveal assumptions embedded in the dominant pattern.

Coaching prompt: "This observation doesn't fit any of our clusters. What would have to be true for it to be the most important finding?"

### Temporal Pattern Recognition

Patterns that emerge across time dimensions add a layer standard clustering misses:

* Issues that appear at shift changes point to handoff and communication gaps.
* Seasonal patterns suggest environmental or workload-driven constraints.
* Onboarding-related issues that persist indicate training gaps; issues that fade indicate adaptation (which may mask poor design through learned workarounds).
* Frequency and recency patterns distinguish chronic friction from isolated incidents.

Coaching prompt: "When does this problem happen most? Is it constant, or tied to specific times, transitions, or conditions?"

## Insight Framework

The method-tier file introduces insight development. The framework below provides structured techniques for moving from surface observations to insights that genuinely open design directions.

### Observation to Inference to Insight Formula

A structured progression prevents teams from treating raw observations as insights:

* Observation: "[User group] [specific behavior observed during research]."
* Inference: "...because [underlying need, motivation, or constraint driving the behavior]."
* Insight: "...which means [implication for design — what this reveals about the problem space]."

Example: "Operators skip step 3 of the checklist" (observation) "because the 30-second feedback delay makes it feel like the system didn't register the input" (inference) "which means the system's response time shapes compliance behavior more than training or policy" (insight).

The formula works backward too: when a proposed insight cannot trace back to a specific observation with a plausible inference chain, it is an assumption rather than an insight.

### Insight Quality Criteria

An insight that meets all three criteria qualifies as robust enough to drive design decisions:

* Surprising: the insight is non-obvious. Stakeholders who hear it experience a shift in understanding rather than confirmation of what they already knew.
* Generative: the insight opens multiple design directions. A statement that points to only one possible solution is a recommendation, not an insight.
* Evidenced: the insight traces back to specific research data points. Insights without traceable evidence are hypotheses that require additional research.

Coaching prompt: "Is this surprising to the people closest to the problem? Does it open up new directions, or point to one specific fix?"

### Insight vs Observation Test

A quick diagnostic helps users distinguish insights from dressed-up observations:

* If removing the "because" clause leaves the statement equally useful, the synthesis hasn't gone deep enough.
* If the statement describes what happens but not why it matters for design, it remains an observation.
* If the statement could have been written before conducting research, it is a pre-existing assumption rather than a research finding.

Coaching prompt: "If we showed this to someone who hadn't done the research, would they learn something they couldn't have guessed?"

## HMW Question Scaffolding

How-Might-We questions bridge synthesis and ideation. Poorly calibrated HMW questions produce either meaninglessly broad brainstorming or solution-constrained design. The techniques below help users generate HMW questions that create productive creative tension.

### Breadth vs Depth Calibration

HMW questions sit on a spectrum from too broad to too narrow:

* Too broad: "How might we improve the factory experience?" — provides no design direction.
* Too narrow: "How might we add a voice interface to the repair manual?" — prescribes a solution.
* Well-calibrated: "How might we give operators immediate access to repair guidance without requiring clean hands or a quiet environment?" — defines the problem space and constraints without dictating the solution.

Test: can the question generate at least five fundamentally different solution approaches? If yes, the calibration is productive.

Coaching prompt: "Could a team brainstorm five completely different solutions to this question? If it only points to one approach, it might be too narrow."

### Generative Tension

Effective HMW questions contain a creative tension — two needs or constraints that seem to pull in opposite directions:

* "How might we make safety compliance feel empowering rather than bureaucratic?"
* "How might we reduce maintenance response time without adding headcount?"
* "How might we preserve institutional knowledge when experienced workers retire?"

The tension prevents the question from having an obvious answer, which is what makes it generative for brainstorming.

Coaching prompt: "What two things are in tension here? A good HMW question holds both sides without choosing."

### HMW Family Generation

A single insight should yield multiple HMW questions that explore different angles:

* Vary the stakeholder: "How might we [address this] for operators?" vs "...for supervisors?" vs "...for maintenance teams?"
* Vary the constraint: "How might we [do this] within existing budget?" vs "...with new technology?" vs "...through process change alone?"
* Vary the aspiration: "How might we eliminate [problem]?" vs "...reduce [problem] by half?" vs "...turn [problem] into an advantage?"
* Try inversion: "How might we make [the opposite of the problem] happen?"

Aim for five to eight HMW questions per strong insight. Quantity creates choice; choice enables prioritization.

### Priority Weighting

A lightweight technique identifies which HMW questions carry the highest design potential:

* Evidence strength: how many research data points support the underlying insight?
* Stakeholder breadth: does the question matter to multiple stakeholder groups?
* Feasibility range: can the team imagine solutions at different resource levels?
* Design space size: does the question open genuinely diverse solution directions?

Questions scoring high across all four dimensions become primary inputs for Method 4 ideation.

## Problem Statement Articulation

Synthesis culminates in problem statements that capture validated understanding. The formats below structure that articulation without making it rigid.

### Point of View Format

The POV format provides a template that balances structure with adaptability:

* "[User] needs [need] because [insight]."
* The user field names a specific stakeholder role, not "users" generically.
* The need field describes a functional or emotional need, not a solution feature.
* The because field contains the insight — the non-obvious finding that shifts understanding.

Example: "Night-shift maintenance technicians need immediate access to equipment repair history because their isolation from day-shift expertise means they rely on documentation that doesn't capture the informal troubleshooting knowledge accumulated over years."

### Scope Validation

Every problem statement benefits from a scope check against Method 1 boundaries:

* Does the problem statement fit within the scope boundaries established during Method 1 conversations?
* If the problem statement expands beyond original scope, is the expansion justified by research evidence?
* Does the problem statement maintain the distinction between problem understanding and solution prescription?

Coaching prompt: "Does this problem statement match what we scoped in Method 1, or has our research revealed that the original scope was too narrow?"

### Assumption Audit

Surface which elements of the problem statement rest on validated evidence versus untested assumptions:

* Mark each claim in the statement as validated (traced to specific research evidence) or assumed (reasonable but not directly evidenced).
* Assumed elements are not necessarily wrong, but they represent risk. Acknowledge them explicitly rather than treating the entire statement as equally evidenced.
* High-assumption problem statements may need targeted return to Method 2 research before proceeding.

### Multiple POV Technique

Writing problem statements from different stakeholder perspectives reveals alignment and conflicts:

* Write the same problem from two or three different stakeholder viewpoints.
* Where POV statements converge, the synthesis has identified genuine shared understanding.
* Where they diverge, the synthesis has identified stakeholder conflicts that brainstorming must address rather than ignore.
* Divergent POV statements are a feature of thorough synthesis, not a sign of failure.

Coaching prompt: "If we wrote this problem statement from [different stakeholder]'s perspective, what would change? What stays the same?"

## Manufacturing Synthesis Patterns

Manufacturing environments produce recurring synthesis patterns worth recognizing. These patterns complement the general techniques above with domain-specific awareness.

### Process vs People Clustering

Manufacturing research findings often split into two natural clusters:

* Process improvement findings: equipment performance, workflow sequencing, throughput bottlenecks, material handling, system integration gaps.
* Human factors findings: ergonomic constraints, communication barriers, training gaps, shift-based experience differences, informal knowledge transfer.

Synthesizing across both clusters — not within one at a time — reveals the systemic themes. A process bottleneck caused by a human factors constraint requires a different solution than a pure process optimization.

Coaching prompt: "We have process findings and people findings. Where do they connect? Which process issues are actually people issues in disguise?"

### Safety Insight Extraction

Safety-related findings require special handling during synthesis:

* Safety findings are never deprioritized during theme ranking, regardless of frequency or stakeholder volume.
* Safety insights often emerge indirectly: workarounds that bypass safety steps reveal design friction rather than worker negligence.
* When safety findings conflict with efficiency findings, surface the tension explicitly rather than resolving it through prioritization.

Coaching prompt: "Are any of these workarounds creating safety risks? If operators are skipping a step, what's making the designed process impractical?"

### Efficiency Paradox Detection

Manufacturing synthesis frequently reveals efficiency paradoxes — situations where improving efficiency in one area creates problems elsewhere:

* Reducing operator task time may shift cognitive load to supervisors who must handle more exceptions.
* Automating a step may eliminate the informal quality check that operators performed unconsciously.
* Consolidating information systems may create single points of failure that affect multiple production lines.

These paradoxes are high-value synthesis findings because they prevent brainstorming sessions from optimizing one metric at the expense of system health.

Coaching prompt: "If we fix this efficiency problem, what else changes? Who absorbs the work or risk that currently lives here?"

* 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.
