No Section...

VII.2 March-April 2000
Page: 74
Digital Citation

Commentary


Authors:
Austin Henderson

Engagement of design with use

The authors of the contributions in this special section seem to agree that design and designers need to be involved with users in one way or another. Some say, "Consider your customer," arguing that you are not your customer, and although you may empathize with them, they will see it differently than you do. Or, "Engage them to find out what they want/need," where engagement may involve talking to them, running user tests, or observing them at work/play. Or, "Consider the purposes to which your product is being put," arguing that there are many different goals that products meet, and therefore different requirements in the design, and different ways to evaluate the results in action. Or, "Get the user to design the product, or at least help you in doing so, since they really know their activity."

Now the further one goes down this path of engaging the user, the more expensive the design project becomes. The argument has been made many times that expending this effort is just good business: Engagement with use pays for itself by helping to get the product right the first time. Or getting it wrong faster so you can ship something better sooner. I agree.

Another reason for engaging the user is that user engagement contributes to diversity, and diversity engenders better design. Many briefs also emphasized the benefits of design by diverse teams composed of people from many disciplines, with their different perspectives, experiences and values. Again, I agree.

But diversity, while yielding better results, necessitates learning to work together. For many, that means sitting in rooms talking to each other, or at each other, or past each other. One design effort I was involved with died a painful death because of such "talking past." But by contrast, my first encounter as a computer scientist with an anthropological perspective—which could have resulted in a serious crashing together of radically different viewpoints—was profoundly effective, because our work was done around and about an adequate record of real human activity. Lucy Suchman and I exchanged and understood each other’s views effectively because there was something full-bodied that we could refer to as a ground for solid contact. Cross-perspective teams work better in the world of real activity than they do in worlds of composed and conflicting abstractions. So get real! As these briefs describe, designers have a wide range of processes for engaging the user. It’s hard work, but worth it.

There also seems to be strong agreement that design is a cycle, although everyone has a slightly different take on it. The cycle is made up roughly of: understand (do your homework), observe (interact with reality), design (visualize and evaluate), implement, and test. With iteration, of course. What differentiates briefs from each other is what they iterate over, and in particular whether implementation is involved in the design process, which seems to depend on how hard it is to implement the thing you are designing. Hardware and software-dependent stuff (networks, operating systems, and applications) take massive efforts to build, so most of the design iteration happens without implementation. To engage users in this design iteration, all sorts of partial measures are substituted for the real thing: mockups, simulations, prototypes. Tools must be able to quickly produce substitutes good enough to stand in for the real thing in testing with users.

It’s interesting that some folks don’t have that problem, or don’t have it as badly. Some design teams have implementers as part of the team. UER at Xerox is the clearest example of design iteration with versions of the real thing, coded—probably partially—by clever people at lightning speed. Product design firms are experts at making it run well enough to see if it is right.

For interaction, the needed tools are programming languages and supporting environments in which working prototypes can be built very fast.

Of course, the really well-positioned folks these days are those building Web-based stuff. HTML and Web site design tools can be used by the design team directly to implement their ideas. Further, they can iterate very quickly: They can just test it with some users by simply serving it to them. Suddenly the loop is not only much faster, but it also includes the users, and it includes them in their real activity in the midst of life. Use has been much more immediately engaged by design.

Swift implementation can lead to confusing design iteration with shipping the product. Here discipline has to be reasserted. Just because implementation can go quickly does not mean design can go quickly. Again, designing for the full needs of the user requires iterative evaluation and redesign. Faster ways of working with Web users are under development, but the process still must take place. We still can’t get it right the first, or even the second or third time.

Discipline is needed for something else, too. In the longer design cycles of operating systems and applications, there is time to reflect. At the end of the cycle one can pause to review what has happened and learn from it (UER’s post mortems); or at the beginning of the next cycle one can engage in the fun exercise of designing without constraint that many briefs mention. However at Internet speeds, reflection within the cycle is often squeezed out. Discipline is required to lift reflection out of the cycle. Rather than something done only in breathing spaces, reflection must be made into a coordinated on-going process.

Of course as Web pages and servers become more complex and code creeps back into them (CGI, Javascript, Java, C again), these light feet again will become mired in software. Iteration will slow. Design will again become disconnected from use. And the need for guessing right in design will again become important.

Change compounds this dilemma. Use, the thing we are designing for, is not standing still (fortunately for users, unfortunately for designers). Use is constantly being made, produced again and again in every occasion of human activity involving technology. The socio-technical practice shifts and drifts. This further accentuates the tension between difficult-to-change technology with its need for disconnected design, and easy-to-change technology that can be simply built and tried.

There is, however, a more radical hope. The best place for design to engage use is in the process of use itself. Allison Druin imagines her young users making things out of wonderful computational material. I believe that Allison has it exactly right, and I want that for everyone, not only those kids. When things don’t work, users should be able to put on their design hats, and push things around so the technology does what they want. Think of all the other technologies I can do that with: I don’t have to wait for a new version of the piles of paper on my desk, or get designers to change the utensils in the drawers in my kitchen, or run a user test on my filing cabinets. I do all of that design in the act of use. Although users can shape their filing systems it is only in ways the designers of desktops anticipated. What hasn’t been anticipated can’t be done. If the software believes that people have first names and middle initials (I don’t, and much of the world doesn’t), I have no hope of changing it. The designers set the terms of interaction, once and for all.

Luckily, software is not only about information, it is information. It can work on itself, if appropriately designed. We should be building systems where users can define the terms of the activity the systems support.

When users can shape systems, design will have engaged use in its fullness by becoming part of it. Instead of incorporating only a single view, the software will be able to take on many views for different users or even the same user at different times. The debates that take place in design teams as to how things should be will be handed over to the users to work out with each other. In this, however, they will not be striving to reach a single answer, but rather multiple answers that are coherent enough with each other so that the whole socio-technical practice they are engaged in can continue in a changing world. And this design will be done not merely as an interesting end, but as an integral part of our activities.

However, if design goes into the hands of users, what will be the job of designers? As I see it, they will still be designing in two critical ways: They will have to provide users with good designs from which to start, just as they do today. And they will have to design for users continuing the design of their systems with everyday skills.

In the end, the subject matter of design will become users designing as part of use. This is the ultimate engagement of design and use.

Author

Austin Henderson
Principal, Rivendel
Consulting & Design, Inc.
henderson@rivcons.com

Figures

UF1Figure. Austin Henderson

©2000 ACM  1072-5220/00/0200  $5.00

Permission to make digital or 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 and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2000 ACM, Inc.

 

Post Comment


No Comments Found