Usability

Usability as a quality

Utility (usefulness)

The most basic but sometimes overlooked aspect of usability is whether the product is any use to anyone. More specifically, understanding why someone would use the product can help predict what factors will lead to the optimum usability; sometimes being harder to use is OK if access to the functionality is more immediate. A good example of where utility is more important than other commonly considered usability factors is text messaging on mobile phones; the utility of sending cheap, informal, asynchronous text messages between mobile phones overrode the difficulty of typing text on a phone number pad. Phones with keyboards are larger and people like small phones, so text messaging remains bound to number pads. Many people have developed extraordinary text-messaging dexterity to overcome the inherent efficiency limitation and access the inherent utility.

The utility of the product or service is the engine behind many usability effects; if your service or product has low utility, small problems when using the system lead to quick rejections. If your service or product has very high utility, people will suffer more pain to use it, but equally will experience more frustration when usability problems get in their way. The utility is like an amplifier for the other usability aspects.

Safety

After utility the most basic usability consideration is the risks to the safety of people, systems, property and environment as a result of the use of the product. This area is widely covered by domain of Health & Safety and Ergonomics so will not be covered here - there will be other articles describing this domain.

The equivalent to safety for computer systems is often legal considerations and data safety. Computer systems can be secure and predictable but their human operators have less rigorous characteristics so thinking about the human-and-computer as a system is important when trying to achieve a 'safe' service.

Effectiveness

The core of usability is whether the right people can achieve the desired tasks.  Sometimes this is the most important usability aspect for a system - for example in financial or other process-driven situations where the costs of failures are high. Aspects of effectiveness include:

• Completion - what percentage of people complete tasks successfully without extra help?
• Completeness - of the data created, how complete is it and how much uncertainty or omission is there?
  
• Accuracy - of the data created, how accurate is it or how many errors does it contain?
  
• Failure - what percentage of user completed tasks are actually incomplete and will require remedial action or cannot be fixed?

Efficiency

After effectiveness, the next factor to consider is the efficiency of getting the task done - how much time and effort is involved. For some systems where time is money or volumes of transactions are high, efficiency is the main driver; it might not matter so much if people don't love the software program, as long as they can complete a task in under 20 seconds.  Aspects of efficiency include:

• Task time - how long to complete a task or tasks (on first use? on second use? on n-th use?)
  
• Learn-ability - how long does it take for someone to make the thing work? How long until they become expert?
  
• Slips and trips - how much manual error is there in operation?
• Errors - how many operational errors occur (user error and system error)?
• Confidence/uncertainty - how much ineffective time do people spend while they wonder what to do next?

Efficiency can effect the satisfaction and pleasure people experience using the system - perhaps getting that flight booked in 3 mins makes the travel website a joy to use. In other cases efficiency might not be a consideration at all - perhaps a business wants people to spend a long time in their shop or online store, browsing the products (think of a book store with a coffee shop inside; come in, sit down, find lots of things you like). Many online marketing tools aim to provide experiences that engage people for longer.  Some aspects (error rates) will always be important, but whether time-efficiency is critical or unimportant depends on the situation.

Satisfaction

Satisfaction is the subjective response people have to using the product or service. Put negatively, it is the amount of frustration people experience. Because satisfaction is subjective it is prone to the wild variation of personality and context. Satisfaction is often the usability people talk about when they say they had a good or bad usability experience, but separating satisfaction from the lower order factors which affect it can sometimes be difficult. A simple way to separate satisfaction is just to say that satisfaction is the subjective rating while effectiveness and efficiency are both objectively measurable. This helps when measuring but not so much when considering a particular design. It might help to think of satisfaction as a direct effect of cognitive effort required to operate the product or service. Too much effort can make people experience discomfort, too little effort is boring or slows people down, and other factors such as colours or cultural issues can add to the attention the product draws from the user.  There are myriad factors which can affect satisfaction and the effects can vary in different contexts; for example something which takes a while to complete but is easy to understand on first use could be satisfying (e.g. a computer operating system upgrade) or frustrating (a banking account service request when the customer is on the phone at the same time).

Frustration can occur in different ways - from poor effectiveness, low efficiency, faults in the product or service etc. The situation affects how frustrating a particular event is; for example a delay in a shoe shop before you are served is more frustrating than the same delay while the assistant fetches your chosen shoe in your size. The same pattern occurs in other situations - the frustration time for a menu to appear when you press is a button is much shorter than when you open a new web page. Being asked for personal information at the start of a survey is more uncomfortable than being asked for it at the end of the survey. So it is possible to include the same delays and inconveniences in different places and achieve dramatically different satisfaction ratings.

Joy

Beyond just standard satisfaction lies much more vague and unreliable aspects termed here as 'joy'.  This aspect is also described by 'pleasure-ability' and more recently 'flow'.  Satisfaction tends to be characterised by indicators such as I-found-it-useful and I-found-it-easy, whereas some products attempt (or need) to provide an emotionally happy experience of some sort. The author is not expert in the field of pleasure-ability or flow so the description here can only indicate that at the top of the usability issue list is something much more intangible. In time it could be expected that the aspect of pleasure has as much background research, categorisation and practice as usability does today.

Flow is a current favourite aspect, and is characterised by control without awareness; you are so in tune with the product that the effort to operate it in the ways you want to become perceptually silent. Flow can also involve being lost in the moment and temporarily losing self-awareness while you become the task.

It is relatively easy to retrospectively recognise something which is successful in providing joy or flow, but the factors that produce joy tend to be ephemeral and heavily contextual; what worked before might not work again, and what worked for one application might not transfer to another. Joy can be sometimes correlate with uniqueness, so it defeats the purpose to copy your competitor.

Knowing which usability you need

Hopefully the above descriptions have made it clear that asking for "good usability" is just the start of the request - it takes some thought or information to define what a product or service needs to achieve.

Once these different manifestations of usability performance and problems are known in just a little more detail it is then relatively easy to understand what the priorities for any particular situation need to be. If you can resist the temptation to say "we need all of the above" then you can provide a focus and direction for usability goals. This doesn't mean that if you prioritise effectiveness that satisfaction gets ignored; it just means that the measures and designs that are used will have a stronger and more appropriate direction.  It is impossible to generalise so a few examples might help:

• Online banking needs to be effective first (to successfully reduce branch costs) and satisfying second (to encourage greater use) while efficiency is not so important (there is essentially unlimited time for each user session because they are independent)
• An aeroplane cockpit needs to be safe first (to prevent unintentional operation) and effective second (to convey correct information and not miss important information) - and a host of specific issues such as error rates, conventions, lighting...
• An online photo gallery needs to be satisfying (or joyous) first (to compete against the competition) and part of this will be related to the efficiency with which people can access the functions. Having some extra utility that others don't will help compete.
  

It is usually possible to use the business case (the definition of the project goal) to define what the usability goals should be.  If the usability goal is not a specifically described level of usability performance tied to a real business need then it is likely that usability concerns will have difficulty competing with other project concerns and usability effort becomes secondary to other delivery effort. The result is (yet another) project that specified "good usability" at the start but failed to achieve it by the completion. Like most things, if you write down specific, measurable goals then you are more likely to achieve them. If the goal is vague or subjective then it is unlikely to be achieved. Another method that can sometimes help understand the focus for usability goals is to analyse the risk of various usability problems or failures. Knowing what you really don't want to happen will focus you on the specific issues to address.  Once you have clear and specific usability goals, each decision that affects those goals is made with those goals in mind.  Without the goals, small sacrifices tend to be made that accumulate to failures.

Indicators and measures of usability as a quality

There are three ways to measure usability which currently dominate:

1. Anecdotal comments from people
2. Big obvious failures like low usage, rejection or a very negative review
3. Someone (e.g. a usability agency) comes along and does an evaluation
   

However, there are hundreds and hundreds of ways you could estimate or directly measure aspects of the usability of something. The most practical measure(s) in each situation will be different so the main issue is to check that the data you get gives you good information that you can rely upon. The important point is to use a little imagination and common sense to choose the right way to evaluate whatever it is. A table below provides some examples as seeds for your own ideas.

Aspect	Measures/Indicators
Utility	Run some focus groups
	Give it to some people to try for a while
	Discover/prove a user expressed frustration with the previous method
	Discover/prove a latent need
Safety	Do a thorough failures & effects analysis (and don't forget slips, trips and mistakes)
	Run some serious usability tests
Effectiveness	Develop a valid set of tasks and run a user trial
	Analyse usage data and look for cancellations, duplicates and time-outs
	Analyse your complaints and product returns
Efficiency	Time some people doing some tasks
	Watch people using it and count errors and back-tracks
	Compare first and subsequent uses to see how quickly people learn
	Try it on the same people repeatedly with a gap (e.g. two weeks) to see if the learning sticks
	Evaluate the accuracy of input data
	Compare the efficiency characteristics with something similar
Satisfaction	Use a (good) questionnaire
	Count return user percentage
	Watch people using it
	Find an aspect of the task that people should enjoy and see if they spend more time on it than with a competitor option
Joy	Watch people using it
	Use a (very good) questionnaire
	(for flow) ask if people feel totally in control and evaluate how much attention is on the task and how much is on the controls (you want very low attention on the controls)

Common themes in current awareness

There is obviously a huge volume of information about particular usability issues available online, in libraries, in universities and increasingly in magazine reviews, job adverts, product information and company marketing material. This section is just a short list of quick summaries and hopes to provide the reader with some memorable ideas that usability professionals use in their day-to-day work, which you might find interesting or useful.

User-task-environment

If you do use a professional, their first step in any evaluation (after spotting any glaring issues) and the first step in any analysis preceding design will be to understand:

• who are the users, what types are there and what are their characteristics?
• what tasks need do users want to accomplish and what factors affect those tasks (both within and outside the thing being analysed)
• what is the environment in which the task is done - and not just the physical (noise, heat, light...) but the psychological; stress, panic, boredom, distraction... for example something which is easy on a computer when it's quiet becomes more difficult when you are talking to, or looking at, another person.

Really good usability success stories come from taking enough time to find the issues and opportunities in the user-task-environment analysis (including the wider issues outside your domain). If the product fits perfectly with everything else the person is trying to do then satisfaction scores improve dramatically. Maybe you already know all the issues and characteristics, but write them down so everyone who needs to consider them does so.

User mental models

You may know exactly how your product works but the chances are that your users don't.  A common route to bad usability is designing something that works quite logically, considering all the issues; it will then only be usable to people that understand all the factors relevant to the product or service.

Our brains construct generalised, simplified, often incorrect working theories about the world and the things in it, and this lets us achieve tasks with sufficient success in the quickest time possible.  The theories can change over time; my point is that quick-and-dirty ideas about things let humans make decisions, plans and changes to the world around them with the minimum effort and quickest start-up time. This efficient and effective cognitive approach is applied to all sorts of technology. Non-technical people will have some sort of simple model of how the thing works, and will stick to that model while it offers reasonable performance. The model maybe incorrect, but you'd better design your thing to respond to the actions of someone who is using a simple mental model of your system.

Donald Norman in his book The Psychology of Everyday Things has a great example about the controls in a fridge-freezer.  There is a freezer control which sets the cooling power, and a vent control which controls the proportion of cooling which goes to the fridge and away from the freezer. Arranged as a cooling control in the fridge and a freezer control in the freezer, there are nearly impossible for the average person to achieve their desired outcomes because they simply see a warmer/cooler control in each compartment.  It is unlikely that the average user's mental model of the fridge/freezer will ever match the actual machine design.  I myself had a fridge-freezer where I had to consult a table of symptoms in the manual to discover the right combination of adjustments to make. I could have taken the effort to build a correct model of how the controls worked based on the design of the machine but really, I have other things to do. I don't need to know fridge mechanics, I just need cold groceries.

The lesson here is to design things not for how they work, but for how people will work them.

Affordance

I mention affordance to colleagues and it's always a concept they remember and use, so I'll describe it here; things have 'affordances' which are clues about how you use them. A button looks press-able, a handle on a mug offers a good hold, a textured indent on a big truck offers a good foothold... there is a universe of affordances that we use to guide our actions but they are so automatic we don't notice them. And sometimes designs can have missing, inappropriate or misleading affordances (again, Donald Norman has some great examples - famously including doors that give the wrong signals).  You need to get your affordances right.

Gestalt

Gestalt is a field of perceptual psychology that provides some rules for how we construct objects out of the signals we receive. Designers and usability professionals use principles of Gestalt to guide people to the right understanding of how things relate to one another. There is a host of information on Gestalt available, e.g. the wikipedia entry on Gestalt.

Convention

Sometimes there is an established way that things work, and even though you might know an objectively better way, there are conventions and people are so used to them that it takes too much effort to do it a different way, or people are so expert at the conventional way that you'd be foolish not to exploit that. Well known examples are the Dvorak v QUERTY keyboard and certain computer operating systems. If there are strong conventions you have to follow them even if they're sub-optimal.

Stereotypes

Similar to conventions but less situation specific are stereotypes or archetypes. Put simply, if it looks like Microsoft PowerPoint it should work like Microsoft PowerPoint. Put another way, people can be thought of a little like computers; they have a lot of programs available but they only load up a program when it's needed. If you put the right stimulus in font of someone, they will automatically 'load' the program that lets them operate the thing that they have recognised. People are much more skilled using these automatic, well-learned programs and will use them when available. They can be your friend or your foe.

An example I have seen is when new people get behind the well-designed control of a good boat; it has been made in a way like the controls of a luxury car; similar steering wheel, dials, nicely formed switches.  The power control is different but it's easy to learn. It all goes well until the need to stop arises, and the captain suddenly has no brakes and is travelling too fast. The car stereotype works well until it doesn't... a different set of controls might keep the novice captain thinking about a watercraft and its inertia instead of applying a car model.

If a user hasn't recognised the appropriate stereotype that your design relies on, it makes it hard to learn and operate the system. If they have loaded the wrong stereotype, they can get quite frustrated and lost wondering where things are that they wrongly expect should be there (e.g. brakes).

Interaction metaphors

Very similar to stereotypes is interaction metaphors where you apply a model from one domain into a different domain to help the user out. The classic example is the Xerox Parc idea to use a desktop metaphor for computers - you have a desk to drop things on and a waste bin to throw things away. This gives people a friendly, recognisable way to figure out the sorts of things they can do. If there is a new set of functions, finding (and sticking to) a friendly metaphor is a good idea, but it is a design exercise so you might need a designer to come up with something that will work as you want it to work.


These examples show some of the ways that a professional might consider a design solution or evaluate an existing solution. There are many others and the applicability of these sorts of themes can vary with different situations. As long as you have a correct picture of the target users in mind there are lots of viewpoints that can yield good design.

Usability as a practice

Reaching a good design is partly about design skill and partly about design process. Different people will tell you different opinions about the weighting of each part. My position is that both are essential (without one you have a big risk of failures) and beyond that, a weakness in one can be compensated by strength in the other. Importantly, you need process to counterbalance design and design to counterbalance process; good design ideas can be beautifully distracting, leading you to miss problems, and good process can be boring and miss the spark of imagination that good design needs.

This article is not about the art of design, it is about the process. If there is just one lesson it is this; make sure that you observe representative people using your design in some representative way and secondly iterate the design so that it becomes refined.  If you build, observe, build again, observe and then build once more you'll have a vastly better product than if you just designed, built and launched. All the best companies do this but it's still surprisingly common just to expect design #1 to be the winner and not try it out on anyone.

There are so many ways that the end user can be involved in your design that they won't all be listed here; the process is known as User Centred Design and different practitioners offer different angles on how the techniques can add value or remove risk. It is possible to involve the wrong users, involve the right users in the wrong way, to misinterpret what happens, and to mis-use the information that is generated. On the other hand the risks of not involving users in some way is much larger.

There are different ways that usability professionals become engaged or enlisted into projects; I haven't seen a taxonomy before so I offer my own set of situations:

Crisis usability - the paramedic at a car crash

Often people don't know they have a usability problem until it becomes obvious; something isn't working like they expected. Maybe the support centre calls are unmanageably expensive due to volume; or returns are high; or complaints are high; or reviews are bad; or volume of trade is low.  All the things that usability professionals at the other end always warn about. So the usability people are called in, they have a clear brief ("stop the dam leaking!") and a clear idea of the value because the problem has a cost - it's a good situation to make progress.  You can ascertain the problem, choose a good solution from the options and the customer is eager to implement whatever you suggest (probably).  With crisis usability there is usually also a good measure so after the recommended changes it it easy to measure the effects.

Crisis usability is the sort where there are graphs showing the benefit gained; it's close to ideal.

Performance usability - the doctor to an athlete

Sometimes the customer is wise to the return on investment of some pre-emptive usability work (maybe they have used crisis usability before). The customer has a sales or support channel which has target costs and returns and the business model requires people to use it well and as expected. The risk is obvious; if we spend half a million setting up this service and it doesn't convert to the expected outcomes then we lose money.  So to mitigate the risk you call in someone who specialises in taking that risk out of the design. When the service launches, you should have a pretty good idea of how it will be received because it matches the real users' expectations and it has been properly tested. The potential surprises have been removed.

Performance usability is good work as long as there is enough resource to meet the required level of quality or assurance. If the brief is tricky but the resource is limited it can be better not to get involved.

Design usability - the visionary

Even better is a design breif where the aspiration is to have a beautiful, elegant, top-class usable design - maybe the brand requires it or the need to compete demands it, or maybe someone actually realises that there is a moral responsibility to provide usable products and services; let's all make the world a better place by taking a little effort.

The luxury of doing the proper job because it needs to be done is rare; some agencies specialise in this area.

Institutional usability - the fool on the hill

The trickiest form of usability work is done within a large organisation with all the competing demands and professional agendas that thrive in this sort of environment.

User Centred Design

a section on UCD

Common issues in delivering usability

(a section discussing some of the issues or barriers that often exist)

System model vs user model

Getting data

Getting time

Design vs a design process

ROI

Featuritis - core versus edge case

Subjectivity

Low fidelity mock-ups

Reliability & validity

Participation

References and further info