Usability Success Stories

How Organizations Improve By Making Easier-To-Use Software and Web Sites

Paul Sherman, Paul Sherman

• Éditeur: Routledge
• Année: 2016
• ISBN:
  9781317003151
• Édition: 1
• Sujet: Design
• Sous-sujet: UI/UX Design

People spend increasing amounts of time and effort interacting with complex hardware and software products. Some of the products we interact with are easy to learn and easy to remember. Some are even a pleasure to use. Others are hard to learn, hard to use, and frustrate us at every turn. But it is not just the user that pays the cost in such cases. Poor usability also imposes significant costs on product producers. Companies that make hard-to-use products incur higher support costs, spend more on rework, and have less satisfied customers. These outcomes can be avoided by applying the techniques of usability engineering and user-centred design (UCD) during product development. This book shows how usability and UCD practitioners do this by studying users' needs and abilities, designing the product accordingly, and verifying the design through additional testing with users. Despite the positive return on investment for usability engineering activities, many organizations view usability engineering as a non-critical part of the product development process. This book seeks to change this by relating a number of cases where usability engineering contributed significantly to the solution of a business problem. Evidence is drawn from experiences within a range of private and public sector organizations showing how usability work can best be organized and executed within a business environment. The organizational factors that facilitate or impede the application of usability engineering are also discussed. The book clearly explains the barriers to be overcome as well as highlighting the factors promoting success. A wide range of applications are covered, including web-based e-commerce, medical devices and software, process control management systems, financial services applications, consumer desktop applications and interactive voice response systems. Usability Success Stories provides a valuable guide for business managers and technical staff as well as for practitioners within the field itself.

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...