Once you have some people to talk with, develop CONCRETE, DETAILED EXAMPLES of tasks they perform or want to perform that your system should support. Here's how this went for Clayton and colleagues in a recent project, disguised to avoid embarrassing anybody.

The aim was to develop a system for modelling traffic: street layout, traffic volumes, accidents and the like. The system was to provide a flexible, graphical interface that would make it easy to tweak the model and examine the results. We had good access to potential users, because the project was sponsored by an organization that included people who currently use an existing model that the new one was to replace.

But there was a delicate issue here, that you will often face. The particular people providing money for the project were not the users themselves, but a staff organization whose mission was to look after the needs of the users. Sounds OK? It's not: it meant that our direct contact was not with the people who really know firsthand what the problems are but people who are supposed to know the problems secondhand, a very different thing. Fortunately we knew what we wanted and were able to arrange a series of meetings with real users.

In these meetings we developed a list of twelve things the users would actually want to do with the system. They were specific, as for example:

It says what the user wants to do but does not say how the user would do it.

As stated, this task does not make any assumptions about the nature of the modelling tool or its interface. Therefore it can be used to compare different design alternatives for the system and interface in a fair way. If we said "change the speed limit by selecting a new value from a menu" we would have prejudged the right way for the user to perform this part of the task.

Not only does it say exactly what the user wants to do, it actually specifies particular streets. What's the point of this? It means that we can fill out this description of the task with any other details that may become relevant in evaluating designs. In fact, it forces us to do this. For example, if the model needs to divide streets into separate pieces for purposes of analysis, and the user then needs to select a number of pieces to do an analysis for a stretch of street, we can see in detail how this would work out for the real Canyon Boulevard. We can't avoid the problem as we could if we were thinking of any old generic street.

Dennis Wixon has an example that makes this point (In M. Rudisill, T. McKay, C. Lewis, and P.G. Polson (Eds.), "Human-Computer Interaction Design: Success Cases, Emerging Methods, and Real-World Context." Morgan Kaufman. In press.). Wixon and colleagues were developing an interface for a file management system. It passed lab tests with flying colors, but bombed as soon as customers got it. The problem was that it had a scrolling file list that was (say) twenty characters wide, but the file names customers used were very long, and in fact often identical for more than twenty characters (the names were made up by concatenating various qualifiers, and for many names the first several qualifiers would be the same.) Customers were not amused by needing to select from a scrolling list of umpty-ump identical entries that stood for different files. And this wasn't an oddball case, it was in fact typical. How had it been missed in the lab tests? Nobody thought it would matter what specific file names you used for the test, so of course they were all short.

Note that the task doesn't just say to fiddle the speed limit on Canyon, or just to calculate projections for Arapahoe. It says the user wants to do both. This means that in seeing how this task plays out for a particular design of the interface we are forced to consider how features of the interface work together, not just how reasonable they may look separately.

We once evaluated a phone-in bank service that had done well in lab tests. People had no trouble checking their balances, finding out if checks had cleared, and the like. But when we looked at what was involved in finding if a check had cleared AND THEN looking at a balance, we found big problems. The interface was supposed to support this kind of transition between functions, but the test tasks used in the lab had not required them.

Describing complete jobs is a key feature of our approach, and it's different from the usual way of doing things. Usually requirements lists are just that: lists of little things the system has to do. Meeting this kind of requirement does little to ensure that users can do a real job without going crazy: it just ensures that they can do all the PARTS of a real job.

An important angle on the complete job issue is seeing where inputs come from and where outputs go. In the example problem, where does the model the user is going to tweak come from? How does he or she obtain it? If there aren't good answers to these questions the system will be no good in practice, even if it does the tweaking and calculating parts very well.

Clayton worked on an early business graphics package whose sales were disappointing. Customer visits (done after ship, not before development when they should have been done) showed that the problem was that the package worked well when users had numbers to type in to make a graph, but badly when numbers were already in the system and needed to be extracted from a file. One user had temporarily hired typists to transcribe numbers from one screen, where a data file was displayed, onto another screen where the graph package was running. He was not eager to continue this arrangement. The majority of uses we saw were of this get-data-from-a-file kind, so the system was unsuited to requirements even though it did a good job on making the graph itself, the part of the whole job on which the designers concentrated.

So you want to choose tasks that represent complete jobs, and you want to be sure to scrutinize the edges of the tasks. Where does stuff come in from? Where does it go? What has to happen next?

In the highway example we were dealing with a small, close- knit group of users, so we didn't specify in our example tasks WHO would be doing what: we took it as given. Probably we should have worried about this more, and probably you should. The success of a design can be influenced strongly by what users know, how the tasks supported by the system fit into other work they have to do, and the like. So you need to get a fix on these things early in design.

The design of Oncocin, a sophisticated cancer therapy advisor, illustrates what's at stake (Musen, M.A., Fagan, L.M., and Shortliffe, E.H. "Graphical specification of procedural knowledge for an expert system. In J.A. Hendler [Ed.], "Expert Systems: The User Interface." Norwood, NJ: Ablex, 1988, p. 15). Earlier experience with doctor users had shown that they are willing to invest very little time in becoming familiar with a new system. A system to be used directly by doctors therefore has to be different from one to be used by medical technicians, who can be told they HAVE to learn a new tool. The Oncocin designers needed to decide up front whether their users would be doctors or would be technicians working in support of doctors. They went for direct use by doctors. The interface they came up with is as much as possible a faithful copy of the paper forms for specifying therapy that doctors were already using.

So what should you say about users in specifying your tasks? If possible, name names. This allows you to get more information if it becomes relevant, just as saying it's Arapahoe Avenue allows you to bring in more detail about the task if you need to. Beyond that you should note characteristics of the users that you already know will be important, such as what their job is and what expertise they have.

In choosing the sample tasks for the traffic modelling system we were guided by two objectives. First, we wanted to be sure that we had examples that illustrated the kinds of support that we as designers thought the system should provide. That is, we had some general ideas about what the system was supposed to be good for, and we tried to find tasks that were examples of these. But second, we needed to reflect the interests of potential users in the examples. So we tried to find tasks that illustrated proposed functionality in the context of work users really wanted to do.

In the process some possible functions for the system dropped out. We had envisioned that the system might include some optimization functions that would manipulate the model to find the best of some range of alternatives with respect to some measure of quality. Users had no interest in this. They preferred to solve such problems by framing and evaluating alternatives themselves rather than having the system do this.

This is not an uncommon conflict, and one without a simple resolution. We thought, and still think, that users would eventually come to want optimization functions once more pressing modelling needs were met, so we didn't want to just take the users' word on this. But we put optimization on the back burner to be pushed again in the future.

This illustrates a key point about input from users: users are NOT always right. They cannot anticipate with complete accuracy how they will use new technology. As a designer your job is to build a system that users will want when it gets here, not to build the system users say they want as they see things today. You may well have insight into the future that users lack. But you need to be very careful about this. If you are like most designers, an outsider in the domain of work you are trying to support, you have to recognize that users know a whole lot more about what they are doing than you do. If you can't get users interested in your hot new idea, however hard you try to draw them into it, you're probably missing something.

HyperTopic: Participatory Design

In our discussion we have been assuming a split between the roles of designers and users that has been traditional in U.S. system design. Designers are not users; they gather information from users and reflect it in systems they build; they give these systems to users who use them or not. There is an alternative approach, pioneered by workers in Scandinavia, that rejects this structure. In participatory design, systems are designed by designers and users working together: a slogan is DESIGNING WITH rather than DESIGNING FOR. The power to make the system be one way rather than another is not reserved for the designers, as it is in most U.S. design practice, but rather is shared by designers and users working in collaboration.

The contrast between participatory design and standard U.S. practice reflects deep differences in political and philosophical outlook between Europe and the U.S.. Most European countries give workers very broad influence on working conditions, which are much more strictly regulated than in the U.S.. In many countries workers must have seats on the boards of directors of companies, and workers must be consulted on the introduction of new technology in the workplace. With this view of workers it is natural to think that workers should have a direct hand in shaping the systems they have to use. By contrast the prevailing view in the U.S. is that management should just decide what systems are good for productivity and then impose them on workers, whose views basically don't matter.

Many people in the U.S., if they think about these matters at all, assume that the U.S. way of doing things must be right. What is your reaction when you hear that in some European countries it is illegal to make someone work in a room without a window? Does that seem silly, or maybe wrongheaded, because of the restriction in places on freedom of enterprise? What do you think about it when you also learn that a number of countries in Europe have higher per capita productivity than the U.S., and that the U.S. is steadily losing export position, especially in advanced industries, and holding its own primarily in commodity exports like farm produce? For a fascinating, disturbing, and constructive look at these and related issues, read the book "The Competitive Advantage of Nations," by Michael Porter (New York: Free Press, 1990).

You can find a lengthy discussion of participatory design in the journal Human-Computer Interaction, (Floyd, C., Mehl, W.-M., Reisin, F.-M., Schmidt, G., and Wolf, G. "Out of Scandinavia: Alternative approaches to software design and system development." Human-Computer Interaction, 4 (1989), pp. 252-350), and a short and sweet discussion in an article by Jeanette Blomberg and Austin Henderson of Xerox in the CHI'90 proceedings (Blomberg, A.L. and Henderson, A. "Reflections on participatory design." In Proc. CHI'90 Conference on Human Factors in Computer Systems. New York: ACM, 1990, pp. 353-359). Blomberg and Henderson stress three defining attributes of participatory design: the goal of the activity is to improve the worklife of users (not, for example, to demonstrate how neat object-oriented technology is); the activity is collaborative, with all goals and decisions actively negotiated and not imposed; the activity is iterative, in that ideas are tested and adjusted by seeing how they play out in practice.

It's pretty easy to see how one could approach participatory design in in-house projects, though it would not be easy to get your organization actually to do it. For in-house projects it will be true at some level that designers and users share the same goals, though in the U.S. context these goals may not have much to do with the quality of worklife. But U.S. organizations usually have job demarcations which make it hard to get participatory design going. Usually, if my job is to be a user it is not to be a designer or to work on designs. That's the province of "experts" employed for the purpose, even though they have no idea what the real problems are that need to be solved.

For commercial projects there are further challenges. At bottom, your objective as a commercial developer may really not be to improve the quality of somebody else's work life, but rather to make money for yourself. So you don't have the right goal to begin with.

There are two ways to go from here. One is to forget about the defining goals of participatory design and go through the motions of it in service of your selfish goals. The idea is that you hope to produce a better design, and hence make more money, by engaging users in collaboration focussed on the user's goals. To draw users in to making the considerable investment of time they would have to make to work with you, you would offer them a piece of the action.

Developing new technology in close partnership with potential users like this is a good idea in many industries for lots of reasons not restricted to the peculiarities of user interfaces. As Michael Porter recounts, the modern printing press was developed by a new technology company that was supported by some of its potential users, big English newspapers. Such a relationship gets you the information you need to make your system really useful, and hence successful, as well as developing an early market.

Another response to the mismatch of your goal of making money and the participatory design goal of improving the quality of work life is to change your goal. Will money actually make you happy? Of course not. Will improving somebody's work life make you happy? Maybe so, if the work involved is itself something worthwhile, or if you just take satisfaction in doing something well. Even if you can't get this unselfish the logic of the situation is that you may do better all around, including monetarily, if you really care about the people who will use your system and what they do than if you only care about the money.