| home pubs essays HCI Remixed HICSS PC patterns |
How to Do Things With Genre: Genre as Catalysts for Social Networks
In 1993 I was one of three people who came together to form the User Experience
Architects' Office (UEAO) at Apple Computer. One of our goals was to promote
a deeper and more uniform approach to user experience across Apple's entire
range of products. In my experience this sort of activity is generally futile,
and of interest only of those who wish to be involved in endless bureaucratic
struggles. However, our case seemed to be an exception, in that our leader was
Don Norman. Don Norman is a well known Cognitive Scientist, and had recently
arrived at Apple to be one of the four Apple Fellows, a highly visible post
both within and outside of Apple; of particular import was that he was famous
enough to be known by the executives, and had the ear of many of the most important
people in the company. So, in short, I thought that Don's stature gave us a
pretty good chance of changing things.
What I hadn't anticipated was our approach to initiating change.
What we did was to design a new genre: the User Experience Requirements Document (UERD). The UERD was intended to join two existing genres, the ERS (Engineering Requirements Specification) and the MRD (Marketing Requirements Document), as one of a triad of documents that must be produced, approved, and updated before proposed products could get funding for serious product development. Don had enough power that got the UERD approved, and required, and he would regularly attend the high level meetings where products were approved to inquire after the UERD.
To be honest, I must admit that I argued against the UERD strategy. It seemed
a very Dilbertian move (although I believe this was pre-Dilbert), and I knew
that product development teams wouldn't have time to write another document,
and even if they did I didn't think that writing it would really change what
product teams did. After all, it's a bit naive to create a genre, and imagine
that those forced to enact it will soak up the world view that it embodies.
But, I was wrong, albeit wrong for interesting reasons
I was correct about one thing: product teams did not, in fact, have time to
write another document. And it was not just time, they didn't know how. Oh,
the form of the document was pretty conventional, adapted from the ERS and MRD
genre, but the sorts of questions that the UERD required answers for were quite
alien to the experience of either engineers or marketers.
After a few product proposals had gotten sent back because of no UERD (thanks to Don's presence at the product approval meetings), savvy project leaders begin to recognize the inevitable, and develop tactics to get their products approved. Given the lack of time and expertise on their teams, what this effectively meant is that they turned to one of two groups in the company where the expertise required, and asked for help.
This had several consequences. First, while requests of help had happened before, sporadically, they almost never happened at the very beginning of product development, which is when design can have the greatest impact. So this was a big success, and simply the possibility that this might become institutionalized was potentially revolutionary, because it meant that *really* saavy product managers might begin to recruit user experience specialists for their teams.
The second consequence was less direct. There wasn't nearly enough help available. The groups (primarily a single group called HIDC) with the expertise were flooded with requests for assistance. They said yes to a few, and no to the rest. And they counted and made lists. So, when resources permitted hiring, the group manager was able to point to literally dozens of requests for help from product groups all across the company, and point out that she was unable to help most of the projects.
Over the next couple of years HIDC at least doubled in size, an unprecedented rate of growth.
The third consequence has to do with forming cross-disciplinary social networks. Since there were many more groups that those able to write UERDs, user experience specialists would consult with a number of groups, helping them generate their documents. Although I can't quantitatively document it, these interactions typically result in informal social networks that connect heretofore unconnected pools of discipline within the company. Once the cross-disciplinary social networks are in place, they are often to be used informally, for questions, inviting someone to kibitz, etc.
There is more to this story, but I'm going to stop here, and point out where
these sorts of issues crop up in our reading.
One of the things that struck me in our reading, and that brought the UERD story to mind, is the way in which genres require social activity to constitute themselves. In a sense, I begin to think of a genre as a sort of social loom, bringing disparate people in contact, requiring collaboration and coordination, and thereby strengthening social connections.
This is illustrated, in a very general way, in chapter 5, on the evolution of the Reader, and its role as a forum; however, what I find striking are the much more focused ways in which a genre develops and utilizes social networks. For example, the case study of manuscript revision, chapter 4 of B&H foregrounds the negotiation and struggle between the (seemingly) powerless author and the shadowy figures of the editor and reviewers. However, it is likely that there is negotiation of a subtler sort going among the reviewers and the editor. Typically a journal editor will be a relatively senior, very powerful member of the disciplinary community, and the reviewers will be more junior members. Just as writing the article is not an exercise in simply recounting what happened, writing reviews -- which will be scrutinized and utilized by a powerful figure -- is not simply an exercise in giving feedback. Reviewers, like authors, must strike balances as well. They must balance the need to provide thorough, substantive feedback, with other agendas vis vis the powerful editor: demonstrating their competence, mastery of the genre, gently advancing their research agendas, perhaps encouraging citation of their allies, and discouraging citation of those they disagree with. A junior reviewer, who does a good job of reviewing, is likly to be invited to review again, perhaps to eventually join the editorial board; a reviewers who do poor jobs, or who allow personal agendas undue influence in their reviews, may damage their reputations, and such damage may radiate beyond the small circle of author, reviewers, and editors. Thus the scientific article genre and the review mechanism associated with it are strenghtening (if not always in a positive fashion) the social connections between mid- and senior level figures in the field.
Also in this vein, I'm struck by the importance of reference conventions.
To the extent that a genre requires intertextual linkage, it encourages attention
outward, and provides rewards for the creation of social and intellectual ties
among labs. It also provides a mechanism through which something not unlike
etiquette may be enacted: one cites relevant work not necessarily because it
has actually influenced one's work, but because it is a form of polite acknowledgement
(and because it is also a way of asserting literacy, currency, and one's participation
in the discipline's narrative of itself). Davis' reluctance to make a phony
story is quite striking, in this light, akin to a party-goer who believes that
honesty requires commenting on the ugliness of an outfit, or the unflatteringness
of a hair cut. It seems likly to me that the reviewers' and editors' proddings
(at the behest of the genre?) for Davis to construct the 'phony story', may
also have prevented the her from a professional faux paus, which might have
had significiant impacts on her future. One wonders, too, whether Davis, if
put in the position of reviewing another paper in her field, would be so cavalier
about precedent and acknowledgement when applied to her work.
| home pubs essays HCI Remixed HICSS PC patterns |