Human Centered Design Thinking in Practice
Many products, services and programmes fail for the same reason: they were designed around what the organisation assumed people needed, not what people actually needed. Human centered design thinking is a practical way to avoid that trap. It starts with the people you are designing for, tests ideas early and cheaply, and improves them based on real feedback before large sums are committed.
It is not just for designers or tech companies. Banks use it to simplify account opening, hospitals to cut waiting times, governments to improve public services and development programmes to design interventions that communities actually adopt. This article shows how it works in practice.
What human centered design thinking is
Design thinking is a problem solving approach that puts empathy and experimentation at the centre. It usually moves through five stages: empathise, define, ideate, prototype and test. In practice these stages overlap and repeat. You learn something in testing, go back to redefine the problem, and try again.
The mindset matters as much as the stages. It means staying curious about the people you serve, being comfortable with not knowing the answer at the start, and treating early ideas as experiments rather than commitments.
The five stages, with a worked example
To make this concrete, imagine a microfinance institution in Lagos. Many small traders start a loan application on its mobile app but never finish. Management’s first instinct is to run more adverts. A design thinking approach looks different.
1. Empathise. The team spends time with traders in markets, watches them use the app and asks open questions about their experience. They learn that many traders share one phone with family members, have patchy data, and abandon the form when it asks for documents they do not have on hand.
2. Define. The team turns what it learned into a clear problem statement: “Busy traders with limited data and shared phones need a way to start and finish a loan application in short sessions, without having every document ready at once.” A good problem statement is specific about who, what they need and why.
3. Ideate. The team generates many possible solutions before judging any of them: saving progress automatically, a USSD option, allowing documents to be added later, agent assisted applications in the market, or a lighter first stage that gives a provisional decision.
4. Prototype. Instead of rebuilding the app, they create quick, rough versions of the most promising ideas: paper screens, a clickable mock-up and a trial of agents with tablets on one market day.
5. Test. Traders try the prototypes while the team watches. Saving progress and adding documents later work well. The USSD idea confuses people. The team refines the strongest ideas and tests again before any major development spend.
The outcome is a better product, built faster and at lower risk, because the expensive decisions were made after the cheap learning.
How to apply it in your own work
You do not need a design lab to use this approach. A small cross-functional team and a few weeks can go a long way.
- Talk to at least five real users before you decide what the problem is. Watch what they do, not just what they say.
- Write a one sentence problem statement and get your team to agree on it before brainstorming solutions.
- Generate ideas in quantity first, then choose. The first idea is rarely the best one.
- Prototype in hours or days, not months. Sketches, role plays, simple mock-ups and pilot days all count.
- Test with real people and be willing to be wrong. Feedback that kills a weak idea early is a win.
- Include the people who will deliver the solution, such as frontline staff, so the design works in real operating conditions.
Common mistakes to avoid
- Treating it as a one-off workshop rather than a way of working.
- Doing “empathy” by surveying people instead of spending time with them.
- Falling in love with a solution before the problem is clear.
- Building polished prototypes that are too expensive to throw away.
- Ignoring the business case. Good design must also be viable for the organisation and feasible to deliver.
Why it matters for impact and change programmes
Human centered design is especially valuable for programmes that depend on people changing their behaviour, such as youth employment schemes, financial inclusion initiatives, health interventions and digital adoption projects. Designing with participants rather than for them improves uptake and makes results easier to sustain. These are exactly the skills explored in our Innovation & Impact Program Management (IIPM) programme, while Strategic Thinking and Problem Solving builds the wider problem solving toolkit.
For teams that want to apply the approach together, we also run tailored training for organisations.
FAQs: human centered design thinking
Is design thinking only for product design? No. It applies to services, processes, policies and programmes. Any situation where people’s needs and behaviour shape success can benefit from it.
How long does a design thinking project take? It varies. A focused team can move through a first round of research, ideas and testing in two to four weeks, then keep iterating as it learns.
What is the difference between design thinking and traditional planning? Traditional planning often decides the solution first and tests it at the end. Design thinking tests assumptions early with real users, so major investment follows evidence rather than assumption.