Showing posts with label usability. Show all posts
Showing posts with label usability. Show all posts

Friday, October 22, 2010

The Curious Case of Buzzing Light

On a long haul international flight, the most boring part besides watching the rerun of movies is standing outside the loo and waiting endlessly for your turn. On a recent trip while I was waiting for my turn, twice or thrice I saw the call attendant light outside the loo blink. Each time the attendant came and asked the person inside if everything was fine, she got a +ve reply and went back. False alarm. It was not as if the call was made by one person. I saw that pattern getting repeated with 3 different people in 2 separate loos. Curiosity took over me as finally my turn came and while the call of the nature happened, I was snooping around to find where the attendant button was. As I accidently spotted the button (yes, I was on the verge of unknowingly pressing it), it dawned upon me why the airhostess was getting called for no reason by person inside the loo. 




Take a look at the picture above. The orange colored button is placed on the left hand side. In the matchbox shaped toilet, as the person sits on the pot, many a times  in that cramped space the person tries to adjust himself in and this is when the button gets accidentally pressed as it’s too close to the arm and tucked away near to the waist level and gets missed completely by the person. It nearly happened with me too as I tried to jostle in the compact loo.

Flawed Product Design  
The above incidence serves as a good example for software & product designers. The intent of placing an emergency call button close to the person is right, but should that be the right position where it needs to be placed? Any call to action features, be it on the web, desktop applications and as my airline loo experience showed me should be placed where it’s visible and convenient for a person to use.  In that loo the button was getting missed and that was the reason it was getting accidentally pressed by people. Perhaps shifting the button a little more to the left could have solved the problem. A) The accidental pressing would have stopped. B) The button would have been more visible and in front of the eye. 

In conclusion, as a designer or a product developer it’s imperative to step into a user’s shoes and iron out these kind of potential usability issues at initial stages of design itself. Getting the product prototype tested by actual users during prototype stage helps in finding problems that are easier and cheaper to fix rather than unearthing it after the product has been released. Involve a usability consultant in the project right from the inception stage as their expertise and usability knowledge can help in shaping up the product as per user expectations and meet defined goals & business objectives.
 

Wednesday, March 31, 2010

Goodbye ABN AMRO


Got bit of sentimental after hearing that ABN AMRO's name would be changed to RBS (Royal bank of Scotland). Perhaps the reason is given the fact that I had been associated with ABN AMRO for the past 9-10 years or so. Not many of my colleagues know this but I was the Information Architect who was part of the design team that had created the the entire ABN AMRO net banking website.  This was way back in 2001 or something. I was working in an IT company in Delhi. We used to deal with ABN Delhi HO. This was my 1st experience of dealing with IA of a full fledged banking application. I remember the workshops that the design team and client used to have at ABN's CP office. We used to do endless rounds of white boarding & card sorting exercises to arrive on user mental models. Of course there were rounds of heated discussions also with the customer during the workshops which used to spice up our thinking process. In one such incidence we were discussing the Online Account Summary flow. The client had a 'banker's view of the same while we felt it won't work and presented end user's view point. It went on for some time. We took a prompt decision. We went down to the branch and randomly selected few users and expressed out point of view to understand what they feel and they agreed with our thinking! Bang on. The discussion was closed. The client team were a bunch of tough nuts but they accepted points when presented with logic & strong rational. When the banking website was launched, we had even created a banking site demo which used to be part of the online application for quite a few years. We had slipped in our names in the demo as account holders and shown lakhs of rupees in fictitious account number. That was the only closest way of demonstrating that we were quite rich! :-) 

When I shifted to Mumbai in 2003 my relation with the bank continued in form of corporate salary account which I got transferred to Pune when I shifted the base here in 2006. I still maintain the account and use the internet banking that I created. I have always loved ABN's services. In my 7 years relationship with the bank,I have only visited my bank once for sign verification else all my transactions have been carried online or through doorstep banking. After nearly 10 years of its online existence, I am glad to see that the core task flows and navigation of the net banking application has not changed at all. It's means a lot as it bears a stamp of users acceptance and seamless interaction & transaction that they have on the site. In fact I was told that the online site was referred as one of the best internet banking applications present in India. 

Now that the bank has been bought over by RBS, I hope the services that I enjoyed earlier would continue to be the same. It's very weird feeling calling my bank RBS now ;-) but hopefully over the period will get used to the new name now. :-)        

Friday, March 05, 2010

Foxed over flux!

I was in two minds about writing this post. This topic had been on my mind for quite some time but I was really dragging on this post. Well some personal experience around this topic last Friday triggered me to put my thoughts across – and of course some help from Sarah Palin!

Couple of the days ago, Sarah Palin called Twitter as ‘little twittering thing’. It was an innocent response to her reference to how speedily things happen on Twitter.  But what came out was the negative connotation rather than an endearing one.

Last week I was discussing an onsite project opportunity with one of the program mangers. Since they work a lot in embedded & desktop apps space, I highlighted them on how they can pitch for technologies like Silverlight & Flex in their projects which are the emerging technologies in RIA (Rich Internet Applications) space.  The Program manager replied ‘oh yeah we are aware of flex…it’s to do with UI skin & design…’. I told him it’s not just about UI skin but more to do with backend technologies which makes the interaction simple. He and his team mate reply ‘ but the flux presentation that you sent in proposal talked about that’. Which presentation I inquired, since I was managing the flex initiatives and I had never sent any prezo. The FLUX prezo – the guy replies. And then it struck me. He was referring to the new capability presentation sent by the usability practice titled: flux. I winced my teeth and politely went on to explain the bizarre branding name that has cropped up couple of months back.

The 1st time I heard about the new branding for usability team I was very surprised. I saw the branding in a team mate’s email signature and this is how it looked.       


The other variation of the branding I saw was like this: flUX which is used in document or as file name of any capability prezo or overview. It didn’t have any tag line along with it. Then I also see it in email credentials like this: flUX – The User Experience Group
 
Branding is a very important exercise and there are various aspects you need to keep in mind before going in for brand christening. Is branding needed for a usability group working in a pure play technology company – I’ll come to that part later but my 1st question to myself and to few peers around was what did flUX – the word meant to them. I was told by the mates who coined the branding that the reason behind using the word flUX is that in metallurgy flux is a chemical cleaning agent that removes oxides from the metal to be joined. Since in UX space we remove the ‘impurities’ related to ‘bad experience’ hence flUX. To add to the touch was the byline ‘flawless user experience’, the ‘fl’ from flUX stands for flawless and ‘UX’ for user experience. Neat. But do people really understand that’s how the term got coined? When put on a ppt or when sent in a document to customer/prospect/internal stake holders – will they understand what flUX means? From my last week experience I don’t think so. Intelligence doesn’t always sell. In colloquial language flux most of the times is used in negative connotation. It means ‘uncertainty’. His mind was in a state of flux over the decision. 8 out of 10 times in spoken language it will be commonly used to express a state of indecisiveness. The remaining 2 times folks in white coats would be using it. The point that I want to make is when it comes to branding, you also need to consider all these aspects, debate it out, research and then proceed. By discussing it internally with 2-3 practice guys or getting the branding feedback done from few external ex- college design friends won’t help in discovering the real issues. A brand name needs to be really thought through; researched and extensive feedback needs to be taken.    

 I know that one of the lessons in branding is also to make your brand stand out, think of uncommon brand names/acronyms, to have a recall value but you need to consider that the brand name unknowingly doesn’t give different context meanings. Also as my flex-flux experience highlighted, the brand shouldn’t get confused with something else, especially in a technology company where the word got confused with a core technology which the company is building capabilities in.  

More than often, you might not be available for any presentation or physically won’t be present when flux branded collateral would be presented or discussed. The luxury of ‘Hi we are from usability practice and our group is named as flux which stands for flawless user experience…” won’t be available. Then what?

Francois gossieaux in his article on customer vs brand advocacy says “most buying decisions happen when your people are not in the room – not part of the conversations that lead to buying decisions. So for them (your company’s marketing team) to be brand advocates is to a certain degree a waste of time. What you need is for your customers and prospects to be your brand advocates.” And this is where the 2nd important point of my whole take on branding comes in.

Should branding be done for usability team or the services that they pitch? Your customers be it internal stakeholders or external one will not recall your group brand name when they need your services. When there is a need for UI design/evaluation etc, do you think the question that will pop up in their mind would be “hey we need to call flux guys in for this”? No. Don’t be under any illusion. For your internal stakeholders, you will always be known as the ‘usability team’, ‘UI team’ , ‘UI guys’ – irrespective of any fancy name that you coin. When the call would come, the top of the mind recall would be usability, UI design, html developer and NOT flux. Similarly for external customers flux will not make any sense. They would be approaching ‘the company‘for certain services which may or may not be aligned to UI/design and not flux. Even if you send them capability branded doc all pasted with flux – their final call of action would be with ‘the company’ and NOT the branded group. Don’t expect the customer to call the company and say “ I need the flux team services for my website revamp”.

Brands need to be created in usability but these should be around the services that you offer. Create brands around your specialized offerings. Let these be the talking point amongst your internal stakeholders and customers. Your well executed work itself becomes a brand within the organization and has a better recall value for the employee and the group than any fancy brand names. Create brands around your resources who come with niche skills.  Their skills and knowledge in the specialized area would indirectly reflect upon company’s capabilities and your practice and help in getting business.

To sum up this branding discussion, signing off with a testimonial that one of the UX person recently received from an internal stakeholder.  Notice the highlighted part.

“…... Minor details on the portal in terms of graphic representation was taken care of well by co-ordinating with others in the UE (Flux?) team…”

The question mark still remains.

Tuesday, March 11, 2008

Washing Machine Usability

The studio apt. where I live in, has this 'fully loaded' washing machine that can do anything and everything you can think of related with washing clothes. You might ask - what's the big deal in washing clothes? All you need is a soap, water and - clothes! But then this machine comes with all those modes of washing different types of clothes (silk, cotton, polyster,etc) at different settings, various wash modes (depending upon how soiled is your clothes), water modes (to conserve water & use it effectively), various RPMs for various wash types..blah blah. Ok, so I was impressed. But now comes the big question - how should I operate it.
Unlike the previous generation washing machines, which just had 2 knobs to select timer and drain water - here was a machine that had a 'mini instrument' panel full of small buttons & various flashing LEDs.


I took out the Instructional Manual and started reading it carefully. 15 mins of 'chatofying' the book and and I still couldn't figure from where do I have to operate the water tap! I checked the washing machine and couldn't figure the point from water pipe had to be plugged in or the draining pipe outlet. Finally I figured out that the water inlet & outlet pipes were already attached to the machine - though there was no 'knob' to turn it on/off. Ok, so this is Uk and perhaps here machines are already attached to the water outlets but shouldn't the manual have instructions for 1st timer users about these things or is it just assumed that people might be knowing about it. What if a person moves into a new house and wants to install the machine? How will he know about these things? The manual should have had instructions about plumbing or how the machine has to be installed -right to details of fixing it to water/drainage outlet. This way, I would have come to know that there is no need to seat about the water outlet. Anyway, this was just the begining. The next part, selecting which clothes type. There were pre-defined clothes type and I selected 'cottons'. The instructional manual was well documented in the remaining steps and after 5-6 steps, I selected the START button and voila - the machine started! But hey, hang on! What's this? For my 'cottons' selection & even wich 'quick wash' option selection, the machine calcuated that it will take 2hrs 45 mins to wash my 9 shirts!!! Quickly I checked the manual. I did not wanted to waste 3 hrs in washing some stupid 9 shirts. The process had started and I realised that if I cancel any pre-defined programme, I have to start the process all over again with the already 'pre-defined' wash modes.


Why couldn't the machine come with a 'customised' wash mode option too? An option where I even select wash time period instead of letting the machine doing it for me. What I felt really missing from the machine was the option of letting the user to customise his washing choice as per his preference. Comparatively, I felt the 1st generation (manual/semi automatic) washing machine was much easier to use (you don't need manual to use those 2 knobs of setting timer & draining water). Ofcourse once you get a hang of a fully automatic loaded gizmo like the one I used, you do start liking it but is it really helping me in any way to make my washing more effective than the 1st gen machines. Those in favor might say that you don't have to worry about anything - put the clothes in and do your other work and come back only to dry clothes but what about the electricity consumption? I spent 3 hrs of electricity (and water) to wash 9 shirts which I could have done in less than 40 mins in semi-automatic washing machine.


Its good that you have a product that promises to 'automate' or ease out the way you have been performing certain tasks but shouldn't we let the user take control of the product instead of the other way around?

Tuesday, October 09, 2007

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.

Monday, October 08, 2007

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.

Monday, October 01, 2007

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.