Positive constraints from developing digital for the developing world

Building better products:

… and how we can all apply these lessons.

There is a huge difference between building technology for a user in the United States and for a user in say, Nigeria. The best way I can describe the magnitude of this divergence is by boiling it down to wants vs. needs. When you build something for someone with wants, expectations are built in based on previous experiences. In a world of wants, your interaction with technology is bountiful and it comes with expectations. In a world of wants, the digitally savvy users are receiving digital products that enhance an existing baseline, which means it is a layer on top of the need. For example — a banking app in New York is enhancing your options for moving money, checking balances, and depositing money; a banking app in rural Kenya is supplying the basic need to deposit money as there may be no other safe, available option.

In an erudite article that highlights a lot of the difficulties of ICT4D (Information and Communications Technologies for Development), Kentara Toyoma explains the myriad challenges to overcome: ‘context-appropriate technology, adhere to socio-cultural norms, account for poor electrical supply, build relationships with local governments, invite the participation of the community, provide services that meet local needs, consider bad transportation infrastructure, think through a viable financial model, provide incentives for all stakeholders, and so on.’ Our company is working through all of these constraints to design context appropriate solutions and a few of them we have solved for pretty well. I’ve realized that the solutions to these problems are valuable for two reasons:

1. They unlock a sustainable approach to technology for developing countries.
2. They demonstrate widely applicable approaches to product development for any user base regardless of digital savviness.

I share four constraints-turned-assets that we have found in the Tech4Good space, and that bring value to anyone building a digital product.

Time is not a number, time is a precious commodity

Time is a complex variable for measuring a digital product. I’ve worked on mobile apps where we wanted to increase time spent in order to signal increased engagement. I’ve worked on AI applications where our goal was to decrease time spent on customer service and therefore see increases in digital knowledge and cross-channel activity.

However, when you build tech for digital novices we are accounting for time spent with technology in relation to outcomes. We expect time to normalize to a point where there isn’t a disproportionate engagement vs. the value we can provide. So we are actually introspectively understanding what value we should bring to our users (the outcome), how long should it take to extract that value in the application, and how far off is that from the actual level of engagement. It is an exercise we could all benefit from and one that does not lend to loss in revenue. If your users spend too little or too much time in comparison to what your product can achieve for them, you have a user-lethargy-quotient or cognitive fatigue. Under the optimized time spent, you’ve lost opportunities to help the user. Over the optimized time spent, you’ve hurt the long term value you can bring to that user. When you pair this with the Jobs to be Done framework it is a great way to frame the product validation.

Symbolism doesn’t equate to simplicity

Symbolism is driving such a significant portion of a screens design space. We see symbols or visual assets as both an efficient translation mechanism and an efficient use of space. However, we discovered symbolism to be a big barrier in multi-cultural societies who lack exposure to technology. What does a hamburger menu mean? Red is the sign of the devil, how do we express errors or ‘out of bounds’ behaviour?

The mentality we have is to strip back the design to the basics and aggregate in a way that will work for our users. This means starting with the lexical form of communication, and then find what level of abstraction works and at which point does it become too western, i.e. incomprehensible to someone who speaks say, Somali. It is amazing to see what is better explained by diligent UX that uses logical procedural flows rather than symbolism to convey intent.

Power !> Size

Take a server, database, computer, phone, etc… As products they all started physically very large. Because when you start building a brand new technology, it’s a few orders of magnitude easier to compromise size for the benefit of greater processing power, and then shrink it over time. It is quite the opposite in the development context. We need to start small, we need to have something that can be easily transportable, but the compromise is power.

We all benefit, regardless of who and where are users are, to think small. To think: how small can we go and yet still be effective at achieving the fundamental mission of our purpose? Looking at the broader consumer computer-based electronics, phones are converging with tablets and laptops are shrinking to converge with tablets from the other end. This means we are either in the process of optimizing size and power, or we’ve just forgotten about the users needa and we are just growing phones to an unmanageable size that will require a certificate in handling heavy machinery. Don’t forget about the user; think big and build small — recognize going smaller might be a worthy tradeoff with increased processing power.

Agility only goes so far

Working in a perfectly symmetrical universe where infrastructure and user sophistication supports iterative releasing seems ideal. Release quickly, learn, and deploy is the boilerplate approach these days. However, it simply doesn’t apply to tech in international development and generally, isn’t always ideal. We have projects that have a few hundred users, out in rural communities, spread several hours drive from one another, with little to no internet, and — in some projects — with the app store locked by the project administrators! If we need to have them update the app, it is a logistical nightmare. If we want to release to some markets and not others, the google play store has a grouping of 165 countries called ‘rest of the world’. Guess what category most of the countries we work in fall into… We focus on parameterizing our app updates as much as possible, by looking at trade-offs much closer and by localizing changes and by abstracting as much as we can by remotely configuring from our cloud backend.

This constraint forces builders of a product to rethink the value of agile. Someone I spoke to at a conference (who had worked most of his career in B2B tech) told me that agility is a modern excuse for not knowing what the fu*k to do. I got a good laugh out of it, largely disagreed but also saw a twinkle of reason in the statement. It is easy to consider that the rapid deployment means a quicker path to a stronger product. However, it comes with a lot of trampling on users and spurious attempts to understand your user base. Because of our context, we have the mantra of develop agile and release waterfall. I still strongly believe in iterative development, but spend time being really internally critical about how important quick releases are for your product.

These constraints can sound like a nuisance or irrelevant. I would contend all of them make us sharper and more disciplined decision makers regardless of the digital savviness of our user base.