Generated banner for Dt Methods
Generated logo for Dt Methods

Dt Methods

MicrosoftOfficialPublished by Microsoft

  • Skill
  • Guidelines
  • Business and productivity
  • MIT
  • No issues found

From the author

Design Thinking method coaching knowledge across all nine methods including per-method techniques, deep expertise, and industry context (energy, financial services, healthcare, manufacturing, nonprofit and social impact, pharmaceuticals and life sciences, professional services, public sector, retail and CPG)
— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The dt-methods skill provides a structured reference system for AI agents to coach teams through the Design Thinking process. It organizes guidance into three layers: core method references for day-to-day activities, deep references for advanced facilitation and recovery, and industry-specific context to tailor vocabulary and constraints. The skill covers nine major industries, including energy, healthcare, and financial services, ensuring that coaching is grounded in the specific operational realities and regulatory environments of the user's sector.

What it does

  • Provides step-by-step guidance for nine core Design Thinking methods.
  • Offers advanced facilitation techniques and recovery strategies for complex scenarios.
  • Maps Design Thinking concepts to industry-specific terminology and constraints.
  • Integrates telemetry expectations for session artifacts to ensure observable outcomes.
  • Supplies industry-specific empathy tools and stakeholder considerations.
  • Supports tailoring of coaching based on the active method and identified industry context.

When to use it

  • When facilitating a Design Thinking session and requiring method-specific guidance.
  • When a team needs advanced troubleshooting or recovery techniques during a workshop.
  • When applying Design Thinking within a specific industry to ensure relevant vocabulary and constraints are respected.
  • When defining telemetry or audit trails for Design Thinking session artifacts.

Advantages

  • Ensures consistent coaching across the entire Design Thinking lifecycle.
  • Reduces friction by using industry-appropriate language and concepts.
  • Provides a clear path for scaling from basic methods to advanced facilitation.
  • Integrates operational and regulatory awareness into the design process.

Usage examples

“How should I facilitate a brainstorming session for a team in the energy sector?”
The agent will load the brainstorming method reference and the energy industry context, providing guidance that uses energy-specific terms like 'reliability concern' and 'forced outage rate' while emphasizing safety and regulatory constraints.
“We are stuck during the user research phase; what advanced techniques can we use?”
The agent will access the deep reference for the Design Research method to provide advanced facilitation strategies and recovery techniques to help the team overcome their current roadblock.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/microsoft/dt-methods/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip dt-methods.zip -d .agents/skills

Documentation by Microsoft

Design Thinking Methods Skill

Entrypoint for Design Thinking method coaching knowledge. The dt-coach agent loads the method reference matching the active method in coaching state, the matching deep reference when advanced technique is needed, and the industry reference when an industry context applies.

How to use this skill

  • Read the method reference for the method currently active in coaching state to ground day-to-day coaching.

  • Read the matching deep reference when the conversation needs advanced facilitation, recovery techniques, or expert frameworks beyond the core method guidance.

  • Read the industry reference when the team has identified one of the nine covered industries as their context, and weave its vocabulary, constraints, and empathy tools into method-specific guidance.

  • Read dt-coach-telemetry.md when DT session artifacts need observable telemetry expectations grounded in telemetry-foundations.

Method references

Industry context references

Load the matching reference when the team identifies its industry context.

ReferenceWhen to load
industry-energy.mdEnergy-sector vocabulary, constraints, empathy tools, and reference scenario.
industry-financial-services.mdFinancial services vocabulary, constraints, empathy tools, and reference scenario.
industry-healthcare.mdHealthcare vocabulary, constraints, empathy tools, and reference scenario.
industry-manufacturing.mdManufacturing vocabulary, constraints, empathy tools, and reference scenario.
industry-nonprofit-social-impact.mdNonprofit and social impact vocabulary, constraints, empathy tools, and reference scenario.
industry-pharmaceuticals-life-sciences.mdPharmaceuticals and life sciences vocabulary, constraints, empathy tools, and reference scenario.
industry-professional-services.mdProfessional services vocabulary, constraints, empathy tools, and reference scenario.
industry-public-sector.mdPublic sector and government vocabulary, constraints, empathy tools, and reference scenario.
industry-retail-cpg.mdRetail and consumer goods vocabulary, constraints, empathy tools, and reference scenario.

Skill layout

.
├── SKILL.md
└── references/
    ├── method-01-scope.md
    ├── method-01-deep.md
    ├── method-02-research.md
    ├── method-02-deep.md
    ├── method-03-synthesis.md
    ├── method-03-deep.md
    ├── method-04-brainstorming.md
    ├── method-04-deep.md
    ├── method-05-concepts.md
    ├── method-05-deep.md
    ├── method-06-lofi-prototypes.md
    ├── method-06-deep.md
    ├── method-07-hifi-prototypes.md
    ├── method-07-deep.md
    ├── method-08-testing.md
    ├── method-08-deep.md
    ├── method-09-iteration.md
    ├── method-09-deep.md
    ├── industry-energy.md
    ├── industry-financial-services.md
    ├── industry-healthcare.md
    ├── industry-manufacturing.md
    ├── industry-nonprofit-social-impact.md
    ├── industry-pharmaceuticals-life-sciences.md
    ├── industry-professional-services.md
    ├── industry-public-sector.md
    ├── industry-retail-cpg.md
    └── dt-coach-telemetry.md

Files

references/method-03-deep.md


title: 'DT Method 03 Deep: Advanced Input Synthesis Techniques' description: Deep-dive companion for DT Method 03 covering 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.

Requirements and compatibility

Written for: GitHub Copilot, Claude Code

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Claude Code frontmatter

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Microsoft
Publisher
Microsoft (Official)
Source
microsoft/hve-core · .github/skills/design-thinking/dt-methods · commit f425e94
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download dt-methods.zip