When You Can’t Rely Upon Intuition

Over the course of my research, I tested various common design patterns with people who belong to the Next Billion demographic. As promised, I’ll be sharing my key learnings through a series of blog posts. Subscribe to stay updated.


Since I began my research on designing for the Next Billion demographic, I have spoken to a lot of Uber drivers. They offered the easiest way to learn from those who had just come online for the first time ever. And with Uber India hiring a lot of drivers rapidly, I would often find myself speaking with someone who had joined in the very recent past.

There is one conversation that stood out to me: a driver who was on his first day at the job. He told me how he’d be struggling with his device, and that he didn’t get any money for the ride prior to mine. He believes he might have erroneously cancelled the ride instead of ending it, though he was yet to speak with Uber’s support team to get an answer for it.

https://www.youtube.com/watch?v=GWX9UoJbbJw

As we reached the destination, he asked me to help him end the ride properly. The experience is similar to the gif on the left: the driver needs to swipe across a red button. He managed to do that fairly easily.

It’s now that I noticed something really interesting. My profile was shown to him and he was asked to rate me. Instead of simply tapping on the 5th unfilled star, he swiped across the stars. He had to do this a few times since the phone would randomly select a particular star as his “tap”. He then again swiped across the confirm button.

The driver had quite clearly gone through a training provided to all new Uber drivers. Yet he had simply learnt to swipe across rectangular buttons (and stars as well) when he’s required to provide an input. He couldn’t differentiate between the differences in affordances between the “Slide to End Trip” and the confirm button — that is the word “slide”, the arrows icon pointing to the right and the animation across the text.

The first is easy to explain, since he probably struggled to read English. The second and third together are great example of minimalism potentially failing to work across cultures and situations. In bright sunlight, it could have been difficult to detect the animation at all, and the icon might not have stood out to him.

Moreover, by avoiding the more “standard” slide widgets, even more experienced users wouldn’t find Uber’s slide pattern intuitive. A better alternative can be seen in this prototype by Dhruv Saxena: simply providing a specific handle to hold and slide, the design becomes significantly more usable.

What likely happened during the course of the training was that drivers were explicitly, in detail, taught how to end a ride. The gesture needed to be taught specifically, since gestures aren’t often natural to even experienced users. However, the taps on the screen might not have been given much attention. He saw a rectangle, remembered the one from the previous screen, and thought he needs to swipe across this one as well.


There were a couple of key takeaways for me from this experience. The first is if your product is being used by the Next Billion demographic, you must simply accept that they’re going to need more explicit affordances than normal. To test this hypothesis, I created various prototypes of the Android lockscreen.

The current standard one, which is on the left, was often a struggle for those who were holding a smartphone for the first time. This is understandable: they had simply never performed a drag gesture in their lives. The lock icon at the bottom itself is so minimal that they couldn’t figure out how to start.

What seemed to work better was a prototype that actually resembled the Android lockscreen from the Gingerbread days. The reason: it had a more explicit lock icon that they would quickly grab.

The challenge some of us might face is managing two very different sets of users with the same app. This is where the second takeaway comes in: the importance that must be paid to training your users over a period of time.

Note: by training I do not mean a gallery on the first launch illustrating your features of overlays that indicate all the key buttons that are present on a particular screen. Users tend to often jump through these and you are expecting them to commit these quick learnings to memory.

There’s a fairly popular saying in the design circles: “A UI is like a joke — if you have to explain it, it wasn’t that good.” Fact is, even the best comedians of all time had people who didn’t “get” their jokes. Intuitiveness in your application must be built over a period of time, and aiding this learning is a key design task.

Some of the more basic things to help tackle this problem are the more standard empty state screens and tooltips with indicators to highlight key actions. Something I’m more excited about is Progressive Reduction, a concept in which a product’s design offers more explicit affordances at first, and becomes more minimal as it is used more.

If these dynamic changes feel complicated at first, you can start with having multiple designs of the same experiences that target different user groups. Using practices like feature toggles, you could bucket different users into different groups and give them a more targeted experience. Implementing Progressive Reduction could then be done by simply moving users from one bucket to another on the server-side. Firebase’s Remote Config tool could make that easier to implement.


One of my major goals in 2017 is to help products being built specifically for the Next Billion demographic. If you’d like to chat about it, feel free to E-mail or DM me on Twitter directly.