Unburdening Phone Menus in Mobile Money

Disruptive innovation typically occurs when market outsiders conceive of a service with a radically simplified user experience, offer it at a much lower total cost, and –crucially— incorporate an order-of-magnitude improvement in one key dimension that really matters to the mass market. It’s a good enough service, with a wow factor. Meanwhile, established players engage in a proliferation of features and pricing plans that only appeal to larger, more sophisticated users, who happen to be the customers they listen to more closely. As Clayton Christensen emphasizes in The Innovator’s Dilemma and subsequent writings, the disruptive service is often so basic that established players don’t even see it as competition, giving it plenty of room to grow – until it’s too late. 

This plot fits perfectly with the development of mobile money, and especially Safaricom’s M-PESA service in Kenya. Mobile money reduces banking services to a bare-bones store of value and means of payment function, and blows away banks in terms of sheer retail footprint.

It is natural and entirely desirable for mobile money players, once established, to seek to improve and broaden their offering, adding features that appeal to their better customers. This comes at the cost of higher product complexity and, eventually, a more expensive service for ordinary users. They become incumbents, opening the possibility of history repeating itself.

On the complexity point, take a look at the M-PESA menu. You can now send money to a phone number (P2P), pay bills (send money to a corporate), buy airtime (where Safaricom itself is the biller), buy goods (pay a store bill on the spot rather than at the end of the month), withdraw cash (pay a store in return for taking cash rather than goods), and send money to your own bank account (M-Shwari or M-KESHO). The only difference between these is who you are sending money to and why. They are use cases around a basic money transfer capability.

Mobile phone user interfaces have tended to productize the use cases: the menu directly exposes a variety of things you can do, such as the above list. It reminds people of what they can do each time they look at the service phone menu, and advertisements for use cases can incorporate a call-to-action linked to a specific item on the menu.

On the other hand, a user interface built around a product logic has the drawback of appearing to customers like each of these use cases is something new and different, needing to be explored and understood separately. Menus first get long, then nested, eventually burying the lesser known use cases. Service categories and names seem increasingly arbitrary and confusing in customers’ minds. Menus need to be updated frequently to fit new services in, disrupting customers’ sense of familiarity with the service. All this can constitute a barrier to customer experimentation: many people will stick to what they know (largely, P2P) and ignore the rest.

An alternative is for the phone menu to expose the basic functions rather than the use cases of the service. Let’s call them send money, get money and view balance. Under send money, to identify the recipient you could enter indistinctly a phone number, a biller or merchant code, an agent code, a bank account number – or you can access a menu of pre-defined destinations (your own bank account number, frequent billers, buying airtime from the operator, etc.) In all cases you are then asked to enter the value of the transaction, and an optional description for the transaction. How the latter is precisely worded might differ based on who you are sending money to: it might say ‘your purpose’ for basic P2P, cash withdrawal, or  transfer to your own bank account; ‘your account number’ for bill payment; ‘for which phone’ for airtime purchase; etc. Having captured these three standards bits of information, the user interface then displays the full intended transaction, including the applicable charge (since different amounts and use cases might incur different charges), and asks the customer to confirm it by typing in his or her PIN.

With this approach, the phone menu remains simple, short and stable. Two steps in the menu protocol are skipped (selecting the service, and confirming the transaction which we have combined with entering the PIN), making transactions faster. Because there is only one send money option and all transaction types work the same way, customers feel they have to learn the mechanics of sending money only once. Different use cases can still be advertised, but they would be promoted as one more reason to send money rather a new service that needs to be discovered and understood separately.

Similarly, the get money function would offer a standard way of getting electronic money from various sources, and could conceivably incorporate a loan feature (i.e. get money from the provider, as with M-Shwari), pulling money from your own bank account, and possibly requesting a cash deposit from the agent (which would achieve electronic rather than offline authentication of the depositor, thereby eliminating the risk of P2P bypass and improving KYC compliance).

When you want to promote many diverse use cases, should you differentiate them into products through the user interface (like an á la carte menu in a restaurant) at the risk of creating overly long menus, or should you consolidate them into a minimum set of distinct functionalities (like in a Swiss army knife) at the risk of not expressing the use cases explicitly? The question is ultimately an empirical one: which one will stimulate more usage? I am not sure what the right answer is, but I do think it’s worth asking. I don’t get the sense that this has been given due attention either by operators (who are merely replicating established formulas) or researchers.

The user interface logic needs to be looked at with a long-term perspective, since mobile money use cases and functionalities can be expected to grow quite substantially, and legacy practices will become more and more of a burden with time and success. (Do you remember when your operating system fit in a floppy disk?) Mobile money operators need to give serious thought to how to future-proof their user interface strategy.

- Ignacio Mas

Ignacio is an independent consultant in mobile money and branchless banking and has previously been  Senior Advisor in the Financial Services for the Poor program at the Bill & Melinda Gates Foundation and at the Technology Program at CGAP. Previously he was Director of Global Business Strategy at Vodafone Group, Executive Vice President of Marketing and Account Management at DoCoMo interTouch, and Senior Manager responsible for telecoms investments in Europe for Intel Capital.

He has undergraduate degrees in maths and economics from MIT and a PhD in economics from Harvard University. He has also been Adjunct Professor at the Booth School of Business at the University of Chicago.