Tacit knowledge, or situated action?

This is a response-to-a-response-to-a-post: my response to Kyle Johnson's comments on Jon Udell's post about the tacit dimension of tech support.

Jon (and Kyle) argue there are 2 kinds of tacit knowledge relevant to IT support: knowing how to do stuff; knowing where to find stuff. They argue that preferences for one over the other contribute to misunderstanding and poor communication between users and helpdesk staff.

But if you're trying to understand how users work, how people function, this doesn't really get to the nub of the problem. From the point of view of the non-expert or novice user, these two species of tacit knowledge (the knowing-how, and the knowing-where) amount to exactly the same thing.

Jon writes, humorously and sympathetically, about what it's like to provide computer support for his "non-geek" wife. From her perspective, he's an IT God, whereas from his perspective, he just knows where to look...

But "knowing where to look" is itself inherently procedural.

"IT expertise", like any form of expertise, involves intricate sets and combinations of situated actions, physical and mental. It also involves tacit understanding of the potential and limits that are attached to procedures: including the possible responses that a system might make to user interventions. Novice users lack this. That's why they are so terrified that if they touch something, they'll break it.

Dealing with a particular computing problem is not just a matter of tacitly knowing some content: in this example, knowing to look at a particular website, go to a particular search engine, or use a particular search term. All of these elements form part of a tacit understanding of procedure. Call it workflow, if you prefer.
<?xml:namespace prefix = o />
Lucy Suchman's Plans and Situated Actions: The problem of human-machine communication gives a better way to understand these issues. Based on her time at PARC, back in the eighties, Suchman's research shows that IT helpdesks and manuals usually fail to assist users because they work on the principle that users' interactions with a system are, or should be, strongly "planned" or "intentional".

The problem is that explaining a problem (or a process) in a step-by-step, one-at-a-time manner doesn't help novice users act like experts. It merely provides a prescribed framework for action that is diametrically opposed to the ways that people, experts included, actually work. Do as I say, not as I do...