Designing Apps for the Illiterate and Digitally Challenged…India Edition
I recently worked in India as a product designer for a New Delhi based non-profit, MHS. There, I designed two apps to help low-income often illiterate communities and their banks design structurally sound homes to finance and build.
The first app is to let the future homeowner estimate their home’s cost within 10%. It also told the user exactly how many bags of concrete, bricks, number of labor hours, and everything the user would need to know to understand what goes into creating a home. These estimates were editable to help the future homeowner choose features within their budget.
I worked with a multidisciplinary team of architects and structural engineers to develop the software that would be deployed via on the ground helpers. If our users weren’t too good with technology why of all things would we make an app for them? Good question. In another Indian city, Ahmedabad, the team was running a pilot study with the excel version of the tool where we had someone walk potential homeowners through the app and get an estimate for their home.
With a mobile app, we could allow anyone with a smartphone to download the app and get an estimate themselves. This would make it easier for anyone anywhere in the community to get an estimate, rather than having a kiosk with a helper like we had set up in Ahmedabad.
To get back to designing the app, during our user testing in Delhi’s resettlement colonies and slums, we found testing the device difficult. Although many people had phones and nearly all the teenagers had smartphones we found language and reading were a big barrier for many of our users. In addition to reading, the vast cultural differences between a U.S. product designer and the users presented some interesting differences in picture interpretations.
I love a good product design challenge, so I started rapidly iterating on the designs and testing weekly with our users to figure out how each design was interpreted.
“What does this picture look like to you?”
“What does this color remind you of?”
“What do you think this button does?”
Through user interviews, we found our target users were mothers 25 -35 years with a couple of children and a husband who wanted to build their own home. The family wanted to get an estimate for how much the home would cost, but also wanted a way to keep the mason (building contractor) accountable. Currently, the man or woman go to the mason and talk through home design and the mason walks them through the options and gives an estimate. The mason may cut some corners to get the client to agree and, as is usually the case, would build a structurally inept home.
Our mission was to create a building estimate tool that told the homeowner exactly how much a structurally sound home in her region would cost.
Our mission was to create a building estimate tool that told the homeowner exactly how much a structurally sound home in her region would cost. The easiest way to give the estimate is through software. We decided on a mobile app because it is relatively accessible, except for the words because of the low literacy levels in Delhi and Ahmedabad where we were testing.
This meant that we needed to design an application that was simple and intuitive to use, culturally appropriate, and written in plain language while still understandable without reading.
We started the design process by employing some of the same design principles as Apple when they launched the iPhone. We made things look like they do in the real world. This design methodology called skeuomorphism aims to mimic real life as much as possible since our users understand real life better than abstractions of reality (like a line drawing of a paper airplane to sent).
Instead of showing a line drawing of a pipe, we would use a 3D rendering of a pipe for instance. During user testing, we showed people in the community four different drawings of the same thing each with a different drawing style. We found everyone understood the real-life pictures and 3D renderings, but only the younger community members understood the simplified pictures…and no one understood a line drawing of a western toilet.
As a result of testing our user interface, we included 3D-looking buttons, culturally appropriate symbols, and images to convey what was being done in the app. We also avoided builder jargon and put in a handy dandy question icon on every screen to help the users if they got stuck on what they should do next.
The process
The first app usability test we conducted as part of our weekly testing was a Marvel prototype. Since we were not entirely sure what type of screens our users would prefer and what they would understand from our pictures, we opted for the low fidelity design to gauge understanding.
Once completed we went out to the resettlement colonies and watched how people used the device and the app (did the hold the phone differently? How did they tap the screen? etc.) This initial prototype failed miserably and forced us to reevaluate a lot of our assumptions. Users were frustrated as they tapped on non-functional buttons and asked us to explain what some of the technical terms such as the type of plot a home would be built on (corner plot, center, etc.) and what septic tanks vs. main sewer line, etc. It was eye-opening to observe the reactions of our users to this initial flow.
From this first iteration, we realized that many of the ideas we took for granted such as the location of a plot of land in a city block were not as easy to understand from my illustrations as I’d hoped.
We went back to the drawing board and started the next iteration, placing emphasis on drawings, and realistic pictures (we hadn’t done the user image analysis till after realized how big a problem it would be.)
During our next usability test, we found that while people responded better to the pictures they were also more confused about what some of the pictures meant. For instance, I had put pictures of a western-style toilet rather than a squat toilet which is typically found in India. We quickly realized the importance of culturally appropriate images to convey our questions.
From this testing we went towards a hybrid design. One that combined the elements of words and pictures but in more realistic settings.
Below you can see we did this with a card view. The card overlaid on the background provides a point of interaction for the user while the image that is revealed below is influenced by the user just tapping a button.
Going out and testing this initial design we found that people who were willing to try the app were able to use it easily and could create a home design while also getting the estimate for their related costs.
We created this tool to make something accessible to most users and provide them with the tools they needed to create strong earthquake-resistant homes. With this application, people will be more connected with their housing construction and be able to communicate their designs directly to the banks easier loan approval and tracking.
This design caters to everyone no matter their level of construction knowledge, technical adeptness, or even literacy. By employing detailed pictures and useful animations we refined our design to show the user how to use the device and what to do when they get hung up.
In the end, we were able to design a product users were more comfortable with and could use even without understanding the words. With this new design, the user could see their home being designed in front of them and follow the estimation process to get the estimate. Along with a helper button as part of the UI, they were able to get through the flow to see their final home estimate.
I designed the 3D assets in SketchUp and rendered them using Visualizer, the prototypes we tested were done in Principle and Marvel. All the user interface screen designs were created done in Sketch. For development, the 3D assets and the home would ideally be rendered on the device using Unity.
Another important part of designing apps for emerging markets like India are the hardware limitations. With low-cost data plans like Jio creating a larger app is not as big of an issue for many users, but their low-cost phones (mostly sub $100) have bigger hardware limitations. For instance, rendering this in Unity in real-time would likely be a choppy experience, and pre-rendering all the potential assets would take up a lot of space on a phone that is already too full. To solve this developmental hurdle our plan is to render all assets on the cloud and push to the device as needed so the bandwidth requirement is drastically increased, but on-device app size is much lower.
One of the key lessons I learned during the user analysis and testing phase was that “one size does not fit all.” It’s vital to study the user’s psychology, cultural, educational, language, and familiarity with different devices when designing an app for a range of users.
In the end, we designed an app that could be used by the majority of our users. The team is now in the throes of developing the app.
