Integration

The assumption that user experience is just another add-on is fairly consistent across the industry.

—Don Norman," The Invisible Computer"

Initially, it may seem easier to rip everything out and start over again because traditional processes seem so different from user-centered ones.

Don't do that. That may seem easier, but it isn't. The momentum in a company's existing development process is usually so strong that a complete restructuring requires a huge, disruptive effort. Questioning the basic fabric of a company's life cycle is a big gamble, and big gambles can fail spectacularly. Thus, when first introducing user-centered thought, pick the right place to start.

Know the Current Process

Note

Much of this section is indebted to the work and thinking of user experience consultants (and my business partners) Janice Fraser and Lane Becker.

There's a process by which products are created now. Sometimes it's formal, established, and closely followed. At other times, it's ad hoc. Before you begin introducing user-centered processes into your company, you should know how development is supposed to work, how it actually works, and how you can manipulate it so that it works better.

Warning

In this section, I attempt to formalize the kinds of social knowledge and interactions that already exist in companies. Understanding your company's processes and working within and around them doesn't require that you become a radical revolutionary for user experience. Knowing the best way to communicate the value of a user-centered design will get you a long way toward positive change. And it's less messy than painting slogans on the elevator doors.

The starting point to introducing new ideas is internal discovery, the process of understanding how and why products are created inside a company and the constraints that shape their creation. Put simply, this is the process of answering three major questions.

• Why is it being done?

• What does it do?

• Who cares about it?

Answering these questions in a broad way about any single project will help you understand how to introduce change into the development process as a whole. Like "follow the money" for journalism, each question is designed to lead to other questions rather than a pat answer.

Why Is It Being Done?

What is the fundamental business case for the product? The reasons for creating or updating an offering are rarely simple. They conceal assumptions and expectations. There are reasons the company wants to make the thing. What are they? If it will generate revenue, then exactly how is it expected to do that? If it will improve the company's image, then how is it going to do that (and what's wrong with the image now)? If it will fulfill someone's personal agenda, then what are they hoping to gain from it, and why are they pushing for it?

What Does It Do?

The functionality a company wants to include reveals much about its understanding and prioritization of user needs. Why are these features more important than others? What makes them critical now? Why not do more? Why not do less?

Who Cares About It?

Introducing user-centered ideas means first identifying who makes the decisions about a product and what their responsibilities, needs, and agendas are. When someone is a stakeholder in a product, its success is their success, and changes to the process of making it will affect how comfortable they are with it and how loyal they are to it. The person who most wants it to happen and who is in the best position to make it happen is its sponsor. Who is the project sponsor? Who are the other stakeholders, the other people who care about or can influence it?

Profiling the stakeholders is the first step to knowing how to present to them, and identifying them ahead of time helps you know who to talk to when it's time to create a strategy for introducing user-centered ideas in the company. In some situations, it may be as simple as convincing the chief operating officer that there's a bottomline benefit to making a more usable product (which is, of course, harder to do than say). In other cases, you may need to work a grass-roots campaign to win over the engineers by showing them how few grubby support tweaks they'll have to make if they get the user's mental model right ahead of time. In many cases, you need to do both, gaining strong support at the top and allies at the product team and director levels.

Internal Discovery

All this is to say that understanding the impetus for a product involves learning to understand the current position, self-image, and political structure of the company. These details are present, if unacknowledged, in every company. Uncovering them is the process of internal discovery, which consists of asking the preceding questions in a systematic and consistent way.

It begins with a list of the major questions based on the general categories defined earlier. Some common ones are

• Who are all the stakeholders?

• How are decisions made and scoped?

• What are the current business mandates?

• How are key terms and concepts defined?

Expand the questions as appropriate. For example, the following questions may help you identify key stakeholders:

• Who are the people who are clearly interested in this project?

• Who are the people who should be interested in it?

• Who are the people whom it's dependent on?

• Who can roadblock it? Who is likely to do so? Why?

• Who is likely to want to help it?

This will give you a first-order understanding of whom you should talk to when doing internal discovery. They may be people who are already on your team, or they may be in adjacent departments. They may be top executives. They may be opinionated engineers.

Once you have an idea of who is important to the project, the company's business mandates, and the reasons for its scope, you have the building blocks for creating a strategy. In a sense, corporate cultures are games. By uncovering the rules and players and playing with a sense of ironic detachment, you play better.

Start Small

In some companies, it's best to start reforming the process from the top, with an executive evangelizing and pushing until the whole company has changed. In another, it may be appropriate to create a "skunk works" that exists outside the rest of the company. Still in others, it may be more appropriate to disseminate abstract ideas first, letting the ideas filter in over the course of months or years before introducing additional methods.

In many cases, starting small works best. When they fail, small projects are not seen as severe setbacks. When they succeed, they can be used as leverage for larger projects. Moreover, they educate everyone in the methods, goals, and expectation of user experience research and user-centered design.

How small is small? Initial targets should be short term, doable, and straightforward. They should also be things that the success of your project doesn't hinge on. A first project can be the redesign of a small section with known problems: a registration page, for example. John Shiple, former director of user experience for BigStep.com, suggests shoehorning user experience research into Web site front door redesigns. Front doors are redesigned on a regular basis, and they serve as entryways and billboards for the company. They are important parts of the user experience, but their design often affects presentation more than functionality, so unsuccessful designs can be rolled back easily. This gives their redesign scope and importance, but without the weight of core functionality redesign.

For example, a news site decided to redesign their front door to improve retention and repeat visits. The designers were working from assumptions based on their own experience when they decided to integrate some user research into the process. It was a month before their relaunch, so there wasn't enough time to research fundamental audience needs or make detailed profiles, but they could test whether their plans to increase content density and emphasize subsection navigation made sense to their potential users. They recruited eight people who matched their audience profile, and wrote a user test to profile their users and test several prototypes.

As they interviewed the participants, they discovered several things they had not expected: increasing the density of data on the front page made it clear that the site contains a lot of information, but overwhelmed a number of participants, several of whom called it "cluttered." Moreover, most of the participants didn't use the navigation bar at the top of the screen, but chose to type keywords into the search box instead. The team realized that their search engine was much more important to the success of the site than they had previously thought.

Likewise, although they weren't studying people's attitude toward their brand, they observed that a number of their users were fiercely loyal, but would never be daily users. Until this point, they had assumed that everyone would be looking at the site every day. This result was, in effect, asking a fundamental question about the design of the product and how the company defined customer retention and success.

Prepare for Failure

Prepare to stumble as you start bringing user-focused techniques in-house. You may do the wrong research at the wrong time with the wrong part of the product. You may ask all the wrong questions in all the wrong ways. You may be asked to do something that's inappropriate, but you have to do it anyway. The research results may be useless to the development staff, or they may completely ignore it. Management may ask for hard numbers that are impossible to produce.

This is one of the reasons to start small. This is also an occasion to be philosophical. Bad research happens to everyone, but every piece of user research, no matter how flawed, provides insight even if it's only into how to structure the research better next time. Recognizing failure greatly reduces the likelihood of such failure in the future. Set appropriate expectations for yourself and for those who may be receiving the results, use problems to make further plans, get feedback from your interview subjects, and examine how well the research is going even as it's still under way.

Involve Stakeholders Early

A heuristic evaluation—or, thoughtful criticism—often does not convince partners that such and such sucks. A live event—with donuts—behind one-way glass can, however. That's sad, but true.

—Dave Hendry, Assistant Professor, University of Washington Information School, personal email

A process is truly customer centered when customers can change designers' initial understanding of the work.

—Beyer and Holzblatt, Contextual Design, p. 54

Making people observe and participate in research is one of the most effective ways to sell them on its value and effectiveness. Observing users failing to use a product is an incredibly powerful experience. It communicates to the observers that their perspective may be entirely unlike the way their users think.

The development team and key stakeholders need to be involved in research, but they need to be involved in different ways.

The Stakeholders

Those who make decisions about a product need to see the value of the process firsthand. The best way to accomplish that is to make them watch research firsthand. They don't have to actively participate, but if they can be in the same room watching people struggle and listening to the kinds of ideas that these struggles inspire in the development team, they are much more likely to support such efforts in the future.

The Development Team

Those who are directly involved need to see the research process and its results. For them, participation in the research should involve direct participation in developing the research goals, creating research prototypes, and analyzing the results. Once they've participated, they are much more apt to support the process and to integrate it into their future plans.

Warning

Respect your development team. Just as there's a tendency in developers to write off users who don't understand their software as "stupid," there's a tendency in user experience researchers to write developers who don't understand user-centered design processes as "stupid" or at least "clueless." Take an active part in development, explain processes, and listen for suggestions. If a development team seems clueless at first, it's surprising how quickly they appear to wise up when engaged as partners in a research project.

Including everyone in every bit of research is often difficult, however, and developers need to be directed toward research that will be most meaningful for them. For example, people from marketing and business development are more likely to be interested in ideas that speak to broad, strategic issues with the product. These are often embodied in focus groups or contextual research studies and less so in usability tests. Technical writers and trainers benefit from knowing which concepts people want explained better, issues that are revealed during task analysis or usability testing interviews. Engineering and interaction design absolutely need to be included in usability testing, but participating in contextual research may not be as immediately useful to them (that said, these two groups should probably be in as much research as possible since they are in the best position to apply bottom-to-top knowledge of the user experience).

Show Results

Almost as important as involving people in research is showing results in such a way that stakeholders see its value. It's most important to present it in a way that is immediately useful, but the ideal research also convinces. Every report can serve as another platform from which to discuss user-centered development.

Presentations should be tailored to specific audiences, as discussed in Chapter 17. For example, the vice president of online services of a media company did not have time to attend any user research, or even to sit for a full presentation of the results. However, he was an important person to convince of its value. So the research team asked him for ten minutes of one of his notoriously quick lunchtimes. There was no time to describe the findings in detail, but it was enough to expose him to important concepts. The presentation focused on the process and showed him a couple of factoids showing improvements in the product. This told the vice president that his staff were thinking in original ways about the customer and introduced him to some new ideas about the development process.

Even as you're writing your report for the developers, think about how to make it a good lever when changing your corporate culture. Present changes in small groups to encourage rapid iteration and discussion. With every report, highlight unanswered questions and future research possibilities to encourage more research. Discuss the interaction of the needs of users, advertisers, and the company's identity to get people thinking about the product as a melding of the three.

Be Patient, but Persistent

You need to be stubborn, committed, and shrewd, but know when to back off and when to barge into the senior VP's office.

—Chauncey Wilson, Director, Bentley College Design and Usability Testing Center, personal communication

Software development cultures attempt to schedule their revolutions. In such an environment, it can be difficult to convince people that an evolutionary approach is worthwhile. But that's exactly what needs to happen when introducing user-centered methods within an organization. A carefully chosen pace will keep the momentum of innovation going, but without unduly stressing the development process or the people in it.

Sometimes, though, the response to research will be lukewarm. Reports can sit unread on managers' desks or be discounted by engineers who see insufficient scientific rigor in them. In these situations, continuing the research is especially important, showing that results are real, valuable, and consistent. For example, if you once had ten minutes with a vice president, request a similar amount of time after every piece of research on a regular basis, presenting the highlights of the research once a month. Even though he or she may not be interested in the specifics of each research project, the stream of interesting tidbits of information will be a useful reminder of the process and its value. Schedule lunchtime seminars on user-centered design and invite people in from outside your company to talk about successful projects. Buy some pizza. Having an outside voice discussing situations similar to those your group is encountering can be quite convincing.

Encourage Specific User Experience Roles

When the value of user experience research and user-centered design begins to be acknowledged in the company, it's useful to start pushing to create positions that take charge of the process. When someone is responsible for the process, they can serve as both spokesperson and evangelist.

In reverse order of seniority, here are a few sample job descriptions.

User Experience Specialist

The User Experience Specialist is responsible for evaluating, tracking, and designing an effective user experience within a development team. The specialist will monitor the development process for situations that require managing the execution of the research and working with the development team to interpret the results.

Usability, marketing research, experimental psychology, or real-world cultural anthropology experience required. Design and software development or project management experience preferred. The ideal candidate will be able to manage research projects and interpret research for design, engineering, and technical writing audiences in addition to moderating research and analyzing results.

Director of User Experience

The Director of UE is responsible for all user experience research within the company. Responsibilities include managing all in-house research projects, communicating results to management, training junior research staff in basic techniques, and transferring knowledge across all research projects as appropriate.

Familiarity with common user experience research methods (usability testing, task analysis, contextual inquiry) is required, and all candidates should have at least three years' experience conducting frequent research studies from beginning to end. Specific experience should include creating user profiles for research and development, recruiting participants, moderating research, and analyzing and presenting results. Experience working closely with interaction designers and software developers required. Information architecture experience preferred.

In addition, candidates should be able to train others to conduct user experience research and be able to adjust research methods in response to the needs of the product or the development team.

Chief Experience Officer (CXO)

The Chief Experience Officer is a senior management position in charge of the entire user experience for all classes of users under all circumstances. This position encompasses any design, marketing, and customer support effort that affects the way people interact with the company. It requires familiarity with all facets of user experience and marketing research. In addition, the CXO should have extensive experience with the design end-user interaction, whether from a visual, creative standpoint, an interaction standpoint, or as part of a customer relationship management system.

In concert with ensuring the best possible experience for the users of a company's products, the Chief Experience Officer is responsible for introducing and maintaining a culture that integrates user input and user research at all key points in the development process. The CXO should be familiar with user-centered management. Finally, the CXO has the responsibility for balancing the needs of the users with the needs of the company, reporting first and foremost to the users, but also to the stockholders and board.