"All interactions magazine articles are posted with the permission of ACM."
© 1998, Association for Computing Machinery. Permission to make digital/hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication and its date appear, and notice is given that copying is by permission of ACM, Inc. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
Reprinted with permission from interactions magazine, 5[2], 16-20, March/April, 1998.
The paradox of "vision"
User-centered design (UCD) provides a comprehensive vision of an alternative design process, involving different activities, practices, and methodologies appropriate for different phases of system development. In our experience, despite the growing awareness of such things as the importance of good user interface (UI) design, usability, and User-centered design (UCD) practices, it is extremely rare that companies adopt a fully integrated UCD approach in one grand strategic shift. Rather, companies tend to adopt UCD practices and methods in a stepwise fashion, adopt a particular method or practice only when a complex set of factors line up to create readiness. Usually, the motivation comes from a combination of painful lessons and glimpses of possible solutions. Furthermore, it is difficult to tell in advance whether a methodology adopted by a particular development team will be a one-time event, or whether it will serve as a precedent within the company, moving it along a progression towards a UCD culture.
This can be frustrating to UCD enthusiasts. Like all "visionaries," UCD believers see clearly the weaknesses of isolated problem-solving efforts that are not tied together by an overall guiding strategy: difficulty coordinating separate actions, a tendency to reinvent the wheel, and a "putting out fires" mentality. Plus, of course, they see the beauty of their own grand vision. There is no question that vision is one component of effective leadership and change management. However, over-emphasis on vision can get in the way of change when corporate activities that focus on vision are disconnected from the current work in progress. Unfortunately, this is all too common.
What happened at Very Big Industries
Imagine the following scenario at Very Big Industries, Inc. (VBI):
As they struggle with their day-to-day tasks and challenges, a group of workers at VBI hear about the importance of UI and start to learn about UCD. They read a book, they go to a conference, perhaps CHI, or they pick up interactions , and they begin to form ideas that go beyond the immediate problem of getting this release out by the end of next quarter. They perceive their current difficulties in designing UIs as embedded in patterns, and in the development process they are using for the UI. They try to locate the source of their problems with design, identify patterns of behavior in the organization that they feel contribute to them, and imagine ways in which things could be different and better in a general sense. They talk at lunch about how it could be (or how they hear it is at another company).
After a period of time discussing these patterns and envisioning changes, during which their talk comes perilously close to sounding like complaining, someone in VBI's management hears about this, and organizes them into a task force . How much commitment that individual really has to the issue may not be clear. Nevertheless, the task force devotes a great deal of time to formulating their assessment and proposing changes. Although they are not necessarily sure of who their customer is (i.e., who is seeking their input in order to take action), sometime after the original deadline has passed, they offer their conclusions.
While they have been hard at work identifying ways that UI work could be done differently using UCD, things have not exactly been put on hold elsewhere at VBI. Their coworkers have continued to their work on current projects, including designing UIs without the benefit of the task force's findings. Meanwhile, since redesigning the organization or the work process was not part of the task force members' core jobs, and their own projects have lagged somewhat as they took time for their task force work, their "productivity" has suffered, and the original pressures to produce have only increased. Since they do not have the authority -- or the time -- to implement the changes they proposed, their recommendations are not acted on. Eventually, they are pulled back to their "real" jobs of designing the next release, feeling somewhat irrelevant, and with the perception that nothing has changed except their own morale.
The relationship between vision and change
Their experience may not reflect any pathology in the company, so much as it reflects an inherent difficulty of managing the relationship between developing a vision and the concrete changes it calls for. A vision does not substitute for a strategy. Developing a vision does not tell you what to do next. The process of considering changes and proposing new patterns of behavior (or new ways of designing) is not the same as the actual migration to a new work process. These are fundamentally different activities, and they do not tend to get along that well.
When people are devoting the bulk of their time and energy to solving immediate problems, time spent focusing on vision can be seen as a distraction. Even when the vision advocate thinks that the vision, if implemented, will make life easier for everyone, other workers, the ones who have to implement changes, are rarely as excited about the changes. They know that shifting to a new way of working while maintaining current production likely means more work, at least in the short term. It's hard to hop on the bicycle while you're pushing it uphill.
Corporate activities that focus explicitly on a general vision disconnected
from current work can arouse suspicion, because it seems to get too far away
from solving "real" problems and starts to sound like another buzzword, management
enthusiasm, or fad. If workers feel as though the changes they are being asked
to make are driven more by the visionaries' passion for their own idea, than
by any specific, objective benefit, it is natural for them to mistrust the change.
What is worse, they may fear that the promoters of the change will be blind
to the objective data as they attempt to implement change, and therefore may
mismanage it. Many people have had experiences of well-intended corporate initiatives
taking time from their current work without producing recognizable benefits,
or making life more difficult, even if they sounded great. Some people have
even left the corporate world to devote themselves to writing comic strips about
the phenomenon.
Using vision to bring about change
People experience the strongest motivation to implement change not because it fulfills an elegant new vision, but because, at a particular time, they perceive that a specific new method or approach may solve a pressing, immediate problem. We would not dream of suggesting that vision is unimportant. What we are suggesting is that the test of a vision is two fold. A successful vision is one that facilitates solving specific problems and helps bring about specific improved results, at the same time that it shows how these separate problem-solving efforts can build on each other, and cumulatively move the company in a new direction. When people perceive that the emphasis is placed too heavily on the "new direction," and not on what will help them now, they naturally balk. The key is to link vision to actual current practice. While this seems like it should be obvious, it is amazing how infrequently it is actually done.
To this point, we have focused on the relationship between vision and change, irrespective of content area. But what about the specifics of UCD? The challenge of connecting vision with concrete changes tends to arise at a particular point in the progression to UCD.
Steps to UCD
We have found that many of the companies we have worked with have gone through a sequence of steps on their move towards UCD. Your company may be different, because there is no set progression. Some companies, like VBI, do start their formal efforts with attempts to articulating an overall UCD process. Others start with training. Perhaps more commonly others begin on the UCD path by trying to deal with a problem or disappointing results with a particular product. Perhaps the customer has refused to accept a customized product because of usability concerns, or sales of a commercial release have been lagging. Sometimes, there are disputes about the UI within the development team as a new product approaches release. Whatever the cause, the UI is implicated. Concern grows over time, and at some point, becomes urgent. Something must be done.
This is the point at which many companies call in a consultant to look at the system. They may ask for an expert or heuristic review. Or, they may do their first usability evaluation. It is almost inevitable that this first experience with usability evaluation happens too late in the development process to actually have much influence on design. Things are too far along, and roll out may be literally next week. This seems to be the fate of first usability evaluations.
But even if the evaluation is too late to have a significant impact on design, this experience often opens a company's eyes. They begin to see not only the problems with the current UI, but also become aware of the problems with the development process which resulted in this UI, and they begin to move from trying to fix a particular product to seeking general changes in their overall process that will reduce the chance of similar problems occurring in the future. While this is clearly a progressive step, it is at this point that the pitfalls of abstract vision arise.
Common activities at this point include the development of tools intended to be applied broadly, like UI guidelines or a corporate UI standard. Others activities include the delineation of a UCD process, or the incorporation of UCD principles into a standardized, corporate system development methodology. These activities inherently shift attention to a more abstract level. They all involve looking at UCD in an idealized manner, and detached from development work in progress in the company. This separation may even be institutionalized as a matter of corporate policy. Studying the development process and proposing general process changes may be considered to be R & D. Funds are sometimes budgeted for R&D separately from project moneys, and, funds designated for such efforts cannot, therefore, be used to support projects. If the two are organizationally separate (as they are in most companies), there may not even be an opportunity to know that work potentially of interest to development is occurring in R&D.
What can you do?
Fortunately, there are a number ways to link UCD vision and practice, to keep the change process grounded in reality and increase the chance of success. Below are examples of ways that some companies have found to do this in their own organization. There is definitely not a "one size fits all" solution. These approaches had to fit the specific organizational environment. The key is understanding both UCD and the culture of the organization to find a strategy which will effectively work in the "real world" of a particular company. Note also that, in each case, a combination of strategies was used. Here are some of the approaches that we have seen work at different companies:
Certainly, it is often important to insulate people from the day to day pressure of production in order to allow them to think as creatively as possible. Some of the most innovative, far-reaching ideas may emerge from an internal think tank. Just remember that the vision that emerges from the think tank, such as a proposal for a new development process, is only part of the change map. It may define an ideal target, but strategic management and leadership is still needed to pick the right change intervention at the right time. Just be aware that as that your next step will have to be the development of a migration plan.
If your company is one of the few with the resources and sustained focus to conduct a multiphase UCD planning process, great. But for most, it is more realistic to try to find ways to make the change process overlap and synergize with development work in progress.
It can also help to remember that the essence of UCD is highly iterative contact with the user. Just as UCD of a UI requires that developers be in close contact with their users, the design of an improved UI development process requires close, ongoing involvement of users of the process, i.e. developers. This does not just mean including developers on a task force (any more than UCD of UIs should be reduced to just including users on development teams). It does mean finding high leverage roles in the change process for key stakeholders and finding ways to introduce new methods into current work in progress. Ensuring a connection between the vision of change and work in progress will make it more likely that the changes will in fact be useful and realistic, that they will be accepted, and that UCD will move beyond abstract concept to become "standard operating practice."