SafeMotos is proud to announce the new version of our smartphone application: what we believe to be the most localized piece of software ever built by an African startup. It’s been a rocky journey though, with many missteps along the way. Our hope is that we can pass on some of the lessons learned at SafeMotos so others can avoid the same pitfalls.
Our story began when I, a Canadian who has now spent more than a decade living in Africa, and my Kenyan co-founder and chief technology officer Peter went to Ireland to take part in a startup accelerator from the Venture Capital (VC) firm SOSv. Focused on global innovations in the transportation industry, we managed to make a minimum viable product (MVP) and secure follow on funding for about a year of runway. We came back to Rwanda, ready to go.
Our product started off very simple when we launched in Kigali, Rwanda in June 2015: let’s take Uber, pair it with motorcycles, shove in some sensor telematic tracking and boom, have a product where we would take a percentage cut from every trip. We pretty much immediately fell flat on our face and so began our journey of understanding consumer behaviour in this region.
We’d made the age-old mistake of making a vitamin instead of a painkiller. While customers ‘liked’ increased safety, they deprioritized it compared to price and convenience. Great! We shifted our thinking from safety as a product to safety as a by-product, with the goal of onboarding as many customers as possible bringing them onto a safer platform. We were heavily influenced by Uber, which led to our next major mistake in not understanding our users. Our assumption was that Uber was this giant company, they have a team of user experience experts, all the other ride hailing companies are (sorry guys!) pretty close to following spot on Uber’s design principles: let’s just do that!
What we hadn’t adequately considered was that we need to build for the real consumers in our markets rather than some ephemeral hypothetical ‘ideal’ user. I personally led more than a hundred hours of user experience testing and right from the get go was humbled to the point of embarrassment.
We thought we knew the African consumer. Peter is Kenyan, I have one of the pre-eminent mental maps of the continent’s drinking holes, our team is all Rwandan, should be easy! We were off by multiple orders of magnitude. So many of those design best practices we borrowed were just glaringly misguided. In the United States or Europe where there is an assumption of evolving technology usage over decades, in Africa for most users a cheap Android smartphone is the first time they have ever used a device that has a processor in it. New African tech consumers are not comparing a smartphone to a Windows XP machine — they are comparing it to a cooking stove or something else they have experience with.
Things like icon packs, an X meaning close, a user flow going from left to right and button identification were all completely against our preconceptions. We simply didn’t realize the extent of our assumptions. The biggest challenge we faced was with users lack of exposure to city maps (global maps are fine), which means when your app is based on a map-based user interface, you’re pretty hooped. Users were thinking they were ordering drivers to the right location when in fact they were asking the driver to go pick them up on the wrong side of the city (or in the middle of the ocean). This challenge was amplified with users on cheap phones with low quality GPS chips and poor satellite coverage.
Here is when we decided to not ‘build to best practices’ but ‘build to the users’. Users don’t know icon metaphors: let’s remove all icons and just have buttons that say exactly what they do. Users don’t know where they are on a map: great, let’s not ask users to find themselves on a map. Let’s only allow them to order if we are 99% confident that their GPS is getting an accurate lock, even if we’re asking the user to lean out a window waving their hand to get a GPS lock.
Things have been going pretty well since then: we can look at our analytic platforms and see less funnel loss and more successful conversions. Our current dream is for the app to be just a big button, something like, “Click here to be picked exactly where you are standing”, though we think that still may not be far enough to understanding local context and believe that we may need to eat our words from years ago and develop a hybrid USSD <> Smartphone option. Understanding users is understanding that even while smartphone usage explodes, things like downloading apps from app stores, registering accounts and having active data connections lag far behind.
We are excited by the fact that there seems to be new design methodologies that can be used to explode adoption of technology and applications in Africa. We are confident that through the Business Call to Action (BCtA), we can connect with other companies on such issues in Africa and beyond and exchange ideas with them. As a relatively young company, we are also keen to get things right from the onset and put the right impact framework in place to assess our contribution to the Sustainable Development Goals. That’s one of the key reason why we joined BCtA. Now, when we use applications like a food ordering platform that makes us go through ten screens and twenty form input items, we just shake our heads: has the developer ever talked to an end user? We think services will be far more rapidly adopted by understanding who the real user is rather than who the company wishes they were.
This article first appeared on Business Call to Action and is reproduced with permission.