Skip to content

why-design-thinking.md

Latest commit

 

History

History
92 lines (65 loc) · 4.9 KB

why-design-thinking.md

File metadata and controls

92 lines (65 loc) · 4.9 KB
Raw
title Why Design Thinking?
description Understanding when and why to use Design Thinking in your projects
sidebar_position 2
author Microsoft
ms.date 2026-07-15
ms.topic concept
keywords
design thinking
user-centered design
methodology
estimated_reading_time 4

Teams build features that users never asked for. Requirements documents capture what stakeholders say they want, not what they actually need. The gap between stated requirements and real needs is where projects fail, not in the code, but in the understanding.

Design Thinking closes that gap by placing human needs at the center of every decision.

When to Use Design Thinking

Not every task needs Design Thinking. Use it when:

  • Requirements are unclear, where stakeholders describe solutions ("build me a dashboard") rather than problems ("I can't tell which machines need maintenance").
  • Multiple stakeholders disagree, and different groups have conflicting needs that require synthesis.
  • The problem is complex, with solutions that span organizational boundaries, user roles, or technical systems.
  • User adoption matters, since the deliverable only succeeds if people actually use it.

For well-understood tasks with clear specifications, jump straight to RPI.

The Three-Space Model

Design Thinking organizes work into three spaces, each with distinct goals and quality expectations.

Problem Space (Methods 1-3) focuses on understanding who you are solving for and what they need. Explore broadly. Outputs are rough, not polished.

Solution Space (Methods 4-6) generates and tests ideas at low fidelity. The goal is learning, not building. Scrappy prototypes beat polished mockups because they invite honest feedback.

Implementation Space (Methods 7-9) builds functional prototypes, tests with real users, and refines based on evidence. Quality becomes functionally rigorous, though visual polish remains secondary to correctness.

Important

Each space has a deliberate quality standard. Producing polished output in the Problem Space or Solution Space wastes effort and discourages honest criticism. Rough artifacts invite better feedback.

DT vs Traditional Requirements Gathering

Aspect Traditional Requirements Design Thinking
Starting point Stakeholder wish list Observed user behavior and needs
Evidence basis Stated preferences Multi-source research and observation
Validation timing After implementation Continuously, at every space transition
Prototype fidelity High-fidelity from the start Lowest fidelity that tests the hypothesis
Stakeholder involvement Beginning and end Throughout the process
Handling disagreement Escalation or compromise Synthesis through shared observation
Output Requirements document Validated problem statement + prototypes

Relationship with RPI

Design Thinking and RPI are complementary, not competing.

Design Thinking answers what to build and why. RPI answers how to build it correctly.

When a Design Thinking session reaches a natural exit point, the DT Coach prepares a structured handoff artifact containing validated findings, confidence markers, and stakeholder maps. That artifact enters the RPI pipeline through rpi-research before the downstream Plan and Implement phases begin:

  • Problem Statement Complete (after Methods 1-3): rpi-research uses validated problem framing to scope technical research.
  • Concept Validated (after Methods 4-6): rpi-research uses stakeholder-validated concepts to scope implementation research.
  • Implementation Spec Ready (after Methods 7-9): rpi-research uses functionally rigorous specifications for focused technical investigation.

See DT to RPI Integration for the full handoff protocol.

Industry Applicability

Design Thinking applies across domains. The DT Coach supports industry-specific context templates that adjust vocabulary, constraints, and stakeholder archetypes:

  • energy
  • financial services
  • healthcare
  • manufacturing
  • nonprofit and social impact
  • pharmaceuticals and life sciences
  • professional services
  • public sector
  • retail and CPG

Industry context shapes the coaching conversation without changing the underlying method structure.

Getting Started

Start with the DT Coach to run your first guided session. The coach adapts to your experience level and guides you through each method at a pace that works for your team.

🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.