Usability Myths Debunked
Usability Myths Debunked |
|
The Managing Director sitting next to me puts his notes on the table and says to the ICT Manager: ‘This is what I want to see on the Intranet. I am looking for a document repository in our new design’
ICT Manager: ‘But there is already a document repository. You just click here and here and there and then select this from the drop-down list. A new application window opens up and then you click here and then there’
MD: ‘I had no idea it was there. I couldn’t find it. Frankly, none of the staff I’ve spoken to knows it is there’
ICT Manager: ‘Well, then they need some training’ I nearly fell off my chair. It is the year 2006 and usability myths like this still exist. If your users can’t find something? Train them into oblivion …’
Usability must be the testing area that is the most misunderstood. This is not because it is rocket science; it is a problem of perceptions. There is an old joke that says the length of a minute depends on which side of the bathroom door you are on. This is so true for software development as well. The ease of use of the system depends on which side of developer’s door you are on. It is just plain and simple logic that if you were the one developing the system from scratch, you know it inside out. If you see the complete system for the first time as a user, you have a totally different perception of it. This is the reason why a lot of ICT people don’t understand why their systems may be unusable to others. This misconception very often leads to myths about usability and usability testing.
I have come across usability myths in the software developing industry that greatly affect the use of systems. Let us look at some of the most common myths:
From my experience in marketing usability to seasoned ICT professionals, I’ve come to realise that many managers are ill informed about usability. Yes, usability does deal with people and yes, some of the usability testing techniques are about getting the user’s opinion of the system. To some people this just sounds way too unscientific to take seriously.
When we do usability testing with users, our aim is to ultimately get qualitative and quantitative data. We do this by measuring the three most important usability parameters: the effectiveness, efficiency and satisfaction criteria. All these things are measurable, for example: number of errors the user makes (influences efficiency), percentage of the task correctly completed (effectiveness) and their rating on a satisfaction scale (satisfaction). By measuring user performance and satisfaction you will quickly see how productivity is affected by usability. If your 10 users take two minutes each to complete a task that could take only 30 seconds (if the design were easier to use), you can see that you are wasting 90 seconds per user per task. If each of them does this task 50 times a day this amounts to 500 tasks. The calculation will look like this:
10 (users) x 90 (seconds) x 50 (number of times task is done per day) = 45,000 seconds, which is 750 minutes or 12.5 hours. Convert these hours into money by taking your staff’s hourly rate into account. If your staff earn an average of R80 an hour, you are losing R1000 a day (about R21,000 a month!). This is real money we are talking about now.
Two of my clients told me last year that they analysed their help desk calls to find out how many calls were usability related problems. The one client found that 29% of his company’s help desk calls were usability-related and the other client said 31%. Let’s for a moment forget about the cost of poor user productivity, and just look at the cost of running a help desk. How much money could be saved if you, by designing your systems for ease of use and intuitiveness, can cut your help desk costs by 30%? If the users can help themselves and make fewer errors, the strain on help desk support and training is reduced.
Myth busted! Usability is in fact measurable and poor usability does affect your pocket.
This is a very counterproductive attitude. Attempting to save time and money during development by not attending to usability is counterproductive: that same time and money (or more) WILL still be spent by the training department. Your company is not saving time nor is it saving money. I’ve been a trainer for a long time. The amount of time that goes into designing, writing and preparing for a training course is frightening! It takes weeks to prepare, and then hours and hours in the classroom still lie ahead. Compare all this to how little time and effort it costs to perform certain usability activities during the development of the software. A few hours of paper prototyping with five users can make a huge difference to how intuitive the design is, and thus to the amount of training the users will eventually need.
Usability implies that users must be able to perform basic tasks without training (here I am not referring to the use of advanced features). Can you imagine if you have to attend an 8 hour training course every time you want to use a new website or a new cell phone? A lot of research and effort goes into web and cell phone usability, so that users can immediately help themselves and use the most basic features. If you want to do more difficult things, you would probably read the manual or look for some form of help. In-house systems and other applications must always be designed this way as well systems must be intuitive so that users need as little (if any) training as possible.
Myth busted! Training does not fix or compensate for poor designs.
I must say, I have heard this one so often and yet I cannot figure it out. Do you think Microsoft® would have been able to ‘rule the world’ with MS Windows® and MS Office® if users were unable to use their products? Remember that their products are used worldwide by users from different cultures, speaking different languages. Microsoft does usability testing on all their software (on the Redmond campus alone they have 25 usability laboratories - http://www.microsoft.com/ usability/lab.mspx ). Enabling and empowering users to use a product is just good business sense. If users can’t use it, they won’t, and they won’t buy it. If it were possible for us to have a peek at Bill Gates’ bank account, I think we would all agree that usability has great value – it is not an optional extra.
Myth busted! Usability is necessary if you are serious about business.
Even though users are used both in UAT (User Acceptance Testing) and in Usability Testing the two are not the same. I think a good starting point is to look at the definitions of both types of testing:
User Acceptance Testing: ‘The type of testing where monitored users determine whether a system meets all their requirements, and will support the business for which it was designed.’
Source: The Free On-line Dictionary of Computing (2003-OCT-10) http://dict.die.netUsability: ‘The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.’
Source: Source: ISO 9241-11From the definitions we can see that UAT focuses on the functionality of the system (what the system can do) and usability focuses on the non-functional aspects of the system (how the system does it). Maybe it can be better understood by looking at the following example: one of the system requirements is that the system should be secure and that users need a log-in screen. During UAT users will check and test that the system does in fact have a log-in screen and that they can log in successfully. However, during usability testing we may find that the users make an average of 5 errors on the log-in screen and it takes them an average of 2 minutes to log in. The functionality is there, but not easy to use. There may be too many fields to fill in, or the password format is too complex, or the password is too long. It is therefore imperative to do both UAT and usability testing because they test different things.
Myth busted! Usability testing tests the HOW of a system and user acceptance testing tests the WHAT of a system.
The more you work with users the more you will see that ordinary users (non-ICT people) want to get the job done as quickly and easily as possible. The real computer-junkies love difficult challenges and get a sense of achievement when they conquer a complex piece of software.
If you get the requirements from your users, build only those requirements into the system. Users are often confused and intimidated by too many complex features. They also do not appreciate searching through many items to find the functionality they need. One of my clients said that they tried to anticipate every single bit of functionality the users might need and build this into the system. It was an amazing feat for the development team (they actually received an award for this project). Unfortunately, after we spent time with the users we realised they were scared of this system due to its size and complexity, and only used three functions in the whole system (with difficulty). It takes a lot of time and money to build complex systems – make sure your users need all of it.
Myth busted! Too many features and unnecessary functionality in a system makes the system expensive to develop and make it difficult for the users to use.
These myths are what I have seen in the South African ICT industry. I thought it might be interesting to see what other people in the world believe the main usability myths are. I found the most comprehensive (and entertaining) list on Dr Theo Mandel’s website (www.theomandel.com). Dr Mandel is involved in the design, usability testing, training and development of all types of web software and applications. On his website he encourages readers to submit their favourite usability myths. The list currently contains some really good ones, and it is clear that these entries are not text book theory, but real life experiences. Here are some of them, followed by my comments in brackets:
(Nos. 1 and 2: I always say that ‘getting used to’ is the enemy of usability. Users get used to doing things in a long and tedious way, but they adapt quickly to a new usable design.)
(I agree that Microsoft® does not always do everything perfectly, but if some of the more familiar Microsoft® layouts and conventions can be used, it improves the learnability of the new product.)
(Nos. 4, 5 and 6: I have seen developers’ reactions – and frustrations – during user testing sessions when users do the opposite to what the developers expected. The developers usually know the system too well to be objective about it. Usability testing almost always shows the developers things they did not expect.)
(If they are talking about usability standards, style guides and design rules, this is actually not a total myth. I’d say that you can achieve about 80% usability in a system by using usability guidelines. The reason for this is that usability guidelines (from trusted sources) are based on actual testing done with users. You are therefore using guidelines that are based on real user behaviour. I always recommend that at least a little bit of user testing is done as well, to get the remaining 20% right. I realise that the ratio here sounds weird as the usability experts will always say that testing with users comes first and is the most important. The reality of the matter is that most clients still do not want to spend that much time and money on usability and therefore opt for the cheaper and quicker method, which is using guidelines.)
(Hmm, who wrote the specification? In most cases the specification is not written by the users. More often than not the users did not give input into the specification. They cannot follow something that may not represent their requirements.)
(It is a bit arrogant to think so. The closest a usability practitioner can get to guarantee the product’s usability is if guidelines were followed AND user testing was done. The combination of the two usually gives the best results.)
(Again not true. Users want to get the job done as quickly and easily as possible with no distractions. A ‘hip and happening’ design often has way too many things like colours, animation and sound effects that can become obstacles. Usability studies with teenagers worldwide proved that even they prefer content to ‘cool’ design. They want the content to be simple, factual and easy to find.)
(And the problem is…? I find that users, to a large extent, allow ICT to take the lead and call the shots, but if something is not part of their own requirements, they need to make changes.)
(No 13 and 14: So not true! A five day expert review is not going to derail a 3 month project. Especially if you consider that the whole project does not grind to a halt while the usability testing is done. The BIG thing to note here is the earlier you have the usability testing done, the less impact it has on the project and the cheaper it is. To make changes, due to problems found during the testing, on a finalised system takes a long time and costs a lot – but we know this is true for functional testing as well.)
(No 15 and 16: Users and ICT people don’t speak the same language. To users terminology like HTML is Greek. So if the developer tells the user: ‘I cannot do it in HTML’, it simply does not mean a thing. If the user tells the developer that the certain ‘thingamajig’ should be moved up next to the ‘goodie’, the developer does not always understand. It is therefore important to have ‘interpreters’ like Business Analysts that can put the users words in writing in a way the developers can understand.)
(Every expert starts out as a novice. Computer literacy just helps certain novices to go through the learning curve a lot quicker. Design the system in such a way that it is simple and easy to use for everyone. Examples are:
(Yeah right! In my experience, if users struggle with something, they first try weird things until they are stuck (or break the system), secondly they ask a colleague for assistance, thirdly they phone helpdesk and lastly they read the manual/help. Unfortunately this does not mean the system should not have a Help file. One of the usability criteria is that the system must provide help if the user wishes to make use of it.)
(I promise you that you will not have time during the next release either…)
It is quite scary that so many myths still exist about usability. I find that the guys who still believe these myths about usability are uninformed. I challenge those that believed even one of the myths mentioned in this article to take 20 minutes and go and watch a user using your product. You will be quite surprised (even horrified) to see how they interpret certain things.
| Quite frankly, usability is not so hard to figure out: | |
|---|---|
Why don’t cars have square steering wheels? Why are cell phones not the same size as land line telephones? Why are golf clubs not 3 meters long? Why do coffee mugs have handles? If you can answer these questions, you know why we need more usable systems. |
 |