Last Updated: 5/13/97

Some Notes on Appropriation, Accounts, and Coproduction

by Dave Curbow


The following note describes the concepts of Appropriation, Accounts, and Coproduction. I'm particularly interested in how these concepts might be incorporated into products.


People don't like being forced to do something in a prescribed manner, we often improvise. Appropriation describes how people designate something (a tool, a machine, some software) to be used in a particular way. We're interested at facilitating unintended uses. For example, if a ladder isn't handy, a user may stand on a chair to replace a lightbulb. The user was improvising and appropriated (or repurposed) the chair to a different purpose.

As a result of appropriation such as this, chair designers have to consider how their chair may be be used other than for sitting -- and design accordingly. A user who has bought a new television may look at a chair and decide it would make a good support to hold a new television (instead of using the traditional milk crate -- a different appropriation.) It is unlikely that the chair designer will anticipate her chair supporting a television, but the designer of milk crates might anticipate this usage because that particular appropriation has become common. Of course, it is up to the user to decide if the chair or milk crate would work better for this purpose.

As a designer of user interface software, I look for ways to make software flexible, robust, etc. so that it can be used in different ways, or be appropriable. Unfortunately, today's software tends to be very inflexible.

Recent work suggests there may be ways around this inflexibility. For example, by an architecture that allows software to be accountable and supporting coproduction. There may be other ways as well. Now I'll describe how software is accountable and coproduction.

Note: you may consider this to be software reuse. However, usually only developers can reuse, or repurpose, software. We're interested in providing this ability to users.

Accountable Software

Being accountable means that the system was designed so that it reveals, as an intrinsic part of its behavior, what it is doing, how it is doing it, and why it is doing each operation. For example, when a user drags a folder from your desktop to a file server icon, the system copies the folder. Often there is a simple dialog telling the user how much remains to be done. However, sometimes the user wants to know more details about what's happening, for example when the system isn't responding as quickly as the user believes it should.

If a system is accountable, it will provide the user with information about the copy and allow the user to ask for more or fewer details. The system would also allow the user to interact with the task in real-time, for example by allowing the user to specify which files should be copied first.

This is more than just putting up a few status dialogs -- it's the idea that the user should always be able to ask "what is going on?" and getting an appropriate answer. What is appropriate for one user may not be appropriate for every other user, so the system must be flexible enough to allow the information to be presented in more than one way.

Also required, is the ability to provide an explanation. For example, the user may not know what a term, such as "internet" means in an error message. Being accountable means that explanations will be given as requested.

If you'd like more information on being accountable, my colleague Paul Dourish, has written an excellent paper. [A paper on Accounts]


Coproduction is the idea that the system is designed to work WITH the user -- each doing what it does best. People and computers are good at different activities, coproduction allows the user to leverage the computer's strengths. Today's computers are commanded to do an operation, such as copy a file, and the user has little control over it. If the system allowed the user to modify the behavior of a command in progress, that would be coproduction. For example, when the folder is being copied to the server, the user may decide to cancel the copy. That's a simple example. A more compelling example would be if the user were allowed to tell the system to finish the copy later, or to only a particular set of the six files remaining to be copied.

You can see that coproduction depends on a system being accountable, but it goes beyond being accountable.For example, suppose that a user prints a particular document often and always using the same set of options. A system that is coproductive might notice this and ask the user if they'd like this set of options to always be used for this document, unless otherwise specified. If the user agreed, in future the print dialog would be filled out with the correct options. Or, the system might go further and not even present the dialog, but provide a mechanism for the user to ask for the dialog when desired.

Back to Pliant Research Home Page