CHAPTER 1
An Introduction to Usability and User-Centred Design
Paul Sherman
Have you ever struggled to figure out the remote for your new television or cable box? Do you often find yourself cursing at the airlineās voice recognition system when you call to make a flight reservation? Have you ever become so frustrated with a computer application, web site or handheld device that you felt your blood pressure rising and your hands balling into fists?
Us too. Thatās why we wrote this book.
Thereās an entire profession ā we call ourselves usability engineers, user experience designers, interaction designers, user-centred design practitioners and so on ā that strives to eliminate these daily moments of frustration. Often it feels like an uphill battle. New technology is often fun and interesting. It sometimes delights us unexpectedly by solving some of lifeās little problems.
But the downside of new technology is that itās often designed by technologists. They regard new gadgets and devices as challenges to be mastered ā and their designs reflect this mindset. In contrast, ordinary people often see new technology as a speed bump on the path of daily life. One more thing to devote scarce time and attention to. To the ordinary person, new technology can be powerful yet difficult to grasp; comprehensive and incomprehensible; robust yet obscure.
Because the technologists bring such wondrous things into existence, sometimes with nothing more than mysterious lines of symbols and numbers, organisations tend to let them exercise control over how ordinary people should interact with their creations.
But the technologists donāt think like ordinary people. Even if they did, the very fact that they are so close to the details of their creations causes their understanding of them to differ radically from anyone elseās understanding.
Remember, the āordinary personā weāre talking about is your grandmother, your electrician, the school student at the supermarket checkout. Most people have the capacity to eventually understand a piece of technology at a comparable level of detail. But they donāt have the time to learn the technology, much less the motivation. Theyāre busy with other things.
Yet, time after time, organisations bring to market products that reflect the technologistās way of thinking. These are the devices, web sites and applications that raise our blood pressure.
The members of our profession are devoted to the never-ending task of minimising or eliminating these mismatches between technologyās designers and its users. Often our efforts fall short. Itās hard to shake the status quo in organisations that are so focused on technological innovation.
However, our profession increasingly gains traction. We learn how to influence the product managers who guide the creation of new technologies, the technologists who create them, the project managers who own the schedules and the executives whose decisions affect the dozens ā sometimes hundreds ā of people who contribute to the creation of new technologies.
This book is a place where youāll learn not only what contributors in our field do, but also how several of us have effectively influenced our organisations and got them to incorporate users into product design and development processes. Youāll hear how weāve convinced decision-makers in our organisations that listening to, watching and interacting with ordinary people as they attempt to use our creations increases acceptance of new technologies and helps the organisation achieve its financial goals.
WHY WRITE ABOUT SUCCESSES?
People spend increasing amounts of time and effort interacting with complex hardware and software products. In the future more, not less, technology will be introduced into our work and personal routines.
Some of the applications and products we interact with ā such as airline check-in kiosks and ATMs ā are easy to learn and easy to remember. Some are even a pleasure to use (think Appleās iPod, or virtually all of Googleās offerings).
Others are hard to learn and hard to use, and in general frustrate us at almost every turn. When we encounter these products, we say they are not user-friendly, or that they are not very usable. Another way of saying it is that these products possess low (or poor) usability.
While there are nearly as many definitions of usability as there are usability practitioners, a concise definition can be found in the ISO standards (ISO 9241ā11, 1998). The standards body defines usability as the effectiveness, efficiency and satisfaction with which a specific set of users can complete a specific set of tasks in a particular environment (Sherman and Quesenbery, 2005).
Hopefully, you noticed the focus on the user in that definition. This is no accident. Usability is all about people, not products. There is no āobjectiveā measure of usability that can be applied to any given device or application. The bottom line is this: if the intended users can use the product to accomplish their goals, then the product is usable. If they canāt (or canāt readily) use the product to accomplish their goals, then itās not really usable.
In our personal lives, products with poor usability cost us time and energy. How many times have you pushed a door handle instead of pulled, pressed āCancelā instead of āOKā, or sat seething in front of your computer monitor, unable to figure out how to purchase an item from an online retailer?
In the work arena, organisations also incur costs when people choose to (or are told to) use a product with poor usability. Businesses lose money because frustrated customers leave (Kehoe, Pitkow, Sutton, Aggarwal and Rogers, 1999). Productivity and even employee satisfaction decrease when employees use software applications with poor usability (Macleod, Bowden, Bevan, and Curson, 1997; Rehman, 2000).
Whether a product is used at work or at home, poor usability imposes significant costs on the producer of the product as well. Companies that make hard-to-use products incur higher support costs, spend more time and money on rework and tend to have less-satisfied customers (Bias and Mayhew, 1994; Wiklund, 1994).
These outcomes can be mitigated ā and often avoided entirely ā by applying a user-centred design process and usability engineering techniques during product development.
The discipline of user-centred design includes a set of techniques that help development teams accurately gather and assess target usersā characteristics, goals and motivations, as well as their workflow, pain points and critical behaviours. User-centred design and usability professionals do things such as:
ā¢ watch people as they perform tasks and activities that product or service providers would like to assist, expedite or automate;
ā¢ discover peopleās skills, goals, motivations, frustrations and successes as they work (or play, or interact, etc.);
ā¢ create designs that assist, expedite or automate, with attention to the intended usersā skills, goals, etc.;
ā¢ test these designs by having people from the intended user group attempt to perform the tasks and activities supported by the product;
ā¢ revise the design as necessary, on the basis of the results of the test sessions.
Armed with this knowledge, user-centred design practitioners are able to design features and interactions that meet the needs of the intended users.
Performing these activities costs both time and money to the organisation, but the costs of usability engineering are usually outweighed by the benefits. In some cases the benefits dramatically outweigh the costs, yielding surprisingly large economic rewards for organisations. Studies have been published documenting a tenfold return, and more, on investment for usability engineering activities (Bias and Mayhew, 1994; see also Lund, 1997).
Despite the evidence for a positive return on investment for usability engineering activities, many organisations view usability engineering as a ānice to haveā, a non-critical part of the product development process. When times get tough, organisations routinely jettison their user-centred designers and usability engineers, if not during the first round of lay-offs then usually by the second or third.
Itās apparent that the message doesnāt always get through. In many cases the ābusinessā (shorthand for the portion of the organisation that decides what to build) and ādevelopmentā (the people who actually build what the business wants to build) do not recognise that dollars spent on user-centred design are dollars incredibly well spent.
The contributors to this book seek to change this by relating cases where user-centred design or usability engineering contributed significantly to the solution of a business problem. The authors also discuss organisational factors that facilitated or impeded the application of usability engineering to the problem. By telling their stories, the authors hope to accomplish two things:
ā¢ provide other practitioners with the benefit of their learning and experience, and
ā¢ demonstrate to technologists and business stakeholders the benefits of integrating user-centred design into their processes.
Why tell āsuccess storiesā? The answer is deceptively simple: humans are drawn to narratives. The story is the oldest ā and probably still the most effective ā way to convey information. By using this format, we explicitly acknowledge and seek to leverage the power of narrative.
Before we tell our stories, hereās some background on the strange world of software development, and more about usability and user-centred design.
THE WORLD OF SOFTWARE DEVELOPMENT
For those who have not witnessed it first-hand, the software development environment is an odd place. If you took a peek into a software development shop, you would be hard-pressed to see anything actually getting done. The product is created, lines of code at a time, across many software developersā computer systems. Each developerās pieces of code are compiled into ābuildsā which represent a collection of executable code, code libraries, scripts and other digital objects.
If the build ābreaksā ā that is, if it doesnāt compile, the program doesnāt run or it runs incorrectly ā itās up to the testing group (known as Quality Assurance, or QA) to help identify the source of the breakage, document it and send the whole mess back to the software developers so they can fix the bugs. When enough bugs are fixed (or when time runs out and itās time to launch the product), the development efforts cease ā at least for a while, until the next release kicks off, or the release is so buggy that a āservice releaseā (or āpatchā) is necessary.
But this process represents only a piece of the picture. Many activities must take place before the developers start coding and QA starts testing. The most important activity that occurs is that someone decides what to build. Typically, the product management group ā the ābusinessā ā studies the market, the competition and various economic factors, and decides to build a product (or additional features for an existing product) that they believe will satisfy potential customers and meet the economic goals of the organisation. This is often referred to as the āideation phaseā.
During this phase, the product manager (or in some organisations, the business analyst) begins to communicate with the software development group in a variety of informal and formal ways. Informally, they meet to discuss strategic directions and what features to build to attain the short-term and long-term goals of the business. More formally, product managers and business analysts produce and distribute market requirements or business requirements documents.
These documents typically describe the business case, or the justification for building the feature or product. They can also describe what the product or feature should do, typically in very granular, unitised statements known as feature requirements. In most software development organisations, these requirements documents are the āspecā ā the specification of what should be built by the development team.
Ideally, product management has a complete and thorough understanding of the potential customersā needs, and the requirements they write are unambiguous. That is, the requirements should be a faithful reflection of existing and potential customersā needs, and everyone who reads them should come away with the same understanding of the writerās intent.
In practice, neither of these objectives is attained with any degree of regularity. Usually two phenomena occur to prevent them:
ā¢ Product managers develop an inaccurate or impoverished understanding of the customers and their needs, and so the requirement set does not represent usersā needs accurately, or represents them only incompletely (sometimes both).
ā¢ Software development attains an inaccurate or incomplete understanding of product managementās intent, and so develops a feature or product that does not meet usersā needs.
And when the product makes it to the marketplace, it ends up disappointing the customers.
Of course there is no perfect world; errors always creep into any human endeavour. But this particular state of affairs plays out time after time, project after project. There is no magic bullet to prevent these phenomena from ever happening, but there are techniques and methods to ameliorate and reduce their influence.
User-centred design and usability engineering are two of these methods.
USER-CENTRED DESIGN AND USABILITY ENGINEERING
Into this breach step user-centred design (UCD) and usability engineering. UCD and usability engineering employ observational and quasi-experimental methods to gather and assess target usersā characteristics, goals and motivations; and document their workflow, pain points and critical behaviours.
This information is extremely helpful to the product manager or business analyst. One challenge they typically face is integrating population-level information such as market size, overall market trends and large sample surveys with their anecdotal encounters of small numbers of potential customers, often in focus group environments rather than in their place of business.
The notion that valuable information can be extracted from simply watching people as they work is simple yet powerful. Every ā and I mean every ā product manager and business analyst who has taken part in observational research sings the praises of the method (and often praises the USD practitioners as well!)
Why? Because observational research provides them with a rich set of actionable data. The data we collect describe how the target users currently solve their problems and attain their objectives, and what they do with prototypes or mock-ups of the proposed product. This offers product managers a means to bridge the gap between market-level quantitative data and their anecdotal experiences.
When people performing ideation-phase work are able to take part in methodologically sound observational research, the quality of their output invariably improves. They write better, more-complete, more-accurate requirements. And they carry in their heads a deeper understanding of their users. They draw on this understanding in their countless informal interactions with the developers and senior management.
User-centred design practitioners often have prototyping skills, meaning that they can mock up a product or feature. Even though prototypes and mock-ups canāt be used as real products, their appearance and behaviour help the business more effectively convey their intentions and objectives to the developers, augmenting the written requirements doc...