Here's a number worth sitting with: across Africa, the connectivity coverage gap has narrowed from 41% to just 9% between 2015 and 2024 — mobile broadband networks now reach the vast majority of the population. And yet, over the same period, the usage gap actually grew, reaching 64% in 2024, according to GSMA. Nearly 1 billion Africans live within reach of mobile internet and simply aren't using it.
That gap is not a connectivity problem. It's a design problem. When coverage exists but adoption doesn't follow, the honest explanation is usually that the products on offer weren't built with the people they're meant to serve. That's exactly what human-centered design exists to fix.
What Human-Centered Design Actually Means
Human-centered design is the practice of building products around the real constraints, behaviors, and context of the people who will use them — rather than around what's convenient for the business, or around assumptions inherited from a different market. For products built for African users, that means designing for the device someone actually owns, the data budget they actually have, the language they actually think in, and the way they actually pay.
The Data Behind the Gap
Cost is a major driver of the usage gap. In 2021, Africans paid an average of 6.5% of their monthly income for just 2GB of mobile data — compared to 1.7% in Asia-Pacific and 0.5% in Europe. Smartphone adoption across Sub-Saharan Africa sits around 51%, yet the region has the widest usage gap of any region in the world. Put simply: people are price-sensitive about data in a way that most product teams building on unlimited fiber connections rarely have to think about, and every megabyte a product wastes is a real cost to the person using it.
What Human-Centered Design Looks Like in Practice
Language and literacy
A product that only speaks the vendor's language, or assumes high digital literacy, silently excludes a large share of its potential users. That can mean multilingual interfaces, voice or audio-first flows, and interfaces that don't assume fluency with conventions borrowed from Silicon Valley apps.
Data and device constraints
Lightweight interfaces, compressed media, and genuine offline functionality aren't nice-to-haves — they're the difference between a product someone can actually afford to use and one they abandon after the first data-heavy screen. Design and test on the entry-level Android devices your users actually own, not the latest flagship.
Payment realities
Designing checkout around card payments, when mobile money is how most of your market actually pays, isn't a minor oversight — it's a structural barrier between your product and your revenue.
Trust and onboarding
In markets where digital trust is still being built, human support channels — WhatsApp lines, agent networks, a real phone number — often matter more to adoption than a polished self-serve flow. Trust is a design requirement, not an afterthought.
Cultural context, not just translation
Swapping in a local language without rethinking imagery, tone, and the framing of decisions (often more family- or community-oriented than individualistic) produces a translated product, not a localized one. The two are not the same thing.
Proof This Works: Designing With, Not Just For
The companies that have won African markets most convincingly tend to be the ones that treated localization as a design discipline, not a marketing checkbox. Transsion — the group behind Tecno, Infinix, and itel — built its dominance in African smartphones on exactly this: cameras tuned for a wider range of skin tones, dual-SIM support that matches how people actually manage cost across networks, and long battery life suited to less reliable power grids. None of that happened by shipping a device designed for another market and hoping it would translate.
Mobile money is another example of human-centered design at the infrastructure level: it didn't succeed by digitizing a Western banking model, it succeeded by solving the specific, local problem of moving money without requiring a bank account or a card.
How to Start Building Human-Centered Products
- Do real field research — talk to and observe actual users in-market, not a proxy audience.
- Co-design, don't just consult — bring real users into the design process early, not just for feedback on a finished mockup.
- Test on real devices and real networks — an entry-level phone on a throttled connection, not a developer's flagship on office Wi-Fi.
- Design the payment flow first — not last, as an integration bolted onto a finished checkout.
- Iterate in-market — ship, watch real usage, and adjust, rather than shipping once and assuming it landed.
Frequently Asked Questions
What is human-centered design?
It's a design approach that builds products around the real needs, constraints, and behavior of the people using them, rather than around assumptions inherited from a different market or user base.
Why do well-funded global apps sometimes fail in African markets?
Usually because they were designed around a different set of assumptions — unlimited data, card payments, high digital literacy, one dominant language — that don't hold for a large share of the intended audience.
How do you design for low-literacy or multilingual users?
Through a mix of approaches: voice and audio-first interaction, iconography that doesn't depend on text, local-language interfaces, and usability testing with real users at varying literacy levels rather than assuming a single baseline.
Does human-centered design cost more than a standard build?
It costs more upfront in research and iteration, but it's consistently cheaper than the alternative: building a product nobody adopts, then re-building it after launch once the real constraints become obvious.
Building genuinely human-centered products for African users is at the core of how we approach both our own products and our client work — see our in-house solutions for examples, or talk to us about a product that needs to work for real people, on real devices, on real networks.