Design thinking
“Fall in love with the problem, not your first solution to it.”
A common pattern in student projects: someone has an idea for a feature in the shower, the team gets excited, and three weeks later they've built something genuinely impressive that nobody who tests it actually wants. Not because the execution was bad — because the team fell in love with a solution before they properly understood the problem. Design thinking is, at its core, a discipline for slowing that down just enough to build the right thing.
What is design thinking?
Design thinking is a human-centred approach to solving problems, originally formalised by the Hasso Plattner Institute of Design at Stanford (the "d.school"). It's built around five stages: Empathize, Define, Ideate, Prototype, and Test. Despite being drawn as a neat five-step line, it's genuinely non-linear — teams jump backward and forward constantly, and that's expected, not a sign you're doing it wrong.
Why is this important?
If you skip straight from "we have a problem statement" to "let's build the obvious solution," you inherit every assumption baked into that first idea, and you don't find out it was the wrong idea until you've already sunk weeks into it. Design thinking exists to catch that failure mode early and cheaply — the same underlying instinct behind Root Cause Analysis (treat the causes, not the symptoms) and Understanding Stakeholders (know who you're actually building for). Design thinking is the process that ties those together into something you actually do, step by step, rather than just a principle you agree with in theory.
The five stages
- Empathize. Understand the people you're designing for — not by guessing, but through interviews, observation, and genuinely listening. This overlaps heavily with the elicitation work in Requirement Analysis. The goal here isn't to collect feature requests, it's to understand the underlying frustrations and context behind them.
- Define. Take what you learned and turn it into a sharp, specific problem statement — not "students need a better way to sign up for courses" but something like "students miss out on popular courses because sign-up windows close before they realise spots are filling up." A vague problem statement produces vague, unfocused solutions.
- Ideate. Generate lots of possible solutions before committing to one. Brainstorm without judging ideas yet — the goal is quantity and range first, evaluation second. Teams that jump straight to evaluating the first idea almost never end up with the best one.
- Prototype. Build the cheapest, roughest version of an idea that lets you test it. This does not mean working code. A prototype can be paper sketches, a clickable mockup, or even a scripted walkthrough — whatever is fastest to build and good enough to react to.
- Test. Put the prototype in front of real users (or as close as you can get) and watch what actually happens, rather than asking them to imagine it. Testing routinely sends you back to Empathize or Define with new information — that's the process working, not failing.
How this fits into a student project
You don't need a two-week design sprint to use this. A lightweight version for a course project might look like:
- A handful of short interviews or an observation session with real intended users, before you write any requirements.
- One sentence that states the specific problem you're solving — write it down and put it somewhere visible.
- A 15-minute brainstorm with the whole team where every idea gets written down before anyone critiques anything.
- A rough clickable mockup (Figma is fine, even hand-drawn screens photographed and linked together work) shown to two or three real users before you build the real thing.
This whole loop can realistically take a few days, and it will save you from the single most expensive mistake in a student project: building the wrong thing extremely well.
Tips
- Resist the urge to prototype in code. Every hour spent making a paper sketch or mockup look "real" is an hour you're not spending testing the actual idea.
- Don't let the loudest voice in the room win the ideation stage by default. Write ideas down individually first, then share — it stops early opinions from silently shrinking everyone else's options.
- Test with people outside your team. Your team already understands the product; that makes you the worst possible judge of whether it's actually clear to a first-time user.
- Treat "going back a stage" as normal, expected progress, not a setback to your timeline. Budget time for it up front rather than being surprised by it later.
References
Interaction Design Foundation — What is Design Thinking?
Nielsen Norman Group — Design Thinking 101
Stanford d.school — An Introduction to Design Thinking Process Guide