Designing for Appropriation

Alan Dix

Lancaster University, UK

Abstract

Ethnographies often show that users appropriate and adapt technology in ways never envisaged by the designers, or even deliberately subverting the designers' intentions. As design can never be complete, such appropriation is regarded as an important and positive phenomenon. However designing for appropriation is often seen as an oxymoron; it appears impossible to design for the unexpected. In this paper we present some guidelines for appropriation based on our own experience and published literature and demonstrate their use in two case studies. You may not be able to design for the unexpected, but you can design to allow the unexpected.

Keywords:appropriation, hackability, tailorability, guidelines, human-computer interaction

Guidelines for Appropriation

allow interpretation

Don't make everything in the system or product have a fixed meaning, but include elements where users can add their own meanings. For example, in MacOS you can associate colours with file, but there is no fixed meaning to a red file (maybe urgent, or problem) – it is the user who provides the interpretation. Similarly, in MacOS folders and Windows desktop you can position file icons freely. Because location does not mean anything to the system, the user is free to group files; perhaps have one corner of a folder window means "finished with". Similarly in a database system, a simple free text comment field allows users to add details the designer never considered, just like writing comments on a paper form.

provide visibility

Make the functioning of the system obvious to the users so that they can know the likely effects of actions and so make the system do what they would like. This is particularly important when the effects of actions are distant or at different time, for example in a collaborative application. Often systems, particularly networks, try to cover up or hide the underlying 'details'. This is fine so long as it is totally and permanently hidden, but often the details leak out (e.g., at the limits of wireless coverage). Users find their way round these problems if they are made clear (signal level bars on a mobile phone allow you to find better signal). The notion of 'seamful' design [3] deliberately exposes these 'seams' in coverage and connectivity in order to create games and applications. Note the common usability heuristic 'visibility of system status' usually refers to the relevant state; whereas it is often the irrelevant state and internal process that can be appropriated.

expose intentions

While appropriation can be very powerful, we have also seen that it can be used to subvert systems. Rather than trying to prevent such subversion the designer can deliberately aim to expose the intention behind the system. This means that (cooperative) users can choose appropriations that may subvert the rules of the system and yet still preserve the intent. For example, if logging into a system is a slow process, then one member of a work group may login once at the beginning of the day and then everyone else use the logged-in system. If the purpose of the login is security, then this may be fine so long as the machine is never left unattended, however if the purpose is to adapt the system to individual users then this appropriation would be inappropriate. Exposing the intentions behind a system can be a frightening thing – you cannot hide behind "well that's the way it works". However, doing this can make the assumptions explicit and if they are wrong then they need to be re-examined. In the login example, if the purpose is personalisation would it be possible to allow a single secure login but have a facility to quickly swap between users.

support not control

As a designer you want to do things right, to make them as efficient and optimal as possible. However, if you optimise for one task you typically make others more difficult. In some situations, such as very repetitive tasks, then designing explicitly for the task may be the correct thing to do, perhaps taking the user step by step through the activities. However, more often the tasks description is incomplete and approximate, in particular ignoring exceptions. Instead of designing a system to do the task you can instead design a system so that the task can be done. That is you provide the necessary functions so that the user can achieve the task, but not drive the user through the steps. Dourish describes this as "informal assemblage of steps rather than rote procedure driven by the system" [9]. Of course you still want the common tasks done efficiently and so you may provide fast paths, or wizards to perform frequent activities using the basic tools and operations ... remembering of course visibility, making sure the user understands what is being done.

plugability and configuration

Related closely to the idea of support is to create systems where the parts can be plugged together in different ways by the user. Quoting from Dourish again "Users, not designers manage coupling" [9]. This is most obvious in programmable or scriptable systems and there is considerable work in making these more accessible to the user. This ability to plug-and-play components becomes a critical issue in ubiquitous computing and Newman et al. discuss the idea of recombinant computing [15] were systems are created bottom-up from small end-user combinable components. In more a traditional interface MacOS Automator allows the user to chain together small actions from different applications, so that, for example, you can create a workflow that takes a collection of images, sepia tints them, and then mails them all to a group of people from your address book. Similarly Yahoo! Pipes (pipes.yahoo.com) allow users to create and share mashups of RSS feeds and search results.

encourage sharing

People are proud of their appropriations of technology, so let them tell others about it! If one user learns a good trick for using an application or device, then this may be useful to others as well. Documentation can be enhanced by end-user contributed material; many web sites offer tips and advice on different software, and this can be designed as an integral part of a system, perhaps a 'tips' button that allows users to annotate functions with their favourite tricks. This could function across institutions making use of the communities of practice to which the user belongs. This sharing is even more important in the case of programmable systems. Even if the configuration or scripting is designed to be 'easy' it will still be only a small subset of users who actively script. However, if you make it easy for more confident or more technically adroit users to share with others then your product grows all on its own. The success of Xerox Buttons was an early example of this [12]. More recently, the MacOS Dashboard has this shareable quality, as does the Firefox architecture. Both allow the creation of plugins using a combination of small XML and HTML files and Javascript; importantly both have web sites dedicated to sharing these. As an online application, the Yahoo! Pipes interface not only allows sharing of complete pipes, but also makes it easy to see the graphical ‘code’ of pipes and hence copy and adapt them.

learn from appropriation

After a while one old, but broad bladed screwdriver becomes 'the' paint-tin opener. What was once a temporary use of a tool has become specialised. This crystalising of appropriation leads to a new tool and the entrepreneur might spot this, notice the particular kinds of screwdriver that made good paint-tin openers and then design a special purpose tool just for the job. By observing the ways in which technology has been appropriated, we may then redesign the technology to better support the newly discovered uses. This is a form of co-design where the users are considered an integral part of the design process. This closing of the Technology Appropriation Cycle has been called design from appropriation [2]. Of course any redesign should also take into account potential further appropriation. This learning from appropriation is particularly easy in some web applications (e.g. blogging or photosharing sites) where the results of users appropriation of the application are easily visible to the designers.

References

1. [1] Ainger, A. and Maher, R. The 'Salesman's' Promise (CSCW in Sales). Chapter 5 in Remote cooperation: CSCW issues for mobile and tele-workers. A. Dix and R. Beale (eds.), Springer Verlag. 1996.
2. [2] Carroll, Jennie., Howard, S., Vetere, F., Peck, J. and Murphy, J. Identity, power and fragmentation in cyberspace: technology appropriation by young people. In Proc. of Australian Conf. on Information Systems, 2001.
3. [3] Chalmers, M. and Galani, A. Seamful Interweaving: Heterogeneity in the Theory and Design of Interactive Systems. In Proc. DIS 2004, ACM Press, 2004, 243-252.
4. [4] Cuddon, J.. The Penguin Dictionary of Literary Terms and Literary Theory, 4th ed. Penguin, 1998.
5. [5] Dix, A., Beale, R. and Wood, A. Architectures to make simple visualisations using simple systems. In Proc. AVI2000, ACM Press, 2001, 51-60.
6. [6] Dix, A, Finlay, J., Abowd, G., and Beale, R.. Chapter 5. Interaction design basics. Human-Computer Interaction, 3rd ed.. Prentice Hall, 2004.
7. [7] Dourish, P. The appropriation of interactive technologies: some lessons from placeless documents. Computer Supported Cooperative Work 12, 4 (Sep. 2003), 465-490
8. [8] Dourish, P. Where the Action Is: The Foundations of Embodied Interaction. Cambridge: MIT Press, 2001.
9. [9] Dourish, P. Implications for Design. In Proc. CHI 2006 (Montreal, Canada), ACM Press, 2006, 541-550.
10. [10] Ellis, G. and Dix, A. 2006. An explorative analysis of user evaluation studies in information visualisation. In Proc. of BELIV '06. ACM Press, New York, NY, 1-7.
11. [11] Galloway, A., Brucker-Cohen, J., Gaye, L., Goodman, E., and Hill, D. 2004. Design for hackability. In Proc. DIS'04. ACM Press, New York, NY, 2004, 363-366.
12. [12] MacLean, A., Carter, K., Lövstrand, L., and Moran, T.. User-tailorable systems: pressing the issues with buttons. In Proc. CHI '90. ACM Press, 1990, 175-182.
13. [13] March, W., Jacobs, M., and Salvador, T. Designing technology for community appropriation. In Proc. CHI '05 Extended Abstracts, ACM Press, 2005, 2126-2127
14. [14] Moran, T., Everyday Adaptive Design (keynote). DIS’02. http://www.sigchi.org/dis2002/
15. [15] Newman, M., Sedivy, J., Neuwirth, C., Edwards, W., Hong, J., Izadi, S., Marcelo, K., and Smith, T. Designing for serendipity: supporting end-user configuration of ubiquitous computing environments. In Proc. DIS'02. ACM Press, 2002, 147-156.

https://alandix.com/academic/papers/papers/HCI2007-appropriation/

Alan Dix 2007