What If It s Too Difficult?


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 (as described in Chapter 17). 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.




Observing the User Experience. A Practioner's Guide for User Research
Real-World .NET Applications
ISBN: 1558609237
EAN: 2147483647
Year: 2002
Pages: 144

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net