Once, when I was testing out some ideas that would eventually go into a journal paper on applying Activity Theory to peripheral displays I went into Peter Lyman's office. I figured Lyman, an expert in qualitative studies and ethnomethodology, would have a solid grounding in the area and would be able to help me navigate some of its exceptionally convoluted nuances. But when I asked him he just smiled and looked at me and said, "I don't do theory, sorry." At the time, that was shocking to me.
Lyman also said things at other times that made me think he had an appreciation for the style of work we did in the HCI branch of the CS Dept at Berkeley -- lite with theory and heavy with iteration. Reflecting back on these comments, I think that his attitude toward his work relied upon a relatively unusual metaphor, one that I'll call (forgive me) the Rauschenberg.
There are many researchers who apply a house-building metaphor to their work -- they pour a foundation (deep theory), construct the framework (hypothesis and experiment), and if it stays up they embellish the work (generalization, discussion, etc.), or strike the lot. Metaphors can only go so far, of course, and sometimes it is necessary to explain results with a different foundation than what one started with. But the end result is a solid thing that others can see, repeat, build upon, etc.
This is a great metaphor to rely on for scientific work. It is useful because the component of the work that is most generalizable is the product.
But I think that it is a poor metaphor for others, like Lyman, and as strange as it may seem, builders in general. The difference is that for others the goal is not to create a thing that itself is a generalizable contribution, but to go through a process that ends in an interesting or useful result but not one that is necessarily more or less valid than any other.
This is where we get to the Rauschenberg (Robert Rauschenberg was a Neo-Dada artist who would create sculptures ["combines"] by selecting pieces of detritus that he saw on a walk-about around an urban setting). The idea is to pick a certain frame, say discarded street signs, and collect data with that frame in mind. Since there is not necessarily any theoretical underpinning, the selection of a frame is more-or-less arbitrary. And indeed the results for any frame could lead nowhere (if so, pick a new one). Because the frame is ephemeral, you can basically discard it as you move to the next stage, interpreting what you have collected to meet some goal. For the artist this goal is a personal aesthetic (I suppose), but for designers the goal would be something more like usefulness to particular people. Now we can start down the traditional iterative cycle, getting feedback, iterating, throwing away what does not work, etc. But crucially you can throw everything away, including the materials and original frame, because there's no particular spec you are necessarily building to. At the end of this process you have a product that solves a much more specific set of problems and that in and of itself is not at all generalizable.
Clearly this second approach is not science -- it is design.
But then, can it also be research? To the extent that doing research is roughly equivalent to the generation of novel results that can potentially be built upon by others, then yes. Instead of the end result being the contribution, though, it is usually the new tools and techniques that had to be developed in the process of making the final product.*
Such contributions have actually enjoyed some respect in the HCI research community, usually as toolkits. But I think the approach taken in tool and toolkit research is problematic because researchers too often apply the house-building metaphor when the Rauschenberg would do better. That is, they treat the tool or toolkit as a first-order goal, a result in-and-of itself, presumably to appear more scientific (an ongoing concern in the academic HCI community) or futuristic (in the case of tools at least). Most useful tools and toolkits tend to emerge, I think, when the primary goal is a product or application (as is the case with so many platforms today). This type of work, to confuse metaphors again, tends to be more grounded. **
This is all too bad, really, because what is wrong with being a design researcher, making one app or explaining one set of people in one place at a particular point in time, while documenting the tools and techniques you develop along the way?
* One might argue that this would ultimately lead to focusing only on short term products. I think you can expand the types of work you develop, though, by requiring a higher level of technological savvy from your user base, trading off its potential size of course (see earlier post).
** This line of reasoning is related, I think, to the overemphasis on design method that Jon Kolko describes. While methods can play an important role, they should be connected directly to, and always in service of, the construction of a usable thing.
