GoTap and the 36 Million

The situation

At Wema Bank I ended up owning a financial-inclusion programme that I still think of as the most important thing I have worked on. The product was called GoTap, and the problem behind it was enormous and unglamorous: in Nigeria, somewhere around 36 million adults are locked out of formal finance. Not because they do not want a bank account, but because every version of one that exists assumes things about them that are not true. It assumes a smartphone, a certain level of literacy, a comfort with forms and apps and jargon, an address that looks like the addresses the system was designed for.

GoTap was meant to reach the people underneath all of those assumptions. It spanned hardware, a mobile layer and a web layer, and it was built with merchants, students and institutional partners rather than for them. It was roughly a 2 million dollar programme, and it is the one where I stopped thinking of myself as someone who designs products and started thinking of myself as someone who designs services, because the interface was the least of it.

What I did

The team had a strong, reasonable assumption when I joined the relevant piece of work: that the barrier was language. The words were too complicated, so the fix was to simplify the words. It is a sensible first guess and I understood why everyone believed it. But I did not think it was enough, and I had learned by then not to win that kind of disagreement with an opinion. Opinions lose to seniority, and they should.

So instead of arguing that the team was wrong, I proposed that we actually test whether people understood, properly, rather than assuming either way.

The method I chose mattered more than anything else in this story. The usual way to check understanding is to ask people whether they understand, and it is useless, because everyone says yes. Saying yes is how you avoid looking foolish in front of a stranger with a clipboard. So I used teach-back instead. I asked people to explain the product back to me, in their own words, as if they were telling a friend how it worked.

The first round was brutal and clarifying. Only 31% of people could explain it back correctly. That single number did more than any argument I could have made. It ended the debate in about a minute, because it was undeniable and, crucially, it was the users’ own words failing to come back.

Then I ran it as a proper loop rather than a one-off study. I worked with a researcher and with 2 community partners who could reach people the bank simply could not reach on its own, people who would never have walked into a branch or answered a corporate survey. We went around 11 times, redesigning between each round. We cut steps. We replaced abstract written instructions with a physical demonstration, because showing beats telling when literacy is in play. And at one point we replaced a whole paragraph of explanation with a 9-second video of a woman actually using the product, and that one video outperformed every written version we had ever tested. A 9-second clip of a real person beat a deck of carefully written statistics. I have never forgotten that.

Holding the standard

Comprehension is not the whole of accessibility, so alongside the teach-back loop I held the technical line too. We audited the full journey to WCAG double-A, and we went to triple-A wherever it was reachable, particularly on colour contrast and on error messages that told people what to do rather than what had gone wrong. It passed at 100%.

The part I am quietly proudest of is that I did not keep any of it to myself. I turned the whole approach into a short, practical checklist and ran sessions with the other product teams, because accessibility that depends on one person being in the room is a risk, not a capability. And I made the commercial case out loud and on purpose: roughly 1 in 5 people is neurodivergent, so this is not charity, it is a fifth of the customer base. That framing is what kept it funded when funding is the thing that quietly kills good inclusion work.

Outcome

Comprehension went from 31% to 87%. The service passed its accessibility audits outright. And the method outlived the project, because other teams were using the checklist after I had moved on to other things.

The product is still live today, now operated by TapprX Limited at usegotap.com. The core service model is the one I shaped.

The lesson

Accessibility is not a screen you fix at the end. It is a standard you hold across the whole service, and then you teach it so it outlives you.

And the deeper lesson, the one that changed my career: do not ask people whether they understand. Watch whether they can use it.