November 19, 2014 by Lisa Kienzle
Participants at the GSMA conference experimented with paper protoypes of mobile services they would offer to low-income users
When mobile money launched several years ago, most services, no matter the market or operator, looked strikingly similar – they focused on safe, fast, and secure payments. It was an undifferentiated product for an un-segmented market; being first to launch was an advantage. However, the market that’s easiest to attract (the urban and peri-urban upper and middle class) is nearly saturated. The new frontier is more rural, less educated, and less technologically literate. Today we need nuanced products to address a segmented market that represents a different set of user needs.
Recently, there’s been increased energy and interest in designing mobile money for the end-user, with CGAP launching a product design program and world-class firms like IDEO and Frog focusing on mobile and the poor. Intuitively, few people dispute the benefit of putting the user at the center; yet practically, when it comes time to design a service, sometimes operators balk. There is a concern that testing is too expensive, takes too long, and requires expert resources. Quite often, operators want to get something out fast and first.
Slowly, those misconceptions are changing. At the GSMA’s Connected Women forum held recently in Cape Town, South Africa, Airtel Uganda Business Development manager Stephen Waiswa told the audience, “You have to cook with the people you are going to eat with.”
Waiswa, along with two other panelists from SEWA and Tigo Tanzania, shared their experiences engaging with the user to debunk some of these myths.
Myth #1: User testing costs too much. Panelists agree; testing can be cheap. Waiswa recounted how he used inexpensive paper prototypes to collect feedback before sending the product specification to the technology vendor. That process, which took just a couple of hours, uncovered key structural issues with the original design—and saved several weeks and thousands of dollars of technical development that would have been hard to change later.
Myth #2: Small samples can’t yield useful information. Kristen Waeber from Tigo in Tanzania noted that large surveys are not required for understanding user needs – working with just a few extreme cases provides invaluable feedback. If a user with low literacy and little familiarity with mobile money can use a product, then the broader segment likely will too.
Myth #3: Users want a product now, and testing takes too long to get it launched. Too often we see services with flaws because in the rush to launch, problems were unaddressed. Fixing issues after a service is live is difficult—users are burnt by a poor experience and operators have moved on to the next development. Taking a few extra weeks to test and iterate gets you closer to what users want before you launch it; this means uptake is faster. As Rushi Laheri from Self-Employed Women’s Association (SEWA) noted, “because we tested the product, implementation was easy.”
Saying testing is easy is one thing; doing it is another. After the panelists shared their stories, we put the audience to work on creating their own paper prototypes for some of the services described by panelists. They spent 25 minutes defining the product and developing paper menus (with the help of pre-printed blank phone prototypes) and then tested their handiwork on another group.
The groups then discussed how the process forced them address a few questions. One participant said it was challenging to decide which features to include in the initial design and which ones they might want to offer over the long-term. This tension underscored the value of testing in helping to identify what users most want.
Others admitted that the feature phone interface presented a constraint —they wanted to include a lot of information, but the process showed them that too many menus and options could be challenging to the user. The group discussed different choices that could be made to manage this constraint, such as offering printed handouts to supplement the information that is provided on the screen.
Testing is more than just a way to define a product menu—it helps development teams prioritize product needs and features and balance short and long-term strategic concerns based on what users need. The exercise showed that testing doesn’t have to be lengthy, expensive, or require technical experts—in less than half an hour all of our groups had a product to put in front of their peers to get fast feedback.