UX Best Practices for Feature Phone Apps
When I started at my current company WorldCover [YC W16], one of the first projects that was proposed to me was creating an “app” for our farmers to make payments and engage with our company. WorldCover provides insurance against drought for farmers in frontier markets, so our customers — smallholder farmers — lack access to the luxury of smartphones many of us take for granted today. In fact even if farmers could afford smartphones, these devices are ill-designed for rural life in rugged remote areas with inconsistent power supply.
Coming from the startup scene in NYC, when I think “phone app,” my first thought is a native iOS or Android app — or maybe a hybrid React Native or a Progressive Web App. But for WorldCover’s customers, who only have feature phones, this meant we needed to utilize an antiquated — though robust — technology called USSD.
In this article, I share the story of our development of this app, some of the constraints associated with USSD technology, and provide tips for how to overcome these constraints to provide great User Experience (UX) for our customers.
What the heck is USSD?
USSD, which stands for Unstructured Supplementary Service Data, is a session-based protocol within the Global System for Mobile Communications (GSM) standard. It has been available on phones alongside SMS and standard voice calling since the earliest mobile phones were available. Its use as an “app” channel came about as an accident. It was originally used as an admin protocol to supplement (per the name) the more person-to-person GSM standards, when someone realized that it could be used to communicate with users.
There is an interesting trend in Africa whereby the continent has only about 40% internet penetration, but 80% of the population has mobile phones. In order to service these customers without having internet access, companies have bridged (basically hacked) USSD to link these mobile phone users to internet services. Today, billions of transactions take place over USSD each month by up to 2 billion users to check their bank balances, top up airtime, provide health information and even to pay their electric bills. It is part of the 5G standard, so the protocol will still be around for at least the next decade or so.
For a deep dive on the history of USSD check out this awesome overview by my friend Wiza Jalakasi.
The Challenges with USSD
Unsurprisingly, when you hack a technology to do something vastly different from its original intended purpose, there can be some issues. For customers, the number one issue is that sessions can time out before they are able to respond or complete the session. A session consists of interactions, colloquially called “hops”. Session times differ for the different telecommunication companies (telcos), but in general a user gets 30 seconds to respond to each hop.
This timeout window generally includes the network transport time to receive the information, so that means customers have about 15–20 seconds to read their screens, fully understand what is being asked, and type a response before the session times out. In addition, the entire session is often capped to about 3–5 minutes, so users need to quickly complete an action or they will need to start over from the beginning. The user experience provided through USSD by telcos is not regulated by government or consumer groups, so the quality of experience can vary widely and these time limits in practice are inconsistently enforced. There is no accountability for the telcos, and apps have been known to time out randomly even if the customer is well within the timeout limits.
The second issue for customers is non-standard billing. For example, in Indonesia where USSD isn’t common, the telcos provide USSD to users for free. On the other hand, in Nigeria some telcos charge customers for every 20 seconds they use the USSD app, even though marginal costs to the provider are effectively null (although the government there is in the process of changing this). Billing is not at all transparent, and it is unclear to customers whether they will be paying for USSD use through reverse billing or if the USSD provider will be paying for the session on their behalf. Sometimes using a news application over USSD is free, but a bank app might charge, even if they are both over the same telco’s network.
As I’m sure you have noticed, there is a pattern here — the telcos provide these services in non-standard ways, which has issues for developers as well. Each telco has different codebases behind their infrastructure, so for example in one country all user responses in the session may be sent concatenated with an asterisk (2*20*300), in another country telcos only send the most recent response (300) and require your application to cache all previous responses.
Services like Africa’s Talking are starting to unite these different telco interfaces behind a common API, but they are just one way of interfacing and is limited to the countries supported by their service. This has been an issue for deployment of our USSD application at WorldCover, which is deployed to Ghana, a country not supported by Africa’s Talking, and needed to be adapted to interface with multiple provider APIs. For startups that are used to building once and deploying everywhere with an API like Twilio or Stripe, this is something to keep in mind when developing a go-to-market strategy for USSD.
Applying Good UX to USSD
Until recently, USSD menus were signed off on by engineers without much consideration for the end user. The structure of menus is rarely optimized or personalized, which can lead to customers having to go through 9–10 steps in order to complete a transaction. These are the main UX constraints I have found developing for USSD, below I will dig into each with some potential solutions:
- Limited Screen Space
- Limited Response Time
- Session Restarts if Not Completed in Time
Limited Screen Space
USSD limits the screen to 160 characters, similar to SMS. This is quite limiting for a designer used to building scrollable apps or mobile websites, where words may be kept to a minimum in order to create a clean and easily digestible UI, but there is no hard cap. As a result, most USSD menus look like this:
We are able to fit maybe 3 or 4 items in a list with about 20 characters for each item. In the above menu we are able to show 2 pieces of information for each policy, which crop the policy covers and how much premium has been deposited toward the premium, Inside a flow we need to show more info and are further limited in the options we can provide:
In this case, we chose to show more items than on the previous menu, but with limited details for each item. As part of our unit testing for this application, we actually check each screen response against the 160 character count.
As a result of this constraint, I have the following tips. You may consider them obvious, but the majority of existing USSD applications do not follow them:
UX Tip 1: Provide Consistent Inputs — Throughout the application flows, always use 1 as the next step in a flow and 0 to move back to the previous flow step.
UX Tip 2: Allow Users to Go Back — In modern applications we take for granted the ability to move backwards and forwards in a UX flow, but that is simply not the case for USSD, and many USSD applications don’t even provide a back function, requiring users to quit and fully restart the flow if they make a mistake. This can be very frustrating for users who have already completed 5 or 6 steps and need to start back from the beginning.
UX Tip 3: Be Ruthless in Cutting Down Information — Do not try to write an essay in the USSD response. For our most data intensive flow, the Check Insurance Policy, we put all the high level summary info on the first screen (sufficient for most customers), and then split additional details across 2 or 3 optional screens for those customers interested in specific drought insurance trigger values. If possible, test directly with your users to see if you are including the most relevant data points or if there are any that are less relevant that you can cut out or move to a further screen in the flow.
Limited Response Time
There is only a small window of time where a user can respond to your application before it times out and closes the session. As a result, it is key to enable users to easily understand and respond to screen options.
UX Tip 4: No Free Form Answers — In our application, we try not to make use of the keypad-to-character capabilities* and generally only have two types of input: number options to select on a menu, or a numeric input for an amount or date.
*One exception is the new customer signup in Uganda, where they have longer timeout windows from the telco
For example, one of our use cases is collecting planting dates from customers. We use this information to determine when the drought contract will start and end. To simplify this and minimize room for error, we split it into month and date screens that each collect a single numeric datapoint and a confirmation screen (in case of mistakes).
Screen 1:
Enter Your Planting Day (1–31):Screen 2:
Enter Your Planting Month (1–12):Screen 3:
You have selected: August 25th. Is that correct?1 — YES2 — NO, Try Again
UX Tip 5: Monitor Flow Drop Off — This is something that is important in any kind of application, understanding where your users drop off, but especially so in USSD because it can surface a UX issue, for example it may require a complex decision that cannot be completed in the allotted time. Users of USSD are fairly patient and will retry actions but if you consistently see drop offs in an area it may indicate that you need to reorganize your information flow (perhaps breaking it up or consolidating excess info) to speed up user navigation.
For our application, we use Mixpanel and track each state in the flow as a separate event. This translates well to their product offering, as we can tie it with customer-specific metadata to segment across our markets and tailor our flows to different types of users. One learning from our dropoff analysis actually applied to the planting date flow shown above. Originally I had designed the Planting Month followed by the Planting Day (as we write our dates in the US), however our users were expecting to see Day first followed by Month (culturally that is how dates are written in Ghana and Kenya), so users were struggling to input properly. We swapped the states and saw an uptick in input success.
Session Restarts on Timeout
One of the most frustrating issues for users is getting 90% through a USSD flow only to receive an error message: ERROR SESSION TIMED OUT. In addition to having only about 15–30 seconds to respond to a USSD screen, telcos often cap the total amount of time allowed in a session to 3–5 minutes. Completing the USSD flow before running out of time, especially for semi-literate users, can be a race to the finish. Luckily, there is a well established practice for executing long flows in a single go, known as long codes.
UX Tip 6: Encourage Long Codes
A common practice for USSD menus is that once they have been developed, they rarely change their structure. If a user knows what menu flow they will be following, for example rather than dialing the USSD code *314# and then selecting menu options 4, then 5 — a user may just dial at once the full code (*314#4*5) to go directly to the end of that flow — hence the long code.
While our application does not allow this functionality for default options as it serves dynamic menus based on user type, we have reserved specific codes for common long flows that can be difficult to complete before timing out.
For example, to enter his/her crop planting date a farmer can skip the flow described above and enter it using the following long code:
*713*4*15*<crop code>*<day>*<month>#In this way, they can skip all intermediary screens asking for information like which crop policy, what day of the month, and what month they planted. After dialing this long code they jump straight to a confirmation menu:
Confirm planting date of 29th August for your Maize cover?Press 1 to confirm.
This cuts the flow from five screens down to just one, allowing users to gather the necessary information, as the session timeout counter only starts after they finish dialing the long code.
Summary
USSD has unique technical constraints compared to modern front-end applications, but by using clever UX principles you can still provide a great experience to your customers. This article only scratches the surface of product design. If you would like to learn more I can dive into advanced USSD tech patterns such as session caching, dynamic menus, event tracking and analytics, unit testing, and more!
Quick Pitch! Did you find this post interesting? If so, our team at WorldCover is hiring a Full-stack Engineer in Amsterdam. We raised our $6M Series A funding in early 2019 and are looking for an engineer to help develop digital insurance products for farmers and enterprises along the agricultural value chain, build up our tech stack and features while helping the lives of millions of farmers across the African continent. Sound good to you? Apply here!
