Dt Methods
MicrosoftOfficialPublished by Microsoft
- Skill
- Guidelines
- Business and productivity
- MIT
- No issues found
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
Download the skill as a ZIP:
https://autogineer.com/agent-skills/microsoft/dt-methods/downloadUnzip 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
| Method | Name | Core reference | Deep reference |
|---|---|---|---|
| 1 | Scope Conversations | method-01-scope.md | method-01-deep.md |
| 2 | Design Research | method-02-research.md | method-02-deep.md |
| 3 | Input Synthesis | method-03-synthesis.md | method-03-deep.md |
| 4 | Brainstorming | method-04-brainstorming.md | method-04-deep.md |
| 5 | User Concepts | method-05-concepts.md | method-05-deep.md |
| 6 | Low-Fidelity Prototypes | method-06-lofi-prototypes.md | method-06-deep.md |
| 7 | High-Fidelity Prototypes | method-07-hifi-prototypes.md | method-07-deep.md |
| 8 | User Testing | method-08-testing.md | method-08-deep.md |
| 9 | Iteration at Scale | method-09-iteration.md | method-09-deep.md |
Industry context references
Load the matching reference when the team identifies its industry context.
| Reference | When to load |
|---|---|
| industry-energy.md | Energy-sector vocabulary, constraints, empathy tools, and reference scenario. |
| industry-financial-services.md | Financial services vocabulary, constraints, empathy tools, and reference scenario. |
| industry-healthcare.md | Healthcare vocabulary, constraints, empathy tools, and reference scenario. |
| industry-manufacturing.md | Manufacturing vocabulary, constraints, empathy tools, and reference scenario. |
| industry-nonprofit-social-impact.md | Nonprofit and social impact vocabulary, constraints, empathy tools, and reference scenario. |
| industry-pharmaceuticals-life-sciences.md | Pharmaceuticals and life sciences vocabulary, constraints, empathy tools, and reference scenario. |
| industry-professional-services.md | Professional services vocabulary, constraints, empathy tools, and reference scenario. |
| industry-public-sector.md | Public sector and government vocabulary, constraints, empathy tools, and reference scenario. |
| industry-retail-cpg.md | Retail 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.mdFiles
- ATTRIBUTION.mdAdded by AutoGineer871 B
- LICENSELicence file added by AutoGineer1.1 KiB
- SKILL.md6.5 KiB
- references/dt-coach-telemetry.md1.5 KiB
- references/industry-energy.md9.1 KiB
- references/industry-financial-services.md10.7 KiB
- references/industry-healthcare.md7.7 KiB
- references/industry-manufacturing.md6.7 KiB
- references/industry-nonprofit-social-impact.md15.6 KiB
- references/industry-pharmaceuticals-life-sciences.md20.1 KiB
- references/industry-professional-services.md14.0 KiB
- references/industry-public-sector.md12.1 KiB
- references/industry-retail-cpg.md16.5 KiB
- references/method-01-deep.md10.4 KiB
- references/method-01-scope.md10.2 KiB
- references/method-02-deep.md15.6 KiB
- references/method-02-research.md7.0 KiB
- references/method-03-deep.md13.9 KiB
- references/method-03-synthesis.md8.9 KiB
- references/method-04-brainstorming.md13.6 KiB
- references/method-04-deep.md16.5 KiB
- references/method-05-concepts.md17.1 KiB
- references/method-05-deep.md17.7 KiB
- references/method-06-deep.md16.3 KiB
- references/method-06-lofi-prototypes.md17.2 KiB
- references/method-07-deep.md10.9 KiB
- references/method-07-hifi-prototypes.md9.8 KiB
- references/method-08-deep.md15.0 KiB
- references/method-08-testing.md11.5 KiB
- references/method-09-deep.md17.2 KiB
- references/method-09-iteration.md11.9 KiB
references/method-01-deep.md
title: 'DT Method 01 Deep: Advanced Scope Conversation Techniques' description: Deep-dive companion for DT Method 01 covering advanced scope conversation techniques.
On-demand deep reference for Method 1. The coach loads this file when a user encounters complex stakeholder ecosystems, organizational politics, multi-department scoping challenges, or manufacturing-specific scope patterns that exceed the method-tier guidance.
Advanced Stakeholder Mapping
The method-tier file organizes stakeholders into three tiers (primary, secondary, hidden) based on proximity to decisions. The layers below reframe that model around impact scope, capturing how influence radiates outward from direct participants to ecosystem-level actors.
Multi-Layer Stakeholder Maps
Expand beyond direct stakeholders to capture the full ecosystem:
Direct stakeholders: people who interact with the problem or solution daily.
Indirect stakeholders: people affected by outcomes without direct involvement (adjacent teams, downstream consumers).
Ecosystem actors: external partners, vendors, or integrators whose systems or processes intersect.
Regulatory bodies: compliance officers, industry regulators, safety inspectors, and union representatives who hold veto power over solutions.
Coaching prompt: "We've identified who works with this directly. Who else is affected by the outcomes, even if they never touch the system?"
Influence and Interest Analysis
Position each stakeholder along two dimensions to prioritize engagement:
High influence, high interest: key players who shape decisions and care about outcomes. Engage deeply and early.
High influence, low interest: stakeholders who can block progress but may not attend voluntarily. Keep satisfied through targeted updates and involve at decision points.
Low influence, high interest: supporters who provide rich context but lack authority. Keep informed and leverage as validators.
Low influence, low interest: monitor for changes in position. A stakeholder who moves quadrants during scoping signals shifting organizational dynamics.
Coaching prompt: "For each stakeholder, consider: can they change the direction of this effort, and do they want to?"
Relationship Network Analysis
Map connections between stakeholders to identify alliances, tensions, and information flow:
Who influences whom informally (mentorship, trust relationships, lunch-table conversations).
Where alliances exist that could accelerate adoption or create resistance blocs.
Which relationships carry tension that might surface as conflicting scope requirements.
How information flows through the organization compared to the formal reporting structure.
Coaching prompt: "When [Stakeholder A] raises a concern, whose opinion do they seek before deciding?"
Missing Voice Detection
Systematically check for unrepresented perspectives:
"Who is affected by this problem but has not been part of any conversation?"
"Which shifts, locations, or roles have we not heard from?"
"Who inherits the consequences of decisions made here?"
"Are there seasonal, temporary, or contract workers whose experience differs?"
Flag missing voices early. Gaps in stakeholder coverage compound through subsequent methods.
Power Dynamics Navigation
Scope conversations occur within organizational hierarchies and political contexts. The coach helps users navigate these dynamics without taking sides.
Formal Authority vs Informal Influence
Formal reporting structures rarely capture how decisions actually happen. Probe for informal influence:
The senior engineer whose technical opinion overrides management direction.
The long-tenured floor supervisor whose buy-in determines whether new processes succeed.
The executive assistant who controls access to decision-maker calendars and attention.
Coaching prompt: "Who in this organization can say no without it being official, and who can say yes without it sticking?"
Recognizing Political Pressure on Scope
Scope is sometimes constrained by politics rather than genuine boundaries:
A department excludes another team's processes from scope to avoid cross-functional accountability.
A leader narrows scope to a pet solution to control budget allocation.
Scope expands artificially to justify headcount or organizational relevance.
When the coach detects these patterns, guide users to surface constraints through neutral questions: "What would change about the scope if we included [excluded area]?" rather than confronting the political motivation directly.
Permission Conversations Disguised as Scope
Sometimes a "scope conversation" is really a stakeholder seeking permission to explore a problem openly. Signals include:
Tentative language: "I'm not sure if this is in our area, but..."
Frequent references to what their leadership would or would not approve.
Requests to keep certain findings out of documentation.
Coach the user to create psychological safety: validate the concern, explore it in a low-stakes format, and help the stakeholder frame the finding in terms their leadership values.
Conflicting Stakeholder Priorities
When stakeholders disagree on scope, use perspective bridging rather than mediation:
Reframe competing priorities as interconnected: "How does [Priority A] affect [Priority B] when both are present?"
Surface shared frustrations that both stakeholders agree exist.
Identify shared constraints that both stakeholders acknowledge.
Note divergent priorities without forcing resolution during scoping.
Multi-Department Scope Negotiation
Complex organizations present scope challenges that span team and departmental boundaries.
Cross-Functional Boundary Identification
Map where the problem crosses organizational lines:
"Where does your team's responsibility for this process end, and who picks it up?"
"Which handoffs between teams cause the most friction or delay?"
"Are there processes that multiple teams own different pieces of, with no single owner for the whole?"
Boundaries between departments often contain the richest problem space. Problems that exist in the gaps between teams are frequently the most impactful to solve.
Shared Dependency Mapping
Identify systems, teams, or processes touched by multiple stakeholders:
Shared databases, tools, or platforms that multiple departments rely on.
Common workflows that flow across team boundaries.
Shared resources (equipment, personnel, budget) that create competition between groups.
Coaching prompt: "If we changed how this works for your team, which other teams would feel the impact?"
Scope Escalation Patterns
Recognize when scope should expand based on discovered interconnections:
A problem attributed to one team turns out to originate in an upstream process.
Multiple stakeholders describe the same symptom from different vantage points.
Constraint discovery reveals that the proposed scope boundary falls in the middle of a critical workflow.
Escalation is a finding, not a failure. Document why scope expanded and what triggered the change.
Scope Anchoring Techniques
Prevent scope creep while keeping exploration open:
Anchor to the original business impact: "How does this relate to the [cost/time/quality] goal we started with?"
Use parking lots for valid but out-of-scope discoveries: capture them in the assumptions log for future exploration.
Distinguish between scope expansion (justified by evidence) and scope drift (gradual, unjustified widening).
Manufacturing-Specific Scope Patterns
Manufacturing environments present recurring stakeholder hierarchies, constraint types, and scope boundary challenges.
Production Line Stakeholder Hierarchies
Manufacturing stakeholder engagement follows a distinct hierarchy with different communication styles at each level:
Operators and floor workers focus on practical daily experience, information access, and task completion. Conversations are most productive on the floor during natural work pauses.
Supervisors bridge operations and management, focused on safety, shift coverage, and process adherence. They hold informal influence disproportionate to their formal authority.
Engineers and maintenance teams own technical systems and understand failure modes. They provide critical context about why current solutions exist.
Plant management tracks efficiency metrics, throughput, and cost. They frame problems in ROI terms and control budget decisions.
Safety and compliance officers hold effective veto power over solutions that affect worker safety or regulatory status.
Engagement sequence matters: start with operators and supervisors to understand ground-level reality before engaging management with findings.
Regulatory Constraint Scoping
Regulatory bodies function as stakeholders with veto power:
Compliance requirements are non-negotiable scope boundaries, not preferences to weigh.
Changes to processes involving safety, environmental controls, or quality certification require regulatory review.
Some constraints are well-documented; others exist as institutional knowledge held by compliance officers.
Coaching prompt: "Which regulations or certifications could be affected if we change this process?"
Shift-Based Scope Considerations
Problems in manufacturing environments often manifest differently across shifts:
Day shifts have more management oversight and support resources.
Night and weekend shifts operate with reduced staffing and may develop workarounds invisible to day-shift management.
Handoff between shifts is a frequent source of information loss and scope-relevant problems.
Include representatives from multiple shifts in stakeholder mapping. A solution scoped entirely from day-shift observations may fail during off-hours.
Supply Chain Scope Boundaries
Manufacturing scope intersects with supplier and customer processes:
Where does internal scope meet supplier-controlled processes (incoming materials, vendor-managed inventory)?
Where does internal scope meet customer requirements (quality specifications, delivery commitments)?
Which scope boundaries are negotiable with external partners, and which are fixed?
Supply chain boundaries define hard limits on what can change internally. Identify them early to avoid scoping solutions that require external cooperation not yet secured.
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 or Microsoft.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download dt-methods.zip