When I’m signing up for online services, my zip code is 00400.
In Nairobi, we don’t have zip codes. A large number of web services I use require me to fill one in to get started, even if it’s a purely digital service that has no real need for a physical address. Over the years, I’ve standardized on that random number out of muscle memory.
It’s a minor annoyance that’s easy to overcome. Still, it comes to mind when I read articles about precise UX optimization: tweaking the wording or color of a call-to-action button, or optimizing a sign-up form’s language to nudge conversion rates up by a fraction of a percentage point. Surely then, dropping the zip code field when I visit from a non-American IP merits a place somewhere in the backlog. I would imagine that a new internet user in a country without zip codes is much more likely to fall off in a signup process due to that form field than due to suboptimal CTA button styling.
An overlooked category of inclusive web design
In recent years, much of the focus of the engineering inclusivity debate has been focused on the training of AI models with biased datasets. This is an important and burning topic, given the very real impact that bad AI models have already had in policing, hiring automation, sentencing, and so on.
Going back a few more years, the inclusivity conversation was primarily about improving web standards to support those with visual and physical disabilities, increasing the rate of adoption of these standards, and supporting non-English speakers on the web.
The zip code field is also an example of exclusionary web design, but in a subcategory that gets a lot less attention in the conversation. I suspect that’s partly because it may come across as superficial: if a Silicon Valley startup needs to know their US customers’ zip codes, is it really asking too much for their international users to make one up?
The trial version of the internet
If the zip code input was a slight barrier, a few lines down the sign-up form we come to a concrete wall: the credit card form. In Kenya, over 80% of the population is online, and virtually every adult has access to a mobile money account. Less than 1% of our web population has a credit card.
Think back to every paid online course you ever took, even if you made sure you completed it within the free trial before your card got billed; the AWS account you set up for your hobby or learning apps, which required a credit card even if you never exceed the free tier; that in-app purchase that unlocked the full power of your favorite productivity app.
The majority of the internet’s users are completely locked out of these purchases and card-required free trials, restricted to only a subset of the learning, entertainment, and money-making potential of the full internet.
This content is not available in your region
The easiest response to finding out about the challenges that some users have in accessing your content or service, or the lack of local content rights agreements, is to block the affected users outright. The familiar banner on social media video posts telling us that this content isn’t for us has become a bit of a meme on Kenyan Twitter, and it is at its most ironic when a clip of an African sports star’s achievements in a European football league can’t be legally accessed by their supporters back home.
There is, of course, a lot of complexity in handling content rights, tax regimes, government censorship, local payment integrations, and so on. However, when the order in which these are addressed invariably puts the poorer markets last on the list, the effect is for those of us in emerging economies to always be last to the party.
Producer/consumer imbalance
In online marketplaces, where users can both consume and contribute content, a common way these exclusive patterns play out is that an international user has full ‘read access’, but is limited in their ability to contribute if there is any monetization involved – even where there is no movement of physical products.
Until recently, Google’s Play Store users in several countries could only download apps from their free catalog. This is understandable, the regulatory and integration requirements to support local payment options in hundreds of markets are a huge headache. However, when Google did move to integrate with payment providers in Kenya, they only provided local payment options to buy apps, and it took almost a decade before they offered merchant accounts that allow local developers to monetize their apps.
It’s no surprise then that in the wild early app store days, African engineers were underrepresented in the success stories.
Nigeria has one of the fastest-growing tech scenes in the world, with local startups attracting global venture capital interest in recent years, and a few notable acquisitions. We’ve seen the first African-born unicorn startup in Nigeria’s Flutterwave, yet a freelance developer in the same country cannot receive money through Paypal. The company completely banned inbound transactions to personal accounts in response to the high fraud rates observed in Nigeria, addressing a tough problem by avoiding the issue.
There must be an untold tide of talented engineers who abandoned their craft because they couldn’t make any money doing it. How far down the road would the Nigerian startup scene be if they weren’t being forced to drive with the handbrake on?
Our continued failure to address this reality has a longer-term effect of casting the internet users in emerging markets in the role of serial consumers. 73% of internet users are in Africa, Asia, and Latin America; we’re all online, but taking in content largely produced by a minority in the global North for whom these barriers don’t exist.
Chicken-and-egg problem
In general, these barriers are not the result of intentional exclusion; they are much more likely the rational outcome of number-driven prioritization. When a large platform looks at their past sales data to plan out their market expansion, the cost associated with plugging in a local payout option in a country where they’ve only ever had a handful of contributors will always be low on the priority list. This is rational, but the observation becomes self-perpetuating; their small number of global contributors is a result of these imbalances in access to the platforms, which won’t be corrected without deliberate effort.
Fixing these imbalances does require an upfront commitment that will only pay back over time, but the large platforms, in particular, have both a strong moral obligation to address it due to the impact inclusion efforts will have, as well as a strong financial incentive, as these affected markets are also where the largest growth opportunities exist.
Inclusion through APIs
Thankfully, there is strong tooling available to engineers now to address this imbalance, and many of them come from producers in these markets who’ve decided to solve these problems themselves. For ecommerce, Alipay and Asiapay cover hundreds of local payment options through a single API. Nigeria’s Flutterwave and Paystack (recently acquired by Stripe) do the same for the bigger markets across Africa. Often, it just takes a bit of research leading to a more inclusive choice of API provider to unblock millions of potential customers around the world.
Most of the large content delivery networks now offer edge locations all over the globe, but you almost always have to opt in to enable the African, Middle Eastern, and (sometimes) Asian locations. This default leaves many streaming sites unusable on even the fastest of internet connections in these parts of the world. Switch all those edge locations on (the primary cost driver is the volume of access, not edge locations) and it makes a huge difference for the users in those locations.
Inclusion through fallback technologies
Inclusion doesn’t necessarily require abandoning cutting-edge technology. If you build your app to support more inclusive but potentially less exciting fallback technologies that could allow access to many more users. You can achieve inclusion without sacrificing the UX in any of your target demographics.
SMS and USSD are excellent fallbacks for your two-way customer interaction. These are old-school technologies whose death has been prematurely forecast for as long as the smartphone has existed. Globally, there are billions of mobile users still either on basic feature phones or on smartphones but with prohibitively expensive data plans. The reach of SMS is still greater than any other digital communication medium, including the internet and email.
If you’re planning to launch on iOS first, consider cross-platform frameworks like Flutter and ReactNative that have improved significantly over the years. They would allow you to release on Android at the same time, and in doing so, include the huge Android smartphone user base that globally outnumbers iOS users almost 3 to 1.
Check your product design assumptions
In addition to payment or communication channels as blockers, there are plenty of product design decisions that lock users out unintentionally.
Mobile first
Truly designing for an internet that is dominated by users whose only internet access is through a mobile device goes beyond responsive CSS. Mobile data is much more expensive per MB than most desktop connections, and many mobile users are only partially online as a result. If your online TV service, learning platform, or music app doesn’t offer offline caching, you’re leaving potential users out.
Not every web user has an email address
In recent years, Facebook led the charge on debunking this one by allowing users with smartphones, but who don’t use email, to log in using their phone number. It’s an increasingly common pattern to allow log-in by email or phone number.
One phone number ≠ one user
Families in emerging markets share access to the internet through a single device. This is not a niche edge case, it is the fastest-growing demographic of internet users. If your login assumes that only one account can be tied to a phone number, it prevents the members of a household from all having access to the account. The solution here is simply to allow for multiple profiles linked to one device, like Netflix does on their ‘Who’s watching?’ screen.
The fact that this affordance is common on platforms for the large screen, but rare on mobile devices, stems directly from more privileged assumptions of device ownership. It is a good example of how a lot of this problem can be solved by simply checking for biases in everyday product design decisions, and taking a little extra effort to accommodate variation in access and behavior of internet users worldwide.
