Preventing Usability Problems from the Get-go

The other day, Jeff Johnson, author of Web Bloopers, showed me something very interesting about Travelocity.com:

Try to book a flight from Boston to Spokane. When you type “Spokane” as the destination city, Travelocity asks you which of Spokane’s two airports you want: “Spokane, WA (GEG)” or “Spokane, WA (SFF)”.

This seems like a reasonable design solution, except for one thing: Travelocity doesn’t offer any flights landing at the Spokane Felts Field (SFF) Airport. Choosing that option will only get you an error message suggesting you might try a different city. (Interestingly, it doesn’t suggest you try the other airport, which has dozens of flights daily.)

It’s possible that a Spokane local might know that GEG is the Federal Aviation Administration’s abbreviation for Spokane International Airport. However, would someone coming from out of town? What are the odds that people will choose the wrong airport and run into a problem with the site?

Interestingly, neither Orbitz nor Expedia, Travelocity’s main competitors, run into this problem. Both automatically assume the traveler wants to fly into the only airport that has flights. So, why did Travelocity choose this particular design avenue?

Some Designs Are Complex

Designing an air travel reservation system is very complex. There are thousands of daily flights, with constant changes to the schedules. A site like Travelocity gets their data from dozens of sources, most of which were never designed for this type of usage.

The fact that Travelocity works as often as it does, doing the right thing most of the time, is quite amazing. This Spokane thing is really just a glitch in an otherwise well running system.

Yet, there is still a nagging question: How come Orbitz and Expedia managed to avoid this potentially serious usability problem, where Travelocity didn’t? What did they do differently?

Where Do Usability Problems Come From?

We’ve studied the development practices of hundreds of organizations over the years, trying to identify how usability problems get introduced into designs. After all, it’s not just enough to know how to spot a usability problem and remove it. What if we could’ve prevented it in the first place?

One pattern we noticed is what happens when design teams work on complex systems. For most teams, the first inclination is to focus on making a design that *works*. This is critical, because a design can’t be usable until it works. So, this is a logical first priority.

Making a complex design work is difficult. Many designs today are either pushing a technological envelope or they are challenging the design team’s skills. Getting the system to do what it needs to, both for the user and on the back end can take everything the team has.

Because meeting the technical requirements and balancing the organization’s needs often come first and second, the user’s needs are often a distant third in this early stage of a design’s life. Many of the teams we studied succeeded at building a working system, often with impressive results.

Usability Problems are Baked into the Design

Yet, just because a design works doesn’t mean it is also usable. The Travelocity design technically works, but is it as usable as the competitor’s design? Probably not.

When a team is focused on making the design work, without looking at making it usable, it’s not unusual for usability problems to become baked into the design. It’s not that the team *wants* an unusable design. It’s that they have no way to know that they’ve made it so. They are so focused on the technology issues that they don’t look for these types of problems.

Making the Jump to Usable

Once the team has succeeded at making the design work, they need to transition their focus to making the design usable. Our research shows this may be a difficult change for many teams.

Often the change in focus comes because of some crisis: some usability problem reaches a critical point and the powers-that-be declare the need for immediate resolution. Unfortunately, this rarely produces a long-term, satisfactory result—working in crisis mode rarely does.

While studying these organizations, we did notice something: some teams make the transition very well. Once they’ve ensured themselves that the design is working fine, they change from a technology-centered perspective to a usage-centered one.

It takes tremendous effort for most teams to make this transition. They start to learn more about how people interact with their design and what those users need from it. Using the results of usability tests and field studies, they start developing personas, scenarios, and use cases.

They start questioning their design. For every screen, they ask difficult questions, such as “Will the user always know what to do here?” and “Have we told them everything they need to know to decide?”

Making it Usable from the Outset

In our travels, we did run across a small number of teams that had the wherewithal to start their designs with a usage-centered perspective. While they still need to ensure their design will work, they also focus on its usability from the outset.

These teams ensure that they spend significant time doing user research from the start of the project. They’ll often start their requirements process creating detailed use cases, usually built from a rich field studies regimen. We saw them conduct frequent usability tests, often *before* they have much of their design, to learn about users and how they respond.

What Happened to Travelocity?

From what we can tell about Travelocity, it seems that they’ve been struggling with the transition from working to usable. (This also seems true of their sister web sites, VirtuallyThere.com and AA.com, all part of the Sabre family.) Contrast that to Expedia, which, a few years back, put a focused effort into their transition, making the user experience a top priority in their design efforts.

Interestingly, Orbitz was one of those few organizations that started with a usage-centered perspective from the first day. They knew they were moving into a competitive arena and that making a usable experience would give them a competitive advantage. (It’s worked—they grew to more than $200 million in less than 3 years.)

“If Only We’d Known 2 Years Ago…”

We regularly work with teams in struggling companies, similar to Travelocity. Often, during these projects, we find ourselves discovering usability problems in their designs. Every usability problem unveils a piece of information about the users that the team wasn’t previously aware of.

In practically every project we hear the words, “If we’d only known about this two years ago, we would’ve designed it differently.” This sentiment is echoed again and again by teams who, until recently were focused only on making their design work. It really captures the angst of a team that realizes they could’ve done it all differently.

Tools for a Usage-Centered Perspective

When we studied the organizations that had a heavy usage-centered focus, we found that they all had a very similar toolbox. This toolbox provided these teams with the techniques necessary to get the necessary information in to the design process.

Almost every team we studied used some variant of field studies, personas, and usability testing to ensure that they knew as much about their users and the users’ goals as possible. They didn’t always conduct these the same way—in fact, they often didn’t even call them the same things. But, once you got under the surface, it’s very clear that these three activities were central to their success.

We were surprised by how many teams were regularly conducting some fashion of field studies. Here, they were visiting their users in their natural habitats, observing how these people went about their daily lives. It was from these studies that they discovered the true motivations of the users and where the design could really enhance the users’ experience.

Personas, in various forms, were also a common thread in the successful organizations. Personas are detailed descriptions of the users, their contexts, and their motivations. Using the age-old tradition of storytelling, teams ensured every team member *knew* their users in-depth, like someone knows an old friend. We have yet to see a more effective technique for communicating user wants and needs.

Finally, some type of usability testing was core to practically every team’s validation process. Not just a single batch of tests, just to ensure they were going in the right direction. Instead, the most successful teams were constantly testing ideas, using all manner of prototypes and competitive designs. Every test yielded more information about their users, giving them insight into the implications for future designs.

It’s All About Perspective

There’s nothing wrong with focusing on making it work. It’s a necessary first step for any design, especially those involving complex technological issues.

Our research clearly shows, however, that those organizations that make a focus, concerted effort to become usage-centered—like Expedia and Orbitz—will naturally produce a design that both works and is highly usable. Being technology-centered, like Travelocity, will produce a working design, but rarely produces a usable one.

How do you ensure you become usage-centered? Learning as much as you can about who your users are and what your users need. The teams we studied made this a constant, using techniques like field studies, personas, and usability testing.

If we learned anything from our research, it’s that preventing usability problems from the get-go isn’t a one-time activity. It’s a philosophy—an approach to designing—that separates the truly successful organizations from those that constantly struggle.