Tom Erickson
  home •• pubs essays  HCI Remixed HICSS PC patterns  Apple Human Interface Alumni page



This is one of a series of essays written for a seminar in Genre Theory in the spring of 1998.


Images and Prototypes as Workplaces

Tom Erickson

1998

I was struck by the notion, invoked in the Amann and Cetina article, of the image as a workplace. They argue that the process of 'seeing' an image -- a process fraught with troubles -- is interactively accomplished through conversational talk. What is seen is negotiated as a consequence of talk, and the talk itself is attached to and organized by the image. The authors note that because of the difficulty of interpretation, difficulties are not resolved once and for all but instead are visited and revisited. And they discuss some of the conversational strategies that are evoked 'within' the image: trying to understand how features of the image relate to the process which produced it (procedural implicature); trying to understand what the features actually are and how they relate to one another (optical induction). And they also note the use of adversarial moves to open new areas of inquiry, which result in revisiting various features of the image.

(Aside: As in a previous essay (on the role of theory), I find myself noticing a correspondence between the concepts of image -- at least in the scientific domain -- and genre. Is an electrophoresis gel -- or at least an image of it -- an instance of a genre? It has certain regularities of form and substance: probes, markers, starts, etc. And these regularities -- which are what make the image analyzable -- arise from an underlying situation, i.e. a carefully produced by an experiment that is a socially constructed entity. Because the image is analyzable, it organizes talk around itself, and furthermore, the talk contains certain types of conversational moves. And finally, it seems like something akin to structuration is happening: what is 'seen' in the image is negotiated through talk, and the talk in its turn is structured by what is seen in the image. Have I fallen into the typical trap of the initiate to a new conceptual system seeing everything in terms of genre theory? Or have I just become sensitized to the fact that talk is always inextricably embedded in its context, and that there is a structurational interplay happening between people and artifacts (material, informational or social) at all levels?)

Let me return to the notion of the image as a workplace.

I think the phrase interests me because one way of describing my job is that I construct 'images' of non-existent things and invite people 'into' them for conversation. That is, I do my work by building what we call 'prototypes' of potentially-buildable technological systems. Over the course of my career I've created prototypes of digital newspapers, hand-held wayfinders, and electronic notebooks. And while these prototypes play a number of very different roles, one of their most important functions is to elicit conversation. In particular, one of the most important and difficult of my tasks is to get 'ordinary people'* to imagine how they might use a prototype, what aspects of it might assist (or hinder) them in achieving their ends, how it might fit into their work practices and lives, and so on. (* "Ordinary people", often referred to in my profession as "users", is a rubric for people who don't care about technology for its own sake -- they are interested in it only insofar as it helps them accomplish their own ends.) So let's focus on this use of prototypes.

I'd now like to reveal some 'practitioners lore' about how to create prototypes that succeed in getting ordinary folks to talk productively about them. A common mistake that beginning prototypers make is to make the prototype as complete as possible. They try to make it look and feel real -- typically, in my field, this means that you have a program running on a computer. When you type on the keyboard, click the mouse on the buttons (or push actual buttons if its a gadget), things happen: the cursor moves, windows appear, beeps sound. Ideally (in the novice prototyper's view) it looks just like the ultimate product might look. This, in and of itself, turns out to be a bad thing. And even worse, because the prototype is supposed to represent some new, promising object, it is designed to look really cool.

Why is this bad?

It's bad because it leaves few openings for conversation. First of all, every detail is there. The windows are perfectly rectangular, the menus have text in them, the buttons have shape and color. It's all done. And in fact, confronted with a prototype like this, most ordinary people have little to say. Typically, they'll give suggestions about window size, the names of menus, and whether the buttons should be oval or rectangular. This is a long way from finding out how they might use the product, or what difference it would make in their lives. If the prototype looks cool, it only exacerbates this problem. Not only do people focus on the details, but because the prototype looks like its makers lavished years of attention on it, people are reluctant to criticize it at all. Since a good rule of thumb in prototype evaluation is to never believe anything complimentary that people say, you're left with nothing at all.

The expert prototype does things differently. In the early stages of design, low-tech media are preferred. Paper sketches, index cards, sometimes supplemented with marked-up post-its for dialog are the preferred medium. If you're making a gadget, foam board with stick on buttons and the occasional post-it is the way to go. Later on, when one needs to begin to experiment with more realistic forms of interaction, more pains must be taken. Screens and dialog boxes are hand-drawn on paper, and are then scanned into the computer and assembled into interactive slide shows. The goal in all of these cases is to make the prototype look rough, as though it were tossed together in half an hour or so (ironically, the scanned-in hand-drawn prototypes are far more time consuming to construct than the great-looking realistic prototypes.)

Why the emphasis on roughness? Again, the goal is to encourage conversation. First, people are much more willing to criticize and suggest alternatives if the prototype doesn't look as though someone spent days perfecting it. Ideally, the prototyper, talking with the ordinary person, will say, 'Oh, yeah, we just threw this together to be a bit more concrete. Pay no attention to it.' And it works remarkably well. Meek people will rip a rough prototype to shreds (figuratively). A second advantage of this method is that you can leave things out. Don't know what to name a button? Leave the name out. Don't know what shape it should be? Just draw a blob. If the ordinary person inquires, the wily prototyper says (often with complete honesty), ' I dunno what shape it should be. What do you think?' But more often the lack of detail and the presence of ambiguity creates a lot more room for talk.

What I find interesting in all this is a set of almost-parallels between the scientists' images and the designers' prototypes. The image is a projection of an object that exists; the prototype is a projection of a purportedly to-be-designed artifact. Both image and prototype serve to elicit and structure conversation. And, in both, missing and ambiguous features serve to enhance the conversation. If I were designing a scientific image to encourage debate, I'd certainly design something that looked messy and ambiguous, like the unedited picture of autoradiographic film (exhibit 1 in A&C); and if I were trying to suppress debate and produce agreement, I'd clean it up, so it looks a like the montaged autoradiographic diagram (A&C's exhibit 4). Finally, it's interesting to note that what makes prototypes look rough is that one can look at them and make inferences about the manner and care with which they were produced (i.e. what was procedural implicature in the case of scientists and their images is made visible, and becomes something like procedural induction in the case of prototypes).

#

 

Tom Erickson

home ••• pubs essays  HCI Remixed HICSS PC patterns Apple Human Interface Alumni page •