microsoft/hve-core

Public

mirrored from https://github.com/microsoft/hve-coreAvailable

CodeCommitsIssuesPull requestsActionsInsightsSecurity
ci/884-codeql-python-analysis

Branches

Tags

  • No tags available.
0Branches0Tags
Go to file
Add file
Code

Clone

HTTPS

Download ZIP

.github/instructions/design-thinking/dt-curriculum-05-concepts.instructions.md

51lines · modepreview

---
description: 'DT Curriculum Module 5: User Concepts — concepts, techniques, checks, and exercises'
applyTo: '**/.copilot-tracking/dt/**/curriculum-05*'
---

# DT Curriculum Module 5: User Concepts

User concepts translate brainstorming themes into visual representations that stakeholders can react to. This module sits in the middle of the Solution Space — it takes abstract solution themes from Method 4 and makes them concrete enough for feedback while staying rough enough to invite honest critique. The key insight is that concepts exist to transfer ideas from the team's head to stakeholders' heads, not to demonstrate design skill.

## Key Concepts

*Minimum viable visual representations* — Concept visuals should be the simplest possible assets that communicate the idea. Deliberate roughness signals "this is not finished, your feedback will shape it."
Polished concepts trigger aesthetic reactions ("I don't like the color") instead of substantive reactions ("I don't understand how this helps during emergencies"). Learners commonly over-invest in visual quality, believing polish demonstrates professionalism; it actually suppresses honest feedback.

*Understanding speed* — A concept should be graspable in 30 seconds or less without explanation. If the viewer needs a walkthrough, the concept is too complex or too abstract. This constraint forces clarity about what the solution does and who it serves. Learners often create concepts that make sense to the team but confuse external stakeholders because shared context was assumed.

*Interaction vs value demonstration* — Interaction concepts show how a user engages with the solution (screen flows, physical interactions, workflow steps). Value concepts show what outcome the solution delivers from different stakeholder perspectives (operator saves 10 minutes per repair, manager sees shift-consistent quality).
Both types are needed because stakeholders evaluate solutions through different lenses. Learners tend to create only interaction concepts and wonder why managers are not convinced.

*Silent review technique* — Present concept visuals without any verbal explanation, then ask "What do you think this represents?" Understanding gaps revealed through silent review are design problems, not viewer problems. This technique prevents the team from talking stakeholders into understanding a concept that does not communicate on its own.

## Techniques

*Stick figure approach* uses deliberately simple drawings — stick figures, basic shapes, labeled boxes — to represent user interactions. The roughness invites feedback and prevents aesthetic distraction. Good output is a concept that communicates the core interaction in under 30 seconds. The pitfall is spending more than 15 minutes refining a single concept visual.

*Environment context visualization* places the concept within the actual use environment. For the manufacturing scenario, this means showing the production floor, the noise indicators, the glove-wearing operator — not a clean white background. Good output is a concept where environmental constraints are visible. The pitfall is abstracting away the environment and losing the constraints that shaped the solution.

*Multi-perspective visualization* creates separate concept cards showing the same solution from different stakeholder viewpoints: the operator's experience, the supervisor's dashboard, the safety officer's compliance view. Good output is a set of 2-3 cards per concept that together tell the full value story. The pitfall is creating a single generic concept that resonates with no one specifically.

## Comprehension Checks

1. A designer spent 4 hours creating a detailed interactive mockup for stakeholder review. Why does this level of polish work against the goals of Method 5?
2. You show a concept to an operator who says "I don't understand what this does." Is this a failure of the viewer or the concept? What should you do next?
3. Why are both interaction concepts and value concepts necessary? What happens when a team presents only interaction concepts to a plant manager?
4. A concept clearly communicates its idea when the designer explains it verbally, but stakeholders are confused during silent review. What does this reveal?

## Practice Exercises

*Exercise: 30-second concept sketch* — For the manufacturing scenario solution theme "hands-free interaction during repairs," sketch a concept (stick figures and labels are encouraged) that communicates the core idea in under 30 seconds without any verbal explanation. Include at least one environmental detail (noise, greasy hands, floor layout).

*Exercise: Multi-perspective cards* — For the same solution theme, create three brief concept descriptions showing value from three perspectives: (a) the night-shift operator performing a repair, (b) the shift supervisor monitoring quality across the floor, (c) the safety officer reviewing emergency procedure compliance. Each description should be 2-3 sentences.

## Learner Level Adaptations

Beginners should focus on the minimum viable visual principle and practice creating rough concepts without over-investing in polish.

Intermediate learners benefit from comparing silent review results across concepts and understanding how concept feedback connects backward to Method 4 themes (invalidating or strengthening them) and forward to Method 6 prototype selection.

Advanced learners should explore how organizational culture affects concept reception (hierarchical organizations may suppress honest feedback), analyze when concepts reveal that synthesis themes from Method 3 were poorly framed, and critique the balance between simplicity and sufficient detail.

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