Or, adopting the language of your clients as a manifestation of design rationality
As I work on the design of a prototype for the Circus Oz Living Archive I’ve been playing around with some basic experiments in reframing. It is a bit of a language game: by changing the way we talk about [something] we can change the way that we think about [something]. I started with a question: we are building a prototype, but what is a prototype? The answer could be very simple: a prototype is a thing, designed to test an idea.
This is where the language game begins. What else is a prototype? A prototype could be an introduction (perhaps the first time a client has interacted with a product or idea). A prototype is a tool (for data collection). A prototype is a rhetorical device (by leaving things in, or taking them out of a prototype, you are making an argument for/against certain aspects). A prototype is a process. You get the idea…
By asking the question, “if the prototype was x, what form would it take?” I am trying to force myself to leave behind my implicit understanding of what a prototype is for: perhaps a prototype can be for much more than testing and solving a particular design or technical problem. Schön calls this imposition of a ‘new way of setting the problem’ a ‘frame experiment’. This kind of experiment forces a reflection on your practice, or ‘Reflection-in-Action’ [and sorry about the sexist nature of the designer as ‘he’ in this passage]:
When someone reflects-in-action, he becomes a researcher in the practice context. He is not dependent on the categories of established theory and technique, but constructs a new theory of the unique case. His inquiry is not limited to a deliberation about means which depends on a prior agreement about ends. He does not keep means and ends separate, but defines them interactively as he frames a problematic situation. 1
This kind of frame imposition can lead you to strange and interesting places. One of the paths that I’m interested in pursuing in my PhD research is the idea that performance practice and interaction design practice share certain qualities. This gave me a new frame to work with: What if we consider the ‘prototype’ analogous to the ‘rehearsal’?
Work with me here: A prototype shares much in common with a process of iterative development in a performance context. The rehearsal and the prototype are both tools to develop, explore, communicate and evaluate ideas. The prototype, like the rehearsal, encourages improvisation and reflective feedback. The prototype, like a rehearsal, can take place in a context similar to that of its final outcome. The prototype, like a rehearsal, can be understood as a means to an end, a version of an artefact that is subject to change, a collaborative work in progress.
One of the well known problems with the use of prototypes in interaction design is that it can be very hard to communicate to a client what a prototype is, and what a prototype is for. You can make the prototype as ‘low fidelity’ as you like, but this can lead to the client thinking that it is ‘broken’, you can make it ‘high fidelity’ which can lead to the client thinking it is finished (and so only providing superficial feedback) 2, you can carefully ‘filter’ your prototype 3 to test for a single quality, but this doesn’t let the client experience how the design might be used in a real world context. It can be really hard to get a client engaged in a process like prototyping.
I would say a lot of these issues actually arise from communication/language problems. A designer intuitively understands ‘prototype’: what it means, what it affords. But this is a technical, professional language. What if instead we adopted the language of our client, using a metaphor for prototype that they can understand?
According to Löwgren and Stolterman:
‘a designer has to have a solid understanding of the complexity involved in being rational. When a designer works with a client, she has to be able to appreciate the client’s understanding of rationality, in relation to her own understanding of it. A basic appreciation of that relationship is fundamental to the communication between designer and client. Rationality is therefore not only a matter of how to do things, but a precondition for good communication’ 4.
I would suggest that appropriating language of a client is an explicit attempt to understand a different rationality: for a designer, it is ‘obvious’ that a prototype is subject to change, unfinished, wants feedback, etc. For a performer, while ‘rehearsal’ has these ‘obvious’ qualities, ‘prototype’ sounds technical and meaningless.
This example of reframing in the language of practice is particularly interesting in the context of the Circus Oz Living Archive project, considering that one of the points of adoption for the digital archive is actually as part of their rehearsal practice. So: the prototype of the digital video archive is a ‘rehearsal’ for the digital archive, it is also a tool to use within the context of a rehearsal.
‘Rehearsal’ has pretty clear implications: this is an unfinished object; this is something open to change; this is an object with the potential for collaborative development; this is something that, while not final, will be public at some point in the future. Using this language can work the other way too: reframing ‘prototype’ as ‘rehearsal’ serves to remind me of the performing arts community context in which I’m working, and also serves to remind me of the prototype’s transience and malleability (which should help prevent me from becoming too fixated on a particular idea or design solution this early in the project).
- Schön, Donald A. 1991. The Reflective Practitioner: How Professionals Think in Action. Aldershot: Avebury. p68 ↩
- McCurdy, Michael, Christopher Connors, Guy Pyrzak, Bob Kanefsky, and Alonso Vera. 2006. Breaking the fidelity barrier. In Proceedings of the SIGCHI conference on Human Factors in computing systems – CHI ’06, 1233. Montréal, Québec, Canada. ↩
- Lim, Youn-Kyung, Erik Stolterman, and Josh Tenenberg. 2008. “The anatomy of prototypes.” ACM Transactions on Computer-Human Interaction 15 (2) (July): 1-27. ↩
- Löwgren, Jonas, and Erik Stolterman. 2004. Thoughtful Interaction Design: A Design Perspective on Information Technology. The MIT Press, December 1. p50 ↩