Design thinking is a human-centered problem-solving framework with phases: Empathize (understand users), Define (clarify the problem), Ideate (generate solutions), Prototype (build and test), and Test (validate with users). It prioritizes iteration and user feedback over assumptions.
Walk through a real problem (redesigning a local business's website, solving a personal friction point) using all five phases. Conduct user interviews and test prototypes with actual users.
From your study of user-centered design, you already understand the core commitment: design should start with the people who will use the result, not with the designer's assumptions about what they need. Design thinking takes that commitment and gives it a repeatable process structure. The framework is often presented as five phases — Empathize, Define, Ideate, Prototype, Test — but the real insight is not the phases themselves but the way they enforce a discipline of delaying solutions until the problem is genuinely understood.
The first two phases are where most of the important work happens, and where most teams rush. Empathize means conducting interviews, observations, and contextual inquiry to understand users' actual behaviors, frustrations, and unmet needs — not what they say they want, but what you observe them struggling with. Define means synthesizing those observations into a clear problem statement, often framed as a "How might we..." question. For example, after observing that hospital nurses spend twenty minutes per shift hunting for supplies, the problem statement might be: "How might we reduce the time nurses spend locating supplies so they can spend more time with patients?" This reframing is critical because it separates the problem (wasted time finding supplies) from any particular solution (better signage, reorganized storage, a tracking app). Teams that skip or rush these phases end up building elegant solutions to the wrong problem.
Ideate is the divergent phase — generating as many potential solutions as possible without evaluating them. The discipline here is suspending judgment. Brainstorming is not about finding the right answer; it is about expanding the solution space so that non-obvious options surface. Quantity matters more than quality at this stage. From a broad set of ideas, the team selects the most promising candidates to move into Prototype — building quick, low-fidelity versions of the solution. A prototype might be a paper sketch, a cardboard model, a clickable wireframe, or a role-played service interaction. The point is speed and learning, not polish. A prototype that takes a week to build has already failed the purpose of prototyping.
Test means putting the prototype in front of real users and observing what happens — not asking if they like it, but watching whether it actually solves the problem identified in the Define phase. Testing almost always reveals surprises: users interact with the solution differently than expected, struggle with elements the team thought were intuitive, or use it to solve a different problem entirely. This is why design thinking is fundamentally iterative rather than linear. Testing feeds back into empathy (you learn something new about users), which may redefine the problem, which generates new ideas. The framework is a loop, not a pipeline, and the willingness to cycle back — to admit that your first definition of the problem was incomplete — is what distinguishes design thinking from a conventional project plan.
Topics in reflective domains aren't scored by quiz answers. Read, reflect, and mark when you've thought it through.