In this interview, lead engineer Adeola Victor Banjo discusses the unique challenges of developing a USSD maternal health platform for rural Nigerian communities on unreliable 2G networks.

He highlights the engineering required to overcome a strict 120-second session timeout, design intuitive text interfaces for low-literacy users, and embrace a “build for failure” mindset to deliver impactful, resilient technology in real-world conditions. Excerpt

As the engineer behind the USSD-based healthcare platform, what did you recognise as the hardest engineering problems to solve when you received the brief?

The hardest single problem was time. USSD sessions expire automatically, the network cuts them off after about 120 seconds of inactivity, and there is nothing the software can do to stop that.

So you are building a health screening tool that has to ask medically meaningful questions, display them clearly on a tiny screen, wait for the user to respond, and move to the next question, all within a window that can close at any moment. For a literate user on a smartphone, 120 seconds is plenty.

For a woman in a rural community who has never used a digital health tool before, possibly being guided by a community health worker reading the questions aloud, that same 120 seconds disappears very quickly? The second hard problem was that feature phones keep no memory between sessions. If a user times out, everything is gone, so they have to start over from scratch.

That is a terrible experience for anyone, but especially for someone going through a health questionnaire. So we had to build session memory into the backend itself, saving each user’s progress after every single step so that if they dropped off and came back, the system could pick up exactly where they left off.

It sounds straightforward but getting that to work reliably at scale, across thousands of concurrent users and unpredictable network behaviour, took significant architectural work.

Those two problems: the session clock and the memory problem essentially shaped almost every design decision that followed.

USSD sessions can time out quickly. How do you engineer a system that captures complex patient data like antenatal risks before the session expires?

The honest answer is that you do not try to race the clock, you design the system to make the clock irrelevant.

The first thing we did was save progress after every single step. As soon as a user answers one question and the system moves to the next, that answer is saved immediately. So the session timeout only ever loses one question’s worth of progress at most, not everything.

When the user comes back and dials in again, the system recognises them and continues from where they stopped. That single design decision is probably the most important one in the entire platform.

The second thing we did was think very carefully about the questions themselves. A USSD screen holds very little text. You cannot ask a long, clinical question the way a hospital form would word it. Every question had to be short enough to read quickly, clear enough that someone with basic literacy could understand it without explanation, and structured so that the answer required minimal typing, usually just pressing a number on the keypad.

We worked closely with health practitioners to strip the clinical language down to its simplest form without losing its medical meaning. That is harder than it sounds.

The third thing was speed on the backend. Every second the system takes to process an answer and load the next question is a second off the session clock. So the backend was built to respond almost instantly, with all the heavy processing which includes risk scoring, data storage, referral logic, happening asynchronously in the background after the session has already moved on. The user never waits for the system. The system waits for the user.

How did you approach designing a system that could handle low-literacy users, basic feature phones, and poor network coverage simultaneously?

The first thing I had to accept was that I could not design for the user I imagined, I had to design for the user who actually exists. In software engineering, there is a tendency to design for what we might call the average literate user, someone who reads instructions, understands numbered menus, and knows what to do if something goes wrong. But the women this platform was built for do not always fit that profile.

Some have never used a digital menu system before. Some are being helped by a community health worker who is reading the phone screen aloud to them. Some are in areas where the network signal drops mid-session without warning.

So we approached the design in three layers. The first layer was simplicity – every interaction had to work on the smallest possible screen, with the fewest possible steps, and the most predictable possible navigation. No clever shortcuts, no multi-step inputs. Just clear numbered options and single keystrokes.

The second layer was fault tolerance. The system was built to assume the network would misbehave.

Every request from a user’s phone was treated as potentially arriving twice, or out of order, or not at all. The backend was engineered to handle all of those scenarios gracefully without corrupting anyone’s data or sending them down the wrong path in their screening.

The third layer was recovery. When things go wrong, the system had to give users a way back in without starting over. That meant building resumption logic, clear error messaging in plain language, and a flow that never put a user in a dead end with no way out. The system had to be more patient than the network.

The platform has processed thousands of healthcare interactions. What does the real-world data tell you about what worked and what still needs improvement?

The data is honest in a way that controlled tests never quite are. You can design the most elegant system in the world, but once real users start interacting with it in real conditions, the numbers tell you things you did not expect.

What worked well is the architecture itself. Over 27,000 sessions were initiated since the platform went live, and the system handled the load without major failures on our end.

The antenatal risk screening tool, when users completed it, identified at-risk pregnancies with a sensitivity of nearly 99%, meaning it almost never missed a woman who needed referral to a higher level of care. That is the number that matters most in maternal health.

What the data also shows honestly is that only about one in four sessions was completed. The majority dropped off due to session timeouts (the 120-second network limit I mentioned earlier).

That is not a failure of the platform in the traditional sense, but it is a real-world friction point that we have to solve. The session resumption feature means those users can come back and finish, and many did. But reducing the number of timeouts in the first place, by making flows shorter and faster is a clear priority for the next version.

A small number of sessions also failed due to the USSD gateway running out of funds, which is an operational issue, not a technical one. But it taught me something important: in critical health infrastructure, you cannot afford operational gaps.

The system needs to be designed to prevent those situations automatically, not rely on someone remembering to top up a wallet.

For Nigerian engineers looking at problems in healthcare, agriculture, or education where users may not have smartphones or reliable internet, what engineering principles are most important to get right from the start?

Three things, and I would say the first one is by far the most important.

Design for failure first. In environments with unreliable power, inconsistent network coverage, and devices that range from old feature phones to mid-range smartphones, something will always go wrong.

The question is not whether your system will fail, it is whether it recovers gracefully when it does.

Engineers who build for the ideal case and then try to patch for failures end up with fragile systems. Engineers who build failure handling into the foundation end up with systems that last.

The second principle is to separate your logic layers early. What the user sees and
Interacts with should be completely separate from what happens in the background.

This sounds like an abstract engineering concept, but it has a very practical consequence: when you need to update the health questionnaire, or add a new service, or fix a bug, you can do it without shutting down the entire system or risking breaking something that already works. For a system that people depend on for their health or livelihoods, downtime is not just an inconvenience.

The third principle is to measure everything from day one. You cannot improve what you cannot see. Build visibility into your system before you launch, track how users move through your flows, where they drop off, where errors occur, and what the patterns look like over time. The data will tell you things your assumptions never could, and it will tell you faster than any amount of pre-launch testing.

USSD is text-based. How can engineers design menus that are intuitive for users with limited literacy or who are navigating technology for the first time?

The most important thing I have learned about designing for first-time users is this: never assume the person holding the phone is the person reading it.

In many of the communities this platform serves, a community health worker or a family member reads the screen aloud and inputs the answers on behalf of the user. That changes everything about how you write the text. It has to make sense when read aloud, not just when read silently.

Sentences have to be short enough to say in one breath. Options have to be memorable enough that the user can hear them, think about their answer, and respond without asking for the question to be repeated.

Beyond that, the design principles are fairly consistent. Keep menus to a maximum of four options, more than that and users lose track of what they heard first. Always number every option clearly. Always provide a way to go back. Never use technical language or medical jargon in what the user sees.

The best feedback we got during the design process did not come from engineers. It came from women in Lagos and Kano who told us, plainly, which questions confused them and which ones they found easy. That feedback changed the product more than any internal review did.