Reading this week:
- Kenya: The Struggle for a New Constitutional Order edited by Godwin R. Murunga, Duncan Okello, and Anders Sjögren
I spent the summer at an internship reviewing old grants for development projects. This was a lot more interesting than it sounds!! There were all sorts of grant applications, from all over the world, and grantees provided regular updates on their progress. That meant as I reviewed the old grants I got to see these people face new problems and overcome them (or not).
The major schtick of the place I was interning was that they did innovative ideas. This is the 21st century, so a lot of time “innovation” is synonymous with “cell phone app.” This isn’t exactly crazy; a lot of the reason that development is hard is that development requires interconnectedness between people, and the whole point of cell phones is to make that easier. So I reviewed a number of app grants. Like all the grants, these too were pretty interesting to me mostly because of all the unexpected problems that people ran into.
Before we get too into this, I want to apologize for vague blogging. Seems like a lot of work to get permission to publish people’s processes, so I’m just going to allude to stuff.
The app with perhaps the most lessons learned had to be one that was designed to help with patient follow-up. Right from the outset they wanted to make it usable to the most number of people possible, so they designed it to be used on feature phones, aka dumb phones. This is a good instinct! They worked real hard to make it super accessible. But man were some of their assumptions off.
One of the funniest to me is that they discovered just how limited some people’s phones were. They initially designed it so you had to reply with a text message, like “yes” or “no,” typing that stuff out T9 style. But then they discovered that some people didn’t even have the capability to do that, and had to switch it up so you could just reply with a number, like “1” or “2” (one creative solution to this technology problem was that some people just gave smartphones to their target audience; for one of those developers, the deal was that if you got a smartphone you were supposed to text vital information to people with dumbphones).
Another assumption they made was that people could read. They figured out a lot of their users were in fact illiterate, and had memorized the menu. That was actually the sort of problem I had read about before! I can’t find the original article I read detailing it, but over in India YouTube has become the search engine of choice for many people. Two things made that possible: really cheap data, and voice search. This WSJ article makes voice search (aka voice-to-text into the search box) just sound like a feature they just added for fun, but there is a huge number of illiterate phone users in India. However, these illiterate users can just talk to their phone, and get a video back, which gets around the reading thing (I’m not worried about this as some Black Mirror future scenario, but it kinda plays into this analysis that everyone in Star Wars is functionally illiterate). This pops up all the time in apps and app designers should think about how to make their app usable by the illiterate (Maybe the blind or disabled too? Dream big). Ignitia, which texts weather forecasts to farmers, found that using keywords consistently helps illiterate farmers decipher their forecasts (they text things along the lines of “Heavy rain today. Sun tomorrow.” Farmers can recognize “rain” in the first sentence, and know it will rain today, and that “sun” in the second sentence means no rain tomorrow).
Yet another non-intuitive assumption that designers made is that every phone or phone number corresponded to a particular person. This was a bad assumption! A lot of times a single phone would be shared between several people, such as a group of friends or a family. I didn’t actually discover anyone who came up with an elegant way to solve this problem, but if you’re designing an app make sure that it can be used by several people on the same phone pretty smoothly. And maybe don’t just send a push notification for sensitive information? Yet another company ran into a problem when people’s phone numbers kept changing. They tried to maintain a database of people’s contact information, but people would switch service providers all the time, and therefore switch phone numbers, whenever a different service provided a slightly better deal. The company’s database got out of date really quick, and again I didn’t see them come up with an elegant solution to solve it. Things to keep in mind!
Another thing just from my personal experience using a phone in a rural village in Zambia is that make sure your app doesn’t use a lot of data! Optimize the shit out of that thing! And data access can be spotty! Make sure your app works with only an intermittent connection to data! I have a lot of vague hypothetical thoughts about this, but make sure your app also functions elegantly when it reconnects to data! Don’t have it download out of date stuff just because it was in the queue! And make sure that your app can pick up right where it left off after a failed download, instead of making a large download start over just because data was interrupted for a second!
One solution people have tried to implement to the whole data being expensive thing is to subsidize their user’s data cost. Unless you have the engineering chops of Facebook, this is probably a bad idea. My favorite was one company that had it set up so that their agents were supposed to text them back, and so had provided their agents with prepaid texting plans. Turns out their agents used all their text messages to chat up girls, and when the time came to actually use their text messages for their intended purpose, they had none left. The company had to switch to a different system to avoid having to get their agents to text them, all because they couldn’t resist hitting on women. Men, amiright?
There were more lessons, but they’re hard to convey in a vagueblog. I also think that the best design ideas for development apps are yet to come. There are a whole lot of efforts to leverage the technology, but I don’t know if I’ve seen a “killer app” (or, since it’s for development, “lifesaving app”) for the developing world. That being said, there are a number I like. A few different apps that give users information via a map (like vegetation data) have been good, so maybe better geospatial information could be useful. I also like the simple implementations; one company trains people in first aid, and then loads onto their phones refresher videos so they can review the lessons at any time. Very neat! Maybe excellent avenues to pursue. The deepest lesson however is, like everything else in development, to let your users guide your app. You’ll find they manage to use it for things you didn’t think of, and have suggestions that could make it way better.
One lesson learned I didn’t include above is one company that tried to distribute their app via the Google Play Store, only to find out that 95% percent of attempted downloads couldn’t be completed because the Play Store required people to have an email address, which was very uncommon in the developing country context they were working in. This was literally something like a million potential users who tried to access the app but just couldn’t. It seemed niche so I excluded it from this post, but then today I come across this New York Times article about Seesaw’s experience suddenly being a critical pandemic-era app. The line I wanted to quote here was that “Numerous students didn’t have email addresses and needed a different way to log in from home.” It looks like the assumption that a potential user has an email address or will attempt to get one is a very bad assumption indeed!
You must be logged in to post a comment.