In 2006, a merry-go-round that pumped water while children played became the center of a $60 million public-private partnership announced through the US PEPFAR program. Within a few years, a report prepared for Mozambique’s government described women struggling to turn it, pumps out of action for up to 17 months, and maintenance as “a real disaster.”
Systems thinking vs design thinking is a difference in emphasis. Systems thinking explains how relationships, feedback, and delays keep a pattern in place. Design thinking studies what people need and tests prototypes with them. One asks what else will change; the other asks whether this works for the person using it.
The PlayPump: a charming design with no system around it
The idea was easy to love. As Columbia’s State of the Planet summarized it, children spin a merry-go-round connected to a pump, and water rises into a storage tank for use on demand. A 2005 Frontline segment spread the story, and Laura Bush and AOL founder Steve Case backed it.
The problems were mostly about everything outside the merry-go-round. Andrew Chambers in the Guardian cited WaterAid’s objections: about $14,000 per pump before drilling, four conventional hand-pump wells for the price of one, a mechanism too complex to repair locally, and children who would not be playing when water was needed, in the early morning, the evening, or the rain. By his calculation, meeting the program’s target of 10 million people at 15 liters a day would take children “playing” nonstop for 27 hours a day.
Frontline’s 2010 follow-up, “Troubled Water”, quoted an unreleased report for the Mozambique government: women found the pumps hard to operate, children did not play as expected, and some pumps sat broken for up to 17 months. Its reporting also quoted a complaint that without funding from PlayPumps International in the US, it was hard “to go and maintain stuff.” Jean Case of the Case Foundation later published a post titled “The Painful Acknowledgement of Coming Up Short.”
| What went wrong | Systems question that would have caught it | Design question that would have caught it |
|---|---|---|
| Water was needed when children weren’t playing | When does demand peak, and what supplies energy then? | Who actually draws the water, and at what hour? |
| Women ended up pushing the wheel | What happens when the designed energy source is absent? | Did anyone test it with the people who carry water? |
| Broken pumps stayed broken | Who pays for parts, and what loop keeps repairs going? | Can a local mechanic fix it with local tools? |
| One pump cost as much as four hand pumps | What is the cheaper alternative this displaces? | Would the community choose this over a hand pump? |
Both methods were thin here
The easy lesson is that the PlayPump needed systems thinking instead of design. Look at the right-hand column, though. Good design work would have caught most of these problems too. Stanford d.school’s bootleg starts with empathize: watch the real users in their real context. The people drawing water were often women, early in the morning, and the design centered on children at play, an image that appealed strongly to donors.
Systems thinking adds what a user test in one village will miss: the maintenance loop, the funding flow, and what happens at the hundredth installation. A broken pump sends people back to the old source, which removes any pressure to fix the pump. That is a feedback loop working against the project.
| Question | Systems thinking | Design thinking |
|---|---|---|
| Main emphasis | How relationships produce patterns over time | How an approach serves people’s needs |
| Common activity | Map variables, feedback, boundaries, and delay | Explore needs, frame a problem, develop and test a prototype |
| Useful output | A testable account of relationships | A tested proposal or learning from a prototype |
| Risk | A complicated map with no actionable test | A locally appealing solution that shifts burdens elsewhere |
The PlayPump is the fourth row, right column, at scale. For a fuller introduction to stocks, flows, and delays, see systems thinking.
How to combine them
- Frame the outcome and boundary. “Reliable water for this village” is a better frame than “install pumps.”
- Collect relevant evidence and perspectives. Include the people who do the work, plus the people who repair and pay.
- Map candidate relationships. Include feedback and delay where they plausibly matter, such as breakdown, repair, and use.
- Choose a bounded intervention. Identify what it is expected to change and what it might displace.
- Build a proportionate prototype. One pump in one village, watched for a full season, beats a ribbon-cutting.
- Test usability and system effects. A design can work in the demo and still push labor onto the people who were never asked.
Then revise both the proposal and the map. A failed test can expose a missing relationship as well as a design flaw. The iceberg model helps trace a single failure back to the assumptions behind it.
When either method backfires
Do not choose a method from its reputation alone. A simple factual error may need correction instead of a workshop, and a defined calculation may need a model instead of ideation.
A system map can become too broad to test. Record its boundary and mark which relationships are supported, inferred, or unknown. More arrows do not make a better explanation.
A design prototype can overfit the people who participated. Ask who was absent, whether their constraints differ, and whether the idea survives at the intended scale. A few delighted visitors are not an outcome evaluation.
Both approaches need a decision about what happens next. Record the change, the evidence, the owner, and what would make you stop. Before scaling, run the second-order thinking question: and then what?
Questions
Which method is better?
Neither in general. Understanding an interacting pattern and developing a usable intervention are related but different needs. Most real problems need some of each.
Can I start with a prototype before a complete system map?
Yes, when the test is small, reversible, and watched for side effects. A complete model is rarely available. Write down the boundary and the assumptions you are testing.
Does design thinking ignore systems?
No. Good design work considers constraints and consequences, and good systems work listens to people’s experience. The PlayPump fell short on both counts.
Your 5-minute method check
The problem in one sentence:
Who uses the solution, and when? Have I watched them?
Who maintains it, and who pays for that?
What will it replace or push aside?
What happens if it breaks for a month?
Smallest test that runs for a full cycle:To get a second view on your answers, paste them into one of the Save Effort prompts and ask it to find the user or loop you left out.