When working in underserved areas with limited infrastructure, try “designing under the mango tree.”

During a recent field visit, I observed a frontline worker who was new to CommCare. He was navigating through some lengthy forms and struggling with the idea that you can scroll vertically to reveal contents on the same page and horizontally to flip pages. Watching this interaction made me realize: Some design choices we assume to be intuitive often aren’t.

While building digital products, especially in the development sector, it is often the case that the person building the product and the person using the product are quite far apart on the spectrum of digital literacy. The end users might be first-time smartphone users who have never been online before. In fact, mobile internet penetration in India currently sits at only 25 percent. As such, it is important to plan for a more limited infrastructure in the field (e.g. worse network coverage, lower data speeds & limits, etc.) compared to the offices where the product is built.

Drawing from our philosophy of designing under the mango tree – otherwise known as directly collaborating with and learning from local teams – there are a number of tactics we recommend for designing and building digital products for users in underserved areas with limitations in connectivity and literacy.

Design locally

The person responsible for building a mobile application in an office in New Delhi may be more educated in technical lingo compared to the average ASHA worker in rural Uttar Pradesh. This makes it important to use clear, familiar language that is easily understood by all users. For example, in CommCare, we use words such as “sync” and “case,” but these words might be confusing for a first time user.

Feature naming follows a similar construct. Names should be simple and direct. For instance, “Household management” is a more easily understood module name than “Update details of a household case.” Keeping the language as close to the terminology used in the field and even translating the application to the local language are ways to further reduce the level of effort required of the end users.

Symbols and icons can have varied interpretations depending on the local culture. A pair of perpendicular intersecting lines could be read as a symbol for a hospital, or a church. Discussing such visual choices with the local partner before implementation is a good way to avoid misinterpretation.

Both the images represent a hospital, but the one on the right is a little less ambiguous

Go beyond words

Even among field workers in the same area, education and digital literacy levels can vary. During trainings, where users’ ages can vary, we often observe that older users can take more time to get comfortable using the application. Visual cues can be easier for first time users to understand. For example, the save button at the end of a form on CommCare is arguably the most important step of the process. Enhancing its clarity by coloring it green can help remind the user of its importance. However, only regular smartphone users may understand a green button on its own to mean “save” or a red box to mean “error”.

So while visual cues are important, the way they are implemented needs to be thought out with the local context in mind. Focus on function rather than aesthetic. For example, the recent popularity in app design of minimalism and muted colors might need to be swapped for bold, bright content that draws attention to the important functions of your app.

Bonus Tip!

In many of the regions we work in, there are great variations in the spoken language. For instance, even though much of North India speaks Hindi, the variations within the states can be immense. Using audio clips that read out the content in the local dialect adds tremendous value for low literacy users. It also adds credibility in the eyes of the beneficiary – hearing what the health worker says reinforced by the phone talking in a language the beneficiary is familiar with can increase her confidence in the message.

Build for offline use

Connectivity and data speeds can be quite erratic in the field, and building an application that works well offline is of paramount importance. Fortunately, frontline workers can use CommCare in the most remote areas without internet connection. The data they collect offline are stored locally on the phone, and then sync to the server when connection is reestablished.

To take full advantage of this feature, make sure your forms require as little data stored on the device as possible. While it is tempting to have the user capture a picture during every visit, or record a voice confirmation from the beneficiary, bear in mind that data packets can be limited and expensive. Increasing the amount of data users must submit increases the the risk that they will run out of data before the end of the month.

More likely than not, the devices chosen for deployment will be at the lower end of the performance spectrum. The app workflows should keep these performance limitations in mind,  and you should perform thorough testing on the exact same model.

Test everything

It goes without saying that workflows should be field tested and iterated multiple times before launch. However, user testing of design choices should also be made a priority.

• Is the navigation intuitive?
• Is the positioning of the ‘save’ button clear?
• Is the list cluttered with too much information?

These are some questions that could be built into the field testing plan. Fine tuning the usability of the app according to the local context can go a long way in driving adoption rates.

Choose the medium of testing based on what you’re trying to understand. If you have to decide between page designs, reviewing many different paper printouts at once is probably easier than scrolling between options on a tablet. If you want to observe the way users interact with the app, then a tablet of course makes more sense. Field testing using a full app on a device might not always be the best choice either – first time smartphone users might be distracted by the novelty of the device and bias the test results. In this case, having printouts of the mockups might be a better choice.

A Note on Field Testing

Make it a priority to identify the points of confusion or failure in a workflow during a field test and refine key workflows to make the experience intuitive from start to finish. For instance, if we observe that users are often making typos and having to go back revise case details, displaying a detailed summary screen before submitting the form can be helpful.

Close the loop

Regardless of how well you design an app or how useful its workflows are, showing users the value of the product helps improve app usage. Closing the loop by sharing the results of their work is a smart way to do this. Provide users with mobile reports that allow them to conceptualize the data they entered to remind them of the importance of what they’re doing.

Giving feedback to the workers on their performance is another way to drive up usage. Showing the users how they compare to their peers can act as good motivation, and has been shown to induce healthy competition among them. This can be built in as a simple graph or table within the app.

Stimulate usage rates by including reports that allow supervisors to acknowledge the work that users are doing. If a digital solution is rolled out to field workers without a way for the supervisor to gain visibility into the work they are doing, usage will die down from a lack of mentoring and feedback. We find that frontline workers lose the motivation to use an app if their work is not acknowledged.

Now what?

Designing under the mango tree is a core principle here at Dimagi, and while we’re continuously learning from each new app we build, we always try to (1) design for the end user, (2) build for the available infrastructure, and (3) test in the field. And this certainly isn’t the first time we’ve written about it.

Now that you know some of the basics of how we approach app design, how might you change your own app? Give it a try on CommCare and reach out on Facebook or Twitter to let us know how it went! Or if you have any questions, that’s great, too – just check out our introduction to mobile data collection or email us at info@dimagi.com. We would love to hear from you!