.webp)
Design thinking
Most innovation meetings begin with a version of "what should we build?" It feels productive, and it quietly narrows the room to one kind of answer: a product. The teams that find better ideas tend to open with a different question. How might we solve this?
A small example of reframing
Ask "what makes a better children’s toothbrush?" and you will get a thicker handle, softer bristles, maybe a cartoon character. Ask "how might we help a child clean their teeth?" and the answers open up: a game that rewards brushing, a timer that plays a song, a different routine altogether. Same problem, far more room to move.
That shift from the thing to the problem is the heart of design thinking, a way of working that puts people first and asks the team to put its assumptions to one side. The approach grew out of design research from the 1960s onwards, with Horst Rittel’s idea of "wicked problems" (ones with no single right answer) as an early landmark, and became widely known through IDEO and Stanford’s d.school.
Three questions a good idea answers
- Desirability: do people actually want this? This means their real motives and frustrations, not their stated preferences.
- Viability: can the business sustain it, financially and otherwise?
- Feasibility: can we build it with the skills, time and technology we have?
Ideas that sit where all three overlap have the best chance of lasting. An idea strong on only one tends to become a lovely thing nobody buys, a profitable thing nobody wants, or a clever thing nobody can build.
Five stages, in a loop
- Empathise. Talk to people, watch them in their own setting and find the needs they have not named.
- Define. Pull the findings together into one clear problem statement that matches user needs with business goals.
- Ideate. Come up with many ideas, build on each other’s, and hold off on judgement until the list is long.
- Prototype. Make a rough version quickly, in cheap materials, so there is something to react to.
- Test. Put it in front of real people, listen honestly and learn what you did not expect.
The stages are not a straight line. Testing often shows that the problem was wrongly defined, and the team returns to an earlier step. That is not a failure. It is the process doing its job before the money has been spent.
What it gives a business
- Better ideas, because asking "how" surfaces options a competitor who is asking "what" never considers.
- More loyal customers, because the result answers something they really needed.
- Lower risk, because weak ideas fail cheaply, as a sketch, rather than expensively after launch.
- Teams that work together, because the method brings different departments into the same conversation.
Starting small
- Pick one manageable problem to practise on.
- Put people with different backgrounds in the room.
- Set aside what you think you know about the problem.
- Spend time with real users before you propose anything.
- Expect messiness. A tidy process usually means someone skipped the learning.
The challenges ahead are complicated, and the organisations that cope best will be the ones that ask better questions. Switch "what should we build?" for "how might we solve this human problem?" and you may find possibilities you had not imagined.