01The scheme everyone qualifies for and nobody enrols in
The review blames awareness. Usually it is four documents, three trips, and a form that assumes a permanent address.
Assumptions are expensive. Evidence is cheap.
We find out who your users really are and what they will actually do, before a budget is committed, a system is built or a team is deployed.
Programs rarely fail because the idea was wrong. A belief about people was.
Every proposal assumes things about users that nobody wrote down. They surface later as a number nobody can explain.
01
02The platform built for a phone the user does not own
Tested on a new handset with good signal, deployed to people with neither. Invisible in the office, total in the field.
03The frontline tool that adds work to a full day
Built to serve the dashboard, not the person holding the phone. It gets filled in on Friday from memory, which is worse than no data.
04The form that produces rejections instead of applications
A high rejection rate reads as fraud. Often it is an ambiguous field or a question that means something else in the local language.
Each of these was knowable in advance. None of them was known.
Seven uncertainties, removed while they are still cheap.
Design is usually sold as deliverables. It is more useful as a list of things you will know at the end.
As against who the proposal assumed. Almost always more than one group, and usually one nobody considered.
As against what they say they would do. Programs are routinely designed on stated intention.
The document they don’t have, the trip they can’t make, the question they can’t answer.
Most don’t matter. A few decide whether the program works at all. Knowing which is the single most valuable output.
Not the minimum viable product: the smallest thing that produces the outcome. Often far less than the proposal contains.
No smartphone, low literacy, a disability, an unplanned language. If it works for them it works for everyone.
A sequenced answer, so technology and field teams know what they are making and what is deliberately deferred.
The Assumption Ledger
Most programs fail on an assumption nobody wrote down. So we write them all down, find the few the program rests on, and test those.
A killed assumption, early, is the most valuable thing this work produces.
- 01
Surface
Every assumption the proposal makes about people: who they are, what they have, what they will do. Typically thirty to sixty. Listing them changes the conversation on its own.
- 02
Weight
Which ones the program actually rests on. An assumption is load-bearing if the program fails when it is wrong. Of sixty, usually five to eight.
- 03
Where most stop shortTest
Those few, taken to real users in real conditions. Not a workshop, a focus group or a survey: watching what people do, and trying things with them.
- 04
Where most stop shortRetire
Each load-bearing assumption confirmed, corrected or killed, with the evidence attached. This is the step clients thank us for later.
- 05
Specify
What survived, handed over as something a technology or field team can build from. Design that stops at a prototype leaves a gap; this closes it.
The Evidence Ladder. Where does each assumption actually sit?
An assumption isn’t simply true or false. Naming its rung turns a vague sense of confidence into something a team can act on.
Most dangerousMinimum to buildLoad-bearing minimum
Assumed
Nobody has checked. It seemed reasonable to whoever wrote the proposal.
Asserted
A stakeholder says so, often the one furthest from the user. It feels like evidence.
Observed
We watched people do it, in their own setting, unprompted.
Tested
We tried it with them and it held.
The standard we hold to
- No assumption reaches build below Observed.
- No load-bearing assumption reaches build below Tested.
- Every assumption carries its rung and the evidence behind it.
- A rung can go down as well as up, and we say so when it does.
Our design work, grouped by what it is for.
Most engagements draw on two or three of these, rarely all four.
Time with users in their own setting, observing rather than interviewing where possible.
Across beneficiaries, frontline workers and officials. Programs design for the first and are delivered by the second.
The journey people actually take, including the parts that happen outside your program.
Every step where someone has to do something, and what it costs them.
Research in the places people live and work.
The whole service, including the parts users never see.
Removing steps rather than improving them. The fastest gains usually come from deletion.
The job aid, the register, the app screen, designed for the end of a long day.
Unglamorous and often the highest-value work here. Fewer rejections do more for a scheme than most interventions.
What gets said, by whom, in which language, written in that language rather than translated into it.
How the service works, end to end.
For people with no training, no support desk and no second attempt.
Reusable across services, so the twelfth costs a fraction of the first.
A practice, not a checklist. For Indian government services it is also a legal requirement.
Scripts, input methods and layouts that survive longer words, and connectivity that comes and goes.
On the devices and connections people actually have, where they are.
Interfaces for people with no training and no second attempt.
Built around the choices a manager makes, not the data that happens to exist.
Findings people read to the end and can act on.
A recognisable, trustworthy presence for the people a program serves.
Findings people read to the end.
Most design research is a visit. Ours is a residency.
A typical team flies in for two weeks and meets people once, on their best behaviour. Our field teams are already there, every week, so we can watch whether a change still holds after the novelty wears off.
What that makes possible
- Research that runs continuously, not in a two-week window.
- Testing on the devices and connections people actually have.
- Seeing whether a change survives past week three.
- Frontline workers as colleagues, not research subjects.
- Validation inside a live program, not a lab.
Related insights & case studies.
The cheapest place to be wrong is on paper.
An Assumption Audit lists what your program believes about people, and shows which beliefs it is resting on.