A decade ago, 70% of ICT4D products failed. Today, that figure has barely changed.
One reason is that we've imported design practices from the commercial sector without adapting the assumptions behind them. Over the past 13 years, we've learned to use those practices differently.

1. From User-Centred Design to System-Centred Design
User-centred design has transformed digital development by helping us understand people's needs and experiences. But many development challenges are not user problems - they're system problems.
Behaviour is shaped not just by need, but by trust, permission, relationships, incentives, institutions and social norms.
User-centred design helps us understand people. System-centred design helps us understand whether the system enables people to act.
What we do instead
Rather than starting with users, we start with behaviour.
We ask:
- What behaviour are we trying to enable?
- What conditions make it possible?
- Who creates trust, grants permission, or controls access?
- Who benefits from change, and who may resist it?
Only then do we design the intervention.


2. From Minimum Viable Products to Minimum Valuable Products
An MVP asks: "What is the minimum product we can build to test our assumptions?"
In social impact, that isn't always enough. People are often navigating fragile services, uncertainty and competing priorities. Their time and trust are valuable.
What we do instead
We ask: "What is the smallest thing we can create that delivers genuine value?"
The first interaction should solve a problem, reduce friction, build confidence or improve someone's situation—not simply help us learn. Learning still matters. But people should benefit from it from day one.
3. From Pilots to System Readiness Testing
Pilots often prove a product works under ideal conditions. They rarely prove a system can sustain it. Extra funding, intensive support and dedicated attention are often removed at scale.
What we do instead
Instead of asking: "Does the product work?"
We ask:
- Can the existing system support it?
- Do incentives align?
- Is ownership clear?
- Will adoption continue without project support?
Because scale isn't making a successful pilot bigger.
It's making an intervention work inside a real system.


The Shift
Over the last thirteen years, we've stopped starting with the product and started with the system. Before designing anything, we ask what outcome we're trying to create, what behaviours are required, and what conditions make those behaviours possible.
Only then do we ask: "What role should digital play?"
Sometimes digital is the intervention. Sometimes it enables the intervention. Sometimes it strengthens the wider system. And sometimes, it should play only a very small role.
Because digital products rarely create change on their own.
Systems do.



