Feature: Selling User Research to the Reluctant

Researching the users of your product is extremely important in making it more popular, more profitable, and more compelling. But companies make products, not user research teams. A company needs more than data about its users; it needs to be able to take that knowledge and act on it. Unless the benefits and techniques of user-centered design and research are ingrained in the processes, tools, and mind-set of the company, knowledge will do little to prevent problems.

A user-centered development process means making an overall shift in perspective from how products are made to how they are used. Development processes are focused on making a product, not satisfying needs. This is a major gap between how a company and their customers think about its products, a gap that's often revealed by user research. The difference between the capabilities of a product and the unsatisfied needs of the users reflects deficiencies in the development processes as much as in the product itself. This is where a solution that's based solely on research can fail. Merely knowing what the users need is often not enough to continue making products that people will want to use and that will serve the company's needs. For research to have a sustained impact on the customer experience, the whole organization needs to understand it, value it, and know how to act on it.

That's a hard sell. The benefits of a user-centered development process are seen as intangible and long term, as an abstract "nice to have" that can be written off when it's time to squeeze out a profitable quarter. But making a user-focused customer experience is not just a long-term strategy that may save a penny here or there; it is a vital short-term process that can create immediate value. Good user experience research takes both the user experience and the company's needs into account, creating a set of needs and constraints that make it more likely to produce a successful, and therefore profitable, product.

Unfortunately, this reticence is not unfounded. Creating an effective user-centered corporate culture is difficult. It's straightforward to have everyone agree in principle to make products "with the users' needs in mind", but it is undeniably difficult to create a development process that is steeped in an understanding of the user while still balancing the needs of the company. Creating a process by which the developers' perspectives are secondary to the users' at every point requires letting go of our innate preference for our own perspective. That's difficult and needs to be done carefully, introducing changes and justifying them at the same time.

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

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?

Warning: I am 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.

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 bottom-line 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 grassroots 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.

What If It's Too Difficult?
None of this stuff is easy, but what if the entrenched corporate culture just doesn't allow integration of usability concepts? What do you do then?

First, identify the nature of the resistance. Resistance comes in two primary forms: momentum and hostility.

People fall into old habits easily. User-centered design takes time, energy, and commitment. Doing things "the old way" is almost always going to be easier, and may momentarily seem like a more efficient way of doing things. 'Well, if we just did this the old way, we could do it in three weeks. You want us to do a month of research first? That’ll just make us miss our deadline even more!' Using near-term efficiency as a pretext for abandoning proper procedures misses the point of the approach. Though gut-level decisions made in the "old school" style may end up being adequate, they are much more likely to cause long-term problems and ultimately create more work.

The way to counter momentum is to build speed in a different direction. As described earlier, a slow introduction of user experience research techniques can be effective when coupled with an internal "marketing campaign" documenting the process's effects on the product and the company. Likewise, an executive commitment to revamping the whole development process can be effective, although it requires more resources and commitment than most companies are willing to expend.

In some cases, though the company buys into the ideas, changing the process in any major way may be impossible in the short run. In such cases, user experience research efforts may need to be justified one at a time.

Hostility is more difficult to deal with, although in some ways an aggressive challenge can allow for a more radical, more rapid change in mind-set than a program of slow subterfuge. Then again, it can be really messy if it goes wrong.

Jeff Veen described the reaction he was met with from one company's staff about doing user research: 'To the engineers, usability was a set of handcuffs that I was distributing; to the designers, it was marketing.' Jeff's solution was to turn it into an event. He made it clear that something special was happening to the company and to the developers: that management was listening to them and really looking carefully at their product. He first arranged for the delivery schedule to be loosened, giving the developers more breathing room and alleviating their apprehension that this process was going to add extra work that they wouldn't be able to do. He then invited all of them to watch the usability research in a comfortable surrounding and with all meals included. As they all watched the interviews together, Jeff interpreted the test for them, emphasizing the importance of certain behaviors and putting the others in context. He also encouraged the developers to discuss the product. After a while, they noticed that they were debating functionality in terms of specific users and their statements rather than principles or opinions.

In certain cases, users threaten people. They call them "lusers", describe the process of making usable products as making them "idiot proof", and approach their users' demands or misunderstandings with derision. Such statements betray an attitude toward the product that's somewhere between arrogance and insecurity. When hostility is especially irrational and obstinate, there's little that can be done about it.

However, direct exposure to users can help convince the doubtful. At first, seeing users fail at something can confirm the doubter's worst fears: that people are unable to use their product and that they're profoundly different and alien. This is really uncomfortable, but it brings home many of the core ideas. Extended exposure almost always reveals that as frustratingly different as users are, their problems and concerns are easier to alleviate than the developers may fear.

Warning: Research paralysis.
When user-centered processes start becoming popular and the development team has bought into the basic processes, there's a tendency to want to make all changes based on user research. This is an admirable ideal, but it's generally impractical and can cause development to grind to a halt.

Don't get distracted by research and forget the product. It's OK to make decisions without first asking people. Just don't make all of your decisions that way.

The Only Direction
However, even if it is difficult to implement this kind of process in your company and it becomes frustrating and demoralizing, it doesn't mean that it will never happen. The ideas behind user-centered design have been floating around for more than two decades, slowly penetrating even the most user-phobic, inward-focused companies. The pressure to create more successful products than your competitor will always be there and user-centered, user research–based methods are one of the best — if not the best — ways to do that. A user-centered company communicates better, makes fewer guesses, solves more pressing problems, and responds better to changes. It is, in short, a company that runs with less friction and a clearer vision.

Such companies may be few today, but there are more of them all the time because there have to be. As the Information Revolution — which only began in earnest in the late 1980s and early 1990s — penetrates societies all over the world, the habits of the Industrial Revolution melt away. With a world where it's no longer necessary to mass-produce and mass-market and mass-distribute products and ideas, it no longer makes sense to think of mass markets. It's no longer necessary to create one solution for everyone based on the limited knowledge of a few. And as economic times get tougher and the bite of competition more painful, companies everywhere learn that good business does not end with the end users of a product or service; it begins with them.


Mike Kuniavsky
"Observing the User Experience"
Excerpted with permission from Morgan Kaufmann Publishers, an Elsevier imprint, copyright 2002. www.mkp.com

Associated Link: Morgan Kaufman

All change at the top for System Concepts
Source: System Concepts Ltd, 3 July 2009
 
Leslie Fountain has been promoted to joint Managing Director of leading usability consultancy System Concepts.

Life in UCD immortalised in fiction: you couldn't make it up
Source: UN, 2 July 2009
 
Sarah Herman's fictitious book on life in a user-centred design company has hit the shelves and The Guardian's book pages...

Interfaces Magazine - Issue 79: The Education Issue
Source: Interaction Group, 1 July 2009
 
The latest issue of Interfaces is now available as a free download from the Interaction Website.

Two new Behavioural research Tools from Noldus
Source: UN, 30 June 2009
 
Tool updates make on-site behavioural data collection easier.

Cell Phones that Listen and Learn
Source: MIT Technology Review, 29 June 2009
 
New software tracks a user's behavior by monitoring everyday sounds.

Top Six Don’ts for Usability Testing
Source: FutureNow Inc., 27 June 2009
 
Six tips for creating quality usability tests to ensure useful feedback from testers.

Usability: ‘Lovely software. But I can’t work it’
Source: FT.com, 26 June 2009
 
In a recent survey by Global Graphics, 77 per cent of office workers estimate they lose up to one hour a week because business software is difficult to use.

And what do you do?
Source: Dexo Design, 25 June 2009
 
How do you describe your job role? Here are the results of a recent 'Preferred UX/UI Title' Poll.

Most Doctors cite Usability as critical to Electronic Health Record Adoption
Source: TMCNet, 24 June 2009
 
It's all about 'meaningful use'.

Glossy monitors look good but can hurt
Source: QUT, 23 June 2009
 
A new advisory cites research which suggests high gloss monitors make users sit awkwardly.