Invisible Work, a Short Essay

Talking to a colleague yesterday about design and usability work, I used the phrase "invisible work" a few times and he said he wasn't familiar with it. I gave a short not-very-political explanation, and now I'm delving into it a bit further. Consider this an infomercial or something.

A 1999 issue of Computer Supported Cooperative Work (CSCW) was dedicated to this subject. ("CSCW" is more or less a subdiscipline of the research arm of the field of human-computer interaction, which itself broadly covers aspects of interface design, product design, and usability methods.)Here's the Introduction to the journal, which summarizes the basic topic they covered:

This special issue documents four kinds of invisible work: (1) work done in invisible places, such as the highly skilled behind-the-scenes work of reference librarians, (2) work defined as routine or manual that actually requires considerable problem solving and knowledge, such as the work of telephone operators, (3) work done by invisible people such as domestics, and (4) informal work processes that are not part of anybody's job description but which are crucial for the collective functioning of the workplace, such as regular but open-ended meetings without a specific agenda, informal conversations, gossip, humor, storytelling.

The way I actually used the term yesterday was in reference to another kind of invisible work, I think more formalizable than (4): the shadow job, the job you do that doesn't at all match your job description, but more or less has the same end goal. It's the job you have to do to get your job done, and the more it doesn't match your job description, the more dysfunctional something is (or might be) in the company: hiring and evaluation of candidates may not be oriented correctly if the shadow job is done by everyone, or team dynamics may be screwed up if it's only one person doing the shadow job out of the crowd with similar job titles. Perhaps the company doesn't know the categories of work that could exist or need to be done by someone, because they haven't got those activity classifiers in their sights yet. To me, it comes down to an ethnographic research issue: what's labelled vs. what's not, and why? What are the missing vocabulary items?

One of the articles in this issue gets close to another topic dear to my heart, the shadow work involved in the user interview/usability test/qualitative data analysis. It just happens to be about ethnography here:

In her paper, "'It's Just a Matter of Common Sense': Ethnography as Invisible Work," Diana Forsythe turns the analytical lens on ethnographers--those who have made significant contributions to uncovering everyone else's invisible work. Forsythe notes with irony that now that ethnographers have convinced researchers and corporations of the value of ethnographic work in technology design, they face a new and unexpected problem: appropriation of their methods. Ethnography does look easy. It's just talking to people, right?!... Drawing on Star's concept of "deletion," Forsythe observes how certain kinds of activities are "deleted," or simply not considered salient, from various kinds of accounts....For example, Forsythe reports from her studies of artificial intelligence researchers how technical people describe the work they do in terms of programming or system design, but consistently delete social activities such as meetings and other kinds of social interaction. The work would not get done without these interactions, but they are deleted by the researchers as inferior to "the real work."

Lots of usability professionals (and UI designers) discuss and have to shrug away this issue in practice; it's better to have 4 developers who've never had a course in interviewing visit the customer alone and bring back enthusiastic (if noisy) stories than to have one usability professional interview a dozen people and return with carefully analysed data that doesn't interest anyone else because they didn't get it viscerally for themselves. And it's better to have everyone participate in usability testing and hear the data first hand even if the signal gets garbled, than to have one person attempt to rein in the wild horses and sour everyone on the practice at the same time. There's usually no time to give people a crash course in methods, after all. We just mope about this at conferences with our colleagues and buck each other up over cocktails.

Invisible work is certainly a problem even for folks in high status positions doing what's seen as the "real work." I've recently had conversations with a few developers about their own invisible work; some of them need cocktails at conferences as well, I think.

(On a personal note, Diana Forsythe was very important to me as a role model and colleague when I was in grad school; she died in a hiking accident in Alaska a year later, an enormous blow to me and to an entire discipline.)