As a designer, the last thing you want to hear after working on userflows, wireframes, mockups and interfaces is that the users “don’t quite get it”. And yet, these are the “failures” that force you to take a step back and rethink your basic assumptions. I’ll be talking about one such failure we encountered while testing an app recently, and why it was an eye-opening experience.

But first, a quick primer about the app in question:

We were tasked with designing and developing an app that allowed the client to send work-orders to a network of rural carpenters in South India. They could choose to take up the job, and keep the client up to date with the progress (by sending photos etc.) thereby reducing the workload on the client reps in the field. The app needed to go out with two language options (English and Tamil) to start with, and the client planned to test it with a small group of carpenters to see how viable the solution was. The catch, was that most of these carpenters (our prospective users) had never used a smartphone (they were still using dumbphones), and the ones who did use a smartphone only used it to make calls, and send + receive messages using SMS and WhatsApp. The carpenters without smartphones were provided one for testing.

We thought this offered a wonderful opportunity to try out a “chat-like interface” or a conversational UI to communicate with the workers as messaging seemed to be a common factor between both types of users. The fundamental interaction would imitate the way phone users choose services like internet data packs, ringtones etc. with their service providers in India:

3G data options
A sample interaction most Indians are familiar with

Although the interaction imitated an automated backend, there was a human monitoring the conversations, which allowed the carpenter and the client rep to converse when necessary.

App wireframes
Wireframes showing the conversational UI used by carpenters to take work-orders and even negotiate

Yup, we were pretty excited, and after developing the test build of the app (in record time I might add, we ❤ our devs!), we handed it over to the client for testing. Now here comes the kicker — we get reports that the carpenters “don’t quite get it”.

Facepalm
Ouch.

We thought we’d kept the experience simple and familiar, but learned that there was a vital aspect of the interaction we hadn’t taken into account.

You see, when the carpenters got a prompt to “enter 1 for yes or 0 for no”, they ignored the text field at the bottom completely. Instead, they navigated to a screen they were familiar with for such interactions…

Yes, the dialer app. Puzzled? Don’t be. Because dear reader, I have a confession to make — I haven’t been entirely honest with you. I misled you on a key detail when talking about the automated SMS interface earlier. You see, most carpenters didn’t use a smartphone to choose their ringtones or their data packs. They used one of these:

Dumbphone
The veritable dumbphone

Therefore, when faced with the numeric options, they did what was logical — give input through the dialer, which is how they did it in the dumbphones. We were the ones who should have been more careful about our assumptions. This was a wake-up call for us and we learned that we need to review every interaction we had taken granted in the app.

Smartphones are getting cheaper and proliferating all levels of society (especially in India). These are tools for users like the carpenters, not toys, and they will probably not have the luxury of learning it’s UX language in a laid back manner (like many of us did). We’ll need to keep this in mind when designing for them. And we look forward to more “failures” like these to understand them better in the coming months.

P.S. For those interested, we’re currently testing a version with selectable options when numeric input is necessary.

Leave a Reply

Your email address will not be published. Required fields are marked *