My recent experience with user research

For the past few weeks I have been involved in a very low key, exciting project. Why low key, coz except for 2-3 people, no one in our Usability & Elearning team really know what I am doing and exciting coz it involves near about full life cycle activities of 'user centered design'. Our Elearning group is developing an assessment module for dealership sales team of India's largest automotive group. For this project, we have been doing extensive usability activities right from the word go. For a change, the customer here itself have been harping on getting a usability person on board who will oversee that the deliverables meet user expectations. Its more of a participatory design process that we are following. At every stage of the design, user is actually kept in the picture. Constant feedback is taken from end users & all design & interaction feedback are incorporated. Its the users who are evolving the design.

The process started couple of weeks back when me & 2 of my elearning team members went to conduct contextual inquiry at the dealer's location. We spent time in the dealership, observing the sales team at their work, noting down their routine, way they handle queries, the kind of queries they face, the various aids & enablers that they bank on, etc. We also spent time individually with each sales person gathering their understanding & views. The focus of this session was to gather insights that would go into making of this assessment module. Contextual Inquiry can at times throw up really wonderful insights. For instance, we were told that most of the TA for this eleraning module are matric pass and are very poor with english. When they come for any company sponsored training, the evaluator had to personally 'interpret' the question form to sales guys and let them know where they had to tick. In our CI exercise we came to know that not many of these guys are too conversant with computers outside their work domain. So how do you design an interface for a guy who has never spent time on computers? Will he adapt to mouse or keyboard interaction? What will be his learning curve? These were some of the challenges that propped up But these were still fine, what came next was really unexpected. During interviews, we popped the idea of localization and many users readily accepted that localization of content would definitely help but then we came across a user who though was not so good with english still said that he would opt for the language in any kind of test. On further pressing he hesitantly shared that in the 'class' where he belongs, 'knowing' english is seen as a step to move up in the ranks. More soever, speaking in english, or for that matter even attempting questions gives him some kind of confidence inside. So it has more to do with socio conditions around him that motivates him to 'attempt' in english irrespective of his knowing that he can fail in the test. Imagine, there can be thousands of users across the country with views like this user. So another design & content challenge for us. How do you define what is 'simple english'? Something so simple that it conveys the message & users understand it immediately. Later during design stage we realised that to make it quite simple to understand, we need to make it short n snappy and at times grammatically incorrect!

Last week we were in user's environment again, this time conducting usability testing of our designs & key interactions with users. We even video graphed the entire user 's interaction with the screen to capture where his mouse movements went, how he interacted with many of these features, etc. These video shoots helped us in analyzing many of these user's 'comfort' pattern with the mouse & keyboard too. Of course besides video analysis, me & my team was involved in f-2-f interactions too. There were many valid design suggestions made by the users too.

Yesterday I was back in the field again, this time to test semantics of some icons for the application with the end users. At times we tend to 'assume' that a particular icon would convey the desired meaning. The icons that we wanted to test was for Timing meter & audio option. While the timing meter which we felt would work, did work with the users, for the audio option , we got interesting feedback for some icons which normally we would have assumed that it will work.

For instance:



A user thought that this icon stood for Shouting Loud.


For this icon, a user felt that it meant that Talking can be a nuisance to others, while another user felt it meant a horn button but an indication to wake the next person, push him!


The best was this:


User view: Loud talking can be injurious to ears!

I won't share what did work with them coz that would be violating the copyright clauses but this exercise reinforced my belief that why for each & every design step its important to keep users in picture.

Personally this whole project has been very stimulating & enriching for me. We are closing in on product rollout soon & would love to see how users across India receive it.

Designers: Does this ring any bell?

Recently my wife & I were scouting for electrical fittings & accessories for our new house. After purchasing most of the stuff, we got into an argument over which bell to buy. She fancied instrument which had Bollywood tones as ring while I wanted to settle for old fashioned bells which had high, if not shrill ring. For me the ‘ting tong’ bell worked. We finally went for the Bollywood one and got it installed. It’s been a week now and we all are still struggling to get a hang of it. First of all, it takes more than a few seconds for the mind to register that it’s our door bell which is ringing! The reason being, it sounds more like a mobile ring tone than a bell. Worse, the instrument is located in my bedroom & if we are standing in guest bedroom balcony and there is lots of noise around, at times it takes more than a few push & “laila-o-laila’ encore before anyone can get to hear it! The other day I had to spend 5 mins outside the house ringing the bell and then flash out my mobile and call wifey inside to open the door! I suspect had it been the old fashioned bell, the sound wouldn’t have caused these problems. Somewhere in back of mind, the bell still stands for ‘ting tong’. A sound like that registers immediately in your mind no matter in which corner of the house you are and perhaps the reason lies in the fact that we have grown up listening to bells which had high pitch noise. Bells which most of the times had always gone ‘ting tong’ and less on ‘gayatri mantra’ tones.

Similarly in software design, it’s very important to know about your user’s mental model, about the way they perceive things to be. Users will take on to your product like a duck to the water only if they find it designed the way that mirrors their work & thought flow pattern.

Bringing simplicity in interfaces

The most intuitive interface ever designed is the human nipple.

I came across this statement while I was researching on some topic and ever since, it has just stuck in my mind. Come to think of it, how true it stands in its meaning. If you have ever observed a lactating mother feeding her baby, see how the baby’s tiny mouth opens up as the nipple comes near. The baby will stare blankly at faces but recognizes the feeding point immediately. And for babies of adult kind, they don’t need any intuitive visual cues!

That’s the power of simplicity. And it’s this simplicity that creates a brand out of an intuitive design. Oliver Reichenstein from Information Architect Inc. in one of his post on his blog talks about his McDonalds experience in Japan. Out of plethora of options available on the display tile, he settles for a plain Cheese Burger. Not that he has a fascination for it, but according to him, the visual of cheese burger is something he can relate to easily out of all other ‘local palate’ suited burgers. Walk into any McDonalds around the world, a plain cheese burger would look exactly the same way. When an interface becomes so simple, language or any other cultural barriers hold no fort. So when he has to place an order, not knowing Japanese language doesn’t matter to him. The visual of plain cheese burger is an instant recognition for him about the burger’s content.

Simplicity leads to intuitiveness and intuitiveness leads to creation of a brand. A brand that doesn’t always need the support of marketing for its creation. A brand that gets created by its own virtues.

In the Indian context, one of the brands which have a very intuitive interface I can think of is the erstwhile Mother Dairy logo. Since its inception till recent years, they had adapted the Operation Flood logo. The operation Flood logo is the most powerful & yet simple design that I can think of. It’s just not about logo design but the recognition that comes with the brand. Mother dairy has been around since I opened my eyes for the 1st time. No Delhiite can ever say that they don’t know what the logo stands for. In the early 80s, there was no concept of milk in poly pack. If you were living in Delhi and wanted milk, you had 3 options. A) The good ol’ Tabela milk delivered by the vendor. B) Go to the nearest Delhi Milk Scheme (DMS) booth and get bottled milk – which was again run by sarkaari karamcharis and somehow used to be a nightmarish experience and C) Go to Mother Dairy Booth. Now these Mother dairy booths were quite ‘hi tech’. They had automatic vending machines (yeah for the 80s…that’s hitech). You pay money to the booth guy, get tokens in lieu of the cash, place your diiba in the vending machine, put your coin in the slot and watch in fascination as half litre milk poured. If the coin used to get stuck, there was a lever which you had to pull and the coin used to come out in a slot below. There were 3 such machines in a booth. 2 machines used to pour half litre milk per token and the 3rd one used to pour 1 litre per token. So it kind of bifurcated people accordingly. Its been over 20 years now. Lot of cosmetic changes has come across the booth. Now it even sells Safal & other Mother Dairy products but the front end of the vending machine still has the same interface except few minor changes like addition of a LCD display to show how many tokens you have deposited in the machine (in the latest machines, you can insert all tokens one after another and then wait as milk starts pouring automatically). For more than 20 years the same interface has worked successfully and the only reason it has worked is because of its simplicity.

In the software context, the most complex task is to bring about simplicity in interfaces. As a designer at times we try to bring about lot of interactivities, marry technology components, bring widgets, thinking that this will bring around simplicity for user’s task but unknowingly we add complexity to the visual & interaction design. All these are just enablers. Focus on basics. Ask the question: Is your interface helping your user fulfill his key tasks without making him take support from other external factors to complete the task? In organizations where usability & processes related to it are still struggling to find a place user the sun, most of the time designers & usability analysts have to work with their hands tied. Lot of these ‘user research’ activities are left to ‘client knows the best’ and requirements come in some fancy documents to the designer. It’s a humungous job changing mindsets in the organization. Well after all Rome wasn’t built in a day so understandably, it will be time before usability processes gets implemented & awareness fully dawns within organization. Till that happens this is what I usually advice to designers when they get a voluminous BRD, HLD or any other fancy document in their hand. Don’t directly jump onto the design conceptualization. Scan through those documents, take a piece of paper, draw three columns on it and jot down the following things in the columns – various user roles, the tasks that each role can perform and finally in the 3rd column jot down according to “you” the steps that a user would need to perform to complete each task. Many times these requirement documents can be misleading & at times even designers tend to stick to it or get influenced by it. But even if we manage to crystallize these three things, rest follows. In 2001 while I was designing the Information Architecture for an online banking application, I came across a business analyst who was not willing to buy the flow that I had designed for the application. His wafer thin argument: the customer has asked us to design it in the way he wants and that’s how we have documented it! In next client meeting I accompanied him to client’s office to hear out their rationale. Then I drew out these 3 columns on their whiteboard with the details that I felt and explained my flow in that context. The customer was partially convinced but somehow his ‘ego’ didn’t allow him to accept the flow (that was 2001, usability was something unheard and customers especially Indian ones still thought they knew everything!). So I did the next best thing. I dragged both of them to the bank branch which was on ground floor and in their presence asked some of the bank customers questions which were in context with my proposed flow. Their replies vindicated my flow & made a few faces around go red. The customer had to accept that the flow that we had designed was indeed ‘user led’. Later, we even tested out prototype of the application with end users and worked on few teething problems that customers would face. When the application was launched, users accepted it wholeheartedly. It was profiled for its simplicity & ease of use in various tech magazines. Circa 2007. Except for a few security related changes, the netbanking application is still running the way we had designed it and is ranked amongst the best internet banking sites in India.

To conclude, just stick to basics. Remember, the mother dairy customer’s need was only milk and that’s what he got in that vending machine interface. 1 slot to put the token, 1 lever to retrieve the token and a clearly visible big compartment where he can put his jar for the milk to pour.