As previously noted, I’m reading Paul Dourish’s book, Where the Action Is, in which he explores the branch of philosophy called phenomenology as a possible theoretical basis for embodied interaction. In particular, he mentions the work of Heidegger, about which I know nothing but a couple brief summaries I have read. But the concept which I want to address today is Heidegger’s exploration of equipment use, in which he divided equipment into “ready-to-hand” and “present-at-hand”. As Dourish explains:

These are ways, Heidegger explains, that we encounter the world and act through it. As an example, consider the mouse connected to my computer. Much of the time, I act through the mouse; the mouse is an extension of my hand as I select objects, operate menus, and so forth. The mouse is, in Heidegger’s terms, ready-to-hand. Sometimes, however, such as when I reach the edge of the mousepad and cannot move the mouse further, my orientation toward the mouse changes. Now, I become conscious of the mouse mediating my action, precisely because of the fact that it has been interrupted. The mouse becomes the object of my attention as I pick it up and move it back to the center of the mousepad. When I act on the mouse in this way, being mindful of it as an object of my activity, the mouse is present-at-hand. (p.109)

We’re all familiar with this concept. When we pick up a hammer and hit a nail, we’re not thinking about the hammer, we’re thinking about the task of hitting the nail. The hammer is invisible to our conscious thought; it has been absorbed into our extended self (Me++ explores similar ideas).

Dourish uses these philosophical concepts as a way to build a theoretical basis for designing embodied interaction. He talks about a bunch of different things, which I’ll explore more when I do a formal review, but for now I’m going to restrict the discussion to understanding how and why different forms of interaction can morph from “present-at-hand” to “ready-to-hand”, from visible to invisible, from outside my personal collective to inside.

While reading later in the book, it occurred to me that one of the keys, if not the key, to this transition is feedback. I am a tremendous believer in the power of feedback to effect changes in the world. It’s something I see everywhere, from the importance of aligning company processes with goals in Built to Last, to advocating using the feedback of others to change oneself.

How is it relevant in this particular situation? I believe that consistent and reliable feedback is necessary before an object can transition to the “ready-to-hand” state. If something is acting as an extension of oneself, it can not have an identity in its own right. It must behave exactly as one expects in response to one’s actions. If it doesn’t, if it starts behaving in an unexpected fashion, then the tenuous connection that has “coupled” it to one’s consciousness is broken, and the “ready-to-hand” status is lost. Dourish’s example of the mouse that reaches the edge of the mousepad is a good example of this transition. When the mouse is “ready-to-hand”, I move it up and the cursor goes up, so after a few moments, the mouse has disappeared from my consciousness, because when I think up, the cursor goes up. It is only when the feedback is unexpected, when I think up, and the cursor does not go up because the mouse has hit the edge, that the connection is broken.

Dourish mentions feedback in passing a few times, but I think it is central to this particular issue. Of course, I haven’t finished the book yet, so it may yet make a more prominent appearance. But that’s why I’m writing this now, so I can feel all clever if it does.

This connection of feedback with making things “ready-to-hand”, making things disappear from one’s consciousness as they are absorbed into an extension of oneself has some interesting consequences. For instance, it ties in readily with this post on cognitive trust, where I say “as we learn to trust and respect [a coworker], we can learn to call upon them with little more overhead than we do a subroutine in our own head” – our coworker has become reliable enough in our eyes that they essentially become “ready-to-hand”.

I noticed this recently in my own life, actually. In my previous jobs, I was always in direct contact with my “customers”, because I was writing prototype software for my coworkers’ use. I didn’t worry too much about specification requirements or software process, because if I started coding and I ran into an ambiguity about what they wanted, I’d turn around in my chair and go “Hey, how do you want this to work?”. At my current job, however, I am at least two steps removed from the customer. The customer talks to the president of the company, and the president talks to us. The feedback loop is much longer because if there are any questions, it has to be relayed to the president, who then has to take it to the customer when she gets a chance, etc. So I’m starting to learn that I need to be much more proactive about clarifying requirements and specifications as early as possible in the software design process. At my old job, I hadn’t even been aware of how much I relied on the instantly accessible nature of my coworkers; they had been “ready-to-hand”, used without thinking. Now that the feedback has become much more distant, my link to the customer has been broken and I am aware of the customer’s existence as being “present-at-hand”, an entity in their own right.

I think this mutual dependency between tight feedback loops and the “ready-to-hand” status of something (or someone) is something to be aware of in design. Certainly one of the things that makes software so hated is that feedback is often inconsistent and reliable. One definition of insanity is doing the same thing over and over and expecting a different result. And yet with our computers, we often repeat the same action over and over… and get different results. We don’t know what makes the software work. We develop elaborate incantations to invoke the blessings of the software gods (“Oh, I know that if I press this button, then call this from this menu, and then press F3, the report works, but if you do it the other way, it crashes”).

This actually ties into Lucy Suchman’s book as well, where she talks about patterns of conversation. One thing she mentions is that when we are talking to somebody, we assume that they are offering appropriate feedback to us. She cites a particularly thought-provoking study where they had students talking to a “psychiatrist” through a computer screen, but were only allowed to ask the “psychiatrist” yes or no questions. Of course, the “psychiatrist” was a program that randomly answered yes or no without any understanding of the questions. And yet the students were able to extract useful information from the conversation, hypothesizing mental models for the “psychiatrist” that resolved even seemingly contradictory answers. Suchman uses this understanding to illustrate how important it is for software to present appropriate feedback in response to a user’s actions; if the software doesn’t, the user will construct an incorrect mental model which will be detrimental to future interactions with the software.

An ideal tool is one that is “ready-to-hand”, that disappears from consciousness. We should aspire to create and design such tools, whether we work in software or any other form of design. And that means being ever aware of the importance of consistent and useful feedback.