Field reading, AI & digital systems
What happens when a digital tool designed for high-bandwidth, always-connected users meets an intermittent phone, a shared device, and a language it wasn't tested in.
An app that works flawlessly in a testing office often fails in exactly the settings it was meant to reach; understanding that gap is the whole difference between a launched product and an adopted one.
The story that "digital services will leapfrog institutional gaps" has become received wisdom. In practice, digital tools reach the people they were built for more reliably than the ones they were promised to serve. The failure is rarely the technology; it is the assumptions embedded in it. Constant connectivity. A private, personal device. English or French. Literacy in the app's genre. A payment method already set up. Any one of these missing quietly excludes a user, and the user then shows up in the metrics as "low engagement" rather than "the product was not built for them."
The pattern shows up across sectors. Health apps that assume the patient owns the phone the appointment is booked on. Agricultural advisory services that assume a smartphone where the household has a feature phone. Government service portals that assume steady electricity for the router. AI-powered assistants trained on languages the intended user does not read. The specifics differ; the shape of the exclusion is the same.
The Lab's field reading of digital-service transitions treats those assumptions as testable claims rather than product-management defaults. Who reaches the tool. Who does not. What happens on the third or fourth failed attempt. What people do with the tool that its designers never anticipated, and what they do not do that the designers assumed they would.
An app that assumes a stable connection breaks silently on an intermittent one. Users experience it as "the app doesn't work" and stop trying; the metric shows "abandonment." Reading the actual connectivity pattern of the users you intend to reach, the hours of the day the network is congested, the neighbourhoods where 2G is still the reality, the household electricity outages that take the router down with them, before the design freezes, is what closes that gap. Offline-first design is not a philosophical choice; in most of the contexts the Lab studies, it is the difference between usable and abandoned.
Shared devices are the norm across large parts of the world the Lab works in. A single household phone that moves between spouse, mother-in-law, and teenage children through the day. A market vendor whose phone is used by three neighbouring stall-holders whose own phones ran out of credit. A design that assumes a personal account with a personal history breaks in shared use, and often exposes personal information in ways the household will not tolerate. Studying who actually holds the phone at 3pm on a Tuesday tells you more about product-market fit than any funnel metric.
Testing in English is not testing. A digital service that was localised in a hurry after launch is a service that was designed for the wrong users first. Language-first design, choosing the target language before the interaction pattern, before the copy, before the onboarding flow, is a signal about who the product is genuinely for, and users read it correctly. The rise of high-quality AI translation has changed the economics but not the principle: a Swahili UI that reads as translated-from-English still tells the user something.
Digital literacy is not one thing. Someone who navigates WhatsApp fluently may find a form-based service completely opaque. Voice input helps until the accent it was trained on differs from the accent the user speaks with. The category of "literate" hides a dozen sub-questions, all of which fieldwork can answer and analytics cannot. What the user recognises as a "back" button, whether a scroll gesture is instinctive, whether tapping a link feels like reading or like committing to something risky, are all separate variables.
The newest layer, AI assistants integrated into consumer apps, adds a further class of assumption. Whether the model has been trained on the local dialect. Whether it defaults to safety behaviours calibrated for a different market. Whether its confident-sounding wrong answers cost more than its useful right ones. The Insight on AI absorptive capacity argues that the decisive variable is not raw capability but which local sectors are ready to convert the model into productivity. In consumer digital services the same question sharpens: an AI feature that improves the app for the median tester in the design office may degrade it for the median user in the target market.
Field research designed to reach users in the settings the product will actually meet: low-connectivity, multilingual, shared-device, informal, dispersed. The interview guide applied to actual usage in front of the researcher, not stated preference in a focus group. Screen-recording sessions with consented users, so the third-tap-that-fails is captured rather than reported. Structured observation in the location the product is meant to be used in (the household, the market stall, the clinic waiting room), not the participant's polite lounge.
Where the service claims to leapfrog a formal system (mobile money over banks, digital IDs over paperwork, AI advisory over an extension agent), the BRW framework reads what mechanism is actually operating, and whether the leapfrog is bounded by state architecture the service cannot renegotiate alone. Bounded leapfrogs are a real and useful thing; unbounded leapfrog claims almost always turn out to be bounded once the field evidence is in.
Digital services that reach real users at scale are not accidents. They are the product of design that took the setting seriously from day one. The Lab's reading treats the users, the device, the network, the language, and (where present) the AI layer as first-order design constraints, and measures against them. For the strategic frame of niche-technology adoption plateaus, see Four Ways a Transition Lands. For the payment layer most digital services depend on, see the payment-rail reading.
This is a Lab reading of the digital-service adoption question, drawn from the same field method used in the MiMaji engagement on water transparency, which is itself a digital-service adoption question dressed as a water question. For the wider expertise, see AI & Digital Systems. To discuss a study, see Contact.
