Design thinking

Learning guide and study notes

What do people actually need? Use it for services and user journeys.

What you will learn

Distinguish a user need from a requested feature.
Explain what a prototype must help you learn.

What is it?

Design thinking centers engineering and service decisions on the lived workflow of real users and operators—alternating between broad discovery of human friction and rapid prototyping of simpler journeys.

Design Council's Double Diamond alternates divergence and convergence: Discover, Define, Develop, Deliver. Testing can take you back to the beginning.

Core question: What do people actually need?
When to use it: Use it for services and user journeys.

Tools and techniques

Key techniques

Double Diamond divergence–convergenceExplore user problems broadly before locking scope, then test multiple concepts before shipping.
Contextual user and reviewer observationWatch both service requesters and approvers in their actual workflow before automating a form.
Rapid journey prototypingPut a low-cost prototype in front of real users early and discard steps that cause friction.

Procedure: think it through step by step

Work through these steps in order, applying the tools above. Write down the answer to each step before moving on.

Discover
Observe affected people and gather evidence instead of accepting the initial brief as the problem. [1] Source: Design Council — Framework for Innovation (opens in a new tab)
Define and develop
Reframe the need, agree success criteria and generate multiple solution concepts. [1] Source: Design Council — Framework for Innovation (opens in a new tab)
Deliver and learn
Prototype, test with users, discard weak designs and iterate. [1] Source: Design Council — Framework for Innovation (opens in a new tab)

Try it now

Interview two people affected by a slow internal process; write a revised problem statement and prototype one change.

Visual guide

Workflow chart: Design thinking — **Workflow**From situation through deliberate steps to output

Mind map: Design thinking — **Mind map**Four connected questions to keep in view

Detailed examples

Core scenario

Situation: An internal access request takes too long.

How to apply: Observe both requesters and approvers before automating the current form.

Outcome: Test simpler flows that meet both user and review needs.

02 / Engineers bypass a self-service deployment portal

Situation: A new deployment portal has low adoption because engineers keep running manual scripts instead.

How to apply: Shadow three engineers during a release to see where the portal breaks their flow: it requires 14 fields they do not know upfront.

Outcome: Auto-populate environment defaults from the repository manifest and reduce the release screen to two confirmations.

03 / Confusing incident status page updates

Situation: During incidents, stakeholders flood chat channels even though the status page is updated every 15 minutes.

How to apply: Interview readers and discover that internal subsystem names tell them nothing about which customer workflows are affected.

Outcome: Redesign status templates around user-facing capabilities, current workaround, and next update time.

Illustrative examples showing how the lens changes decisions; not measured outcomes.

Practice and keep learning

Watch out: The four phases are iterative, not a one-way permission slip to ship a preferred solution.

Getting better at it

01 · Learn the foundationTreat the initial feature request as a symptom to investigate rather than a specification to code immediately.
02 · Build daily fluencyWatch at least two real users perform the task end to end and prototype on paper or mockups before writing production code.
03 · Master under pressureMeasure success by reduced user friction, fewer errors, and faster task completion—and be willing to discard a polished prototype that fails user tests.

Combine this lens with others rather than relying on it alone. Browse all thinkings

Review and make it your own

The idea to remember

Understand the user’s problem before committing to a solution, then learn through prototypes and feedback.

An outline for your notes

Use a problem of your own. Write a short answer to each prompt, then return after trying the method.

Observation: record what users do, where they struggle, and the context.
Problem: frame the need without assuming a feature.
Prototype: state the assumption to test and the feedback to collect.

Check your understanding

Answer from memory before opening the suggested answer.

Why might a requested dashboard miss the real need?

Compare with a suggested answer

The need may be to notice and act on an exception quickly. A dashboard is one possible solution; observation may reveal a simpler workflow.

What makes a prototype useful even when it fails?