"A good user experience doesn't just happen -- it first needs to be envisioned and researched, and then deliberately designed using the right mix of skills and technologies."

Technology Should Be Invisible

Increasingly, users expect the kind of flexible, interactive, collaborative applications that Web 2.0 makes possible. Every successful consumer site or application with a "wow" factor raises the bar.

Let There Be Art!

Most users don't care about technology at all -- they're just trying to get their work done. A great user experience comes from a focus on user needs, not the latest user interface widgets.

Opening Statement

The concept of "ease of use" has worked its way into the collective consciousness of the consumer and business world. A quick Web search shows that "ease of use" crops up in marketing copy and professional reviews of everything from Volkswagens to pharmaceutical packaging to worldwide mobile advertising. Ease of use is here to stay.

In the chaotic process of getting a product to market, ease of use (also called usability or user experience) was once considered a luxury. It's increasingly risky to think that way. During the dot-com boom, we saw plenty of silly ideas, not to mention silly business models, come and go as giddy startups threw everything at the market, trying to figure out what would stick. We learned that that's a pretty expensive way to fail. Meanwhile, classic success stories like Amazon.com and eBay were focused on delivering what their users wanted and needed. Their success helped to raise the bar -- managers recognize that the market is no longer quite so forgiving of companies that take two or three releases to get the user experience right.

I recently evaluated some home security systems for a client. In the US, professional monitoring of a consumer security system, which includes dispatch of emergency services, typically costs about $30 a month. That's not a lot of revenue for the monitoring companies, and false alarms take a big bite out of the bottom line. In fact, some municipalities have threatened to no longer respond to such alarms or to fine the homeowner if the alarm proves false. The problem is bad enough that the Security Industry Association has actually created an "alarm school" (the analogy to "traffic school" for those convicted of driving offenses is intentional) to "educate residential alarm users about the enormous costs associated with false alarms, most of which are caused by user errors."¹

Hold on a minute. Let's draw what the current process looks like:

Sales --> installation --> use --> false alarms --> punishment --> education

You don't have to be a genius to spot the problem: education comes last! Wouldn't it make more sense to integrate user education throughout the customer's experience? To wit:

Sales/education --> installation/education --> use/education

Although I'm not an industry insider, I believe that security companies ended up in this pickle because they focused on making their systems reliable (necessary to even get in the game) and delegated to professional installers the important task of educating homeowners about their sophisticated but not-very-intuitive systems. From what I have seen, most systems are still jargon-heavy because no one has thought to translate them to user-friendly language.

For example, one system has a settings page with an option labeled "Exit delay tone enabled" with Yes/No buttons. The translation for normal people is, "Do you want the system to beep during its countdown to arming the system?" So how come it doesn't simply say that? I think there are two reasons:

1. "Exit delay" is a standard term in the security industry. There's nothing wrong with using jargon within an industry, but whenever the audience changes, in this case to consumers, it's worth checking whether a translation is needed.

2. Developers create a lot of nouns for the concepts in their system. They do this because they write specs, and nouns are an efficient way to refer to things (e.g., "Exit tone delay is enabled in Settings"). And concepts are sometimes used as building blocks for other concepts -- in this case, "exit delay" goes to work as an adjective to give us "exit delay tone." Again, this is completely appropriate within the development team, but it may draw blank stares from anyone else.

Unless companies look for these kinds of issues, they will continue to fly under the radar. Focusing on the user experience takes a deliberate, conscious effort. There are actually many "teachable moments" during the sales and installation process of a security system, but the systems I've seen don't take advantage of them. There's a huge opportunity here -- the company that gets the user experience right is going to eat everyone else's lunch.

Of course, such challenges aren't unique to the security industry. As a usability consultant, I see them in virtually every project I work on, because our ability to create new technology outpaces our understanding of how real people will actually use it. In the security industry, the false alarm problem is just one highly salient manifestation of users' difficulty in learning the interface. IT professionals don't literally hear the sirens going off (or at least, most of us don't). Instead, the suffering happens in relative silence, in the form of lost productivity, turnover, or customer dissatisfaction.

The International Organization for Standardization (ISO) defines usability as "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" (ISO 92411-11).² And because all users are human beings, these three main facets of usability are just as applicable to internally used applications as they are to consumer-facing ones. That's what this issue is about.

In our first article, Jared Spool makes a compelling case for why we're on the cusp of a new level of expectations that goes beyond interface design to experience design. He uses Netflix as an example of this phenomenon, showing how the company has put a lot of effort into designing all its interactions with its customers, including, surprisingly, the way it handles customer service problems. Even for applications that are only used internally, it's vital to think about the user experience in terms of more than just technology. Spool explains how disciplines that have not historically been part of IT, such as copywriting, take on a new importance, and organizations that fail to adopt a multidisciplinary approach will be scrambling to keep up. He ends with some practical suggestions for how to think about your organization and end users. By envisioning the future user experience now, you'll be better prepared for what lies ahead.

Next, Nick de Voil talks about how IT is affected by Web 2.0 -- in particular how Web 2.0, with its rich input and rich feedback, is changing expectations about intranet usability. New technologies such as AJAX may give developers better capabilities for improving the user interface and performance of Web-based systems. Collaborative content offers the promise of capturing organizational knowledge in a form that can be preserved and shared. He also discusses the intriguing notion that four distinct types of pleasure (or "satisfaction," to use the ISO definition) can be designed into an application. And while Web 2.0 capabilities can help deliver these kinds of pleasure, such capabilities must of course be deployed strategically rather than capriciously.

In contrast, Martha Lindeman goes into detail about why developing rich Internet applications (RIAs) is a double-edged sword. Developers aren't just upgrading their tools -- they have to consider many other factors that interact in RIAs, with an exponential increase in complexity. For instance, the ascension of mobile devices means that designers must design for occasional connections rather than constant ones. In addition, because the basic unit of change in a RIA is a region of a display rather than an entire page, users can no longer use the Back and Forward buttons to move between pages. And as if that weren't enough confusion for the poor user, the technology that supports RIAs allows designers to create almost any user interface control they can think of -- even some with a nonstandard look or behavior. Most developers are already good at thinking about edge cases, but Lindeman outlines a bunch of new edges that we might want to beware of.

Next, Rebecca Ormsby talks about what happens when things get older -- not just us humans, who are subject to physical and cognitive frailties, but also those aging legacy applications that will be increasingly seen as intolerable by the YouTube generation. The classic (though macabre) joke about legacy users is "The good news is that they will eventually all die." However, those old applications might have to be murdered! Ormsby's article first discusses some general strategies for supporting users with age-related declines in vision or dexterity. Fortunately, just as curb cuts help not just people using wheelchairs but also people on rollerblades or pushing strollers, age-friendly designs are usually advantageous for younger users as well. The second half of Ormsby's article encourages us to think about what will happen when those old users are, well, maybe not dead, but happily retired. When they leave, they take much of the organizational memory along with them, leaving younger employees to face ossified, undocumented legacy systems on their own. The challenge for internal applications lies in building more ease of use and expertise right into the applications themselves.

And that brings us to our last article, in which Michael Hughes and Richard Henneman summarize the tension between features and usability. But they don't merely admire the problem -- they provide practical advice for how to make complex applications work for users by understanding their needs (hint: you can't always take what they say at face value), modeling their interactions with the system, and providing meaningful assistance. You've probably noticed that much traditional help content is drivel, along the lines of "To remove a policy, click the Remove button next to the policy you want to remove." Fortunately, there's a better way, and Hughes and Henneman have got some great examples to prove it.

The unifying concept in this issue is that the user experience plays an essential role in an organization's success. But a good user experience doesn't just happen -- it first needs to be envisioned and researched, and then deliberately designed using the right mix of skills and technologies. In my opinion, those of us in the usability profession are still learning how to do this, and I don't think we have all the answers yet. But having IT managers who understand the importance of the user experience is a huge step in the right direction.

ENDNOTES

¹ "Ninety Percent Reduction Rate Signals Solution to False Alarm Problem." Security Industry Association, 2008 (www.siaonline.org/research/false_alarms.html).

² "ISO 9241-11: Guidance on Usability." International Organization for Standardization (ISO), 1998.

ABOUT THE AUTHOR

Carolyn Snyder has spent the past 15 years practicing user-centered methods, focusing on usability testing and paper prototyping. Ms. Snyder is the founder and principal of Snyder Consulting, a usability consulting firm specializing in hands-on work with development teams to help them evaluate and refine their user interfaces. She has conducted approximately 1,000 usability tests of software applications and Web sites from a wide variety of industries. Ms. Snyder is the author of Paper Prototyping, the seminal book about low-cost, rapid prototyping. She teaches a course in the technique at Bentley College. She is coauthor of two books on Web usability and is active in professional usability organizations. Prior to becoming a usability professional, Ms. Snyder spent 10 years working at Landis & Staefa, a building controls company, as a software engineer and project manager. She has a BS in computer science from the University of Illinois and an MBA from the University of Chicago. Ms. Snyder can be reached at csnyder@snyderconsulting.net.