Authors:
Elizabeth Goodman
I don't remember when I first heard the word deliverable, but I do remember ferociously loathing it.
Many of interactions' readers undoubtedly live and breathe deliverables, but here's a quick definition for those who are still innocent: A deliverable is a document created by one group of people that is then passed to another. Hence the name. Like a parcel, a deliverable has a sender and a receiver. In commercial interaction design, the sender is likely a designer or consultant; the receiver, the developer or client. As a primary form of communication between key players in the creation of a technological product, deliverables can have very high stakes.
As a print graphic designer, I never heard the word. I dealt with comps, flats, or proofs. I started hearing requests for deliverables only when I started working as an interaction designer.
I didn't like it at all.
To be honest, my dislike was instinctive rather than intellectual. Hearing or saying deliverable reminded me that my work depended on other people. That instead of holding the fate of my ideas in my own hands, I had to give up control to other people. That my personal visions were just technical specifications. The word deliverable symbolized what I saw as the standardization of creativity into prosaic routines. It just seemed so... industrial. Like working on a digital assembly line.
I had gone into interaction design because I loved imagining new digital thingsuseful, playful, provocative, exciting things. But I didn't see myself as a member of an industry, or even of a team. And therein lay the problem: I saw myself as an inventor of things, rather than a maker of products.
Flash forward to about three years ago.
The word deliverable had long since stopped irritating me. In fact, I took it for granted. By the time I started my dissertation research, an observational study of interaction design work in consultancies, I used the word almost every day without much noticing it.
However, in observing interaction design projects over the past three years, I have entirely changed my mind. As a word, deliverable is neither irritating nor unremarkable. I now see it as wonderfully precisea perfect description, in fact, for how interaction designers work, the skills they cultivate, and some current troubles they face.
Let me explain.
As professionals, interaction designers rarely have to write production-ready code. Some may not ever touch code at all. They produce diagrams and text as design specifications that they deliver to others. Organizational distance between the makers of specifications and the makers of working code means that interaction designers don't have final control over what's made. Instead, the implementations of their ideas require communication in drawing, writing, and verbal presentation.
All three skills are required because the usual interaction design deliverables, such as wireframes and site maps, are flawed. As static documents, they cannot themselves fully demonstrate the digital interactions that designers want to communicate. But they have become the expectedand requiredend result in many workplaces.
Luckily, in everyday interaction design, the deliverable doesn't have to stand alone. It is more like the text of a speech than a mailed parcel. A live walkthrough by the creator almost always accompanies the transfer of a deliverable to a receiver. Part of being an expert designer is managing the collaboration across organizational separation, and the related arts of cross-discipline storytelling and negotiation. Like a speech, then, the influence of a deliverable depends on how skillfully it's delivered.
That's how I have observed deliverables working in design practice, but that's not always how they are perceived. Some designers make heroic efforts to perfect their deliverables. Others advocate a changed relationship to deliverables. Art director Dan Mall, for example, proposes improving team communication with more mid-process documentation, what he calls "invisible deliverables" [1]. UX designer Jeff Gothelf, on the other hand, recently argued for designers to "get out of the deliverables business"to put fewer hours into documentation and more into iterating on working prototypes [2].
Debates about the appropriate role of documentation in project-based work continue. But I value the word deliverable because it reminds me that we do not, and cannot, make our visions real by ourselves. Part of being a thoughtful designer, educator, or student is to keep in mind that our job is not just imagining wonderful things. It's also to consciously considerand perhaps redesignhow we work together in teams and organizations to materialize those things and deliver them to the world.
References
1. Mall, D. Invisible deliverables. Method & Craft. Feb. 28, 2011; http://methodandcraft.com/articles/invisible-deliverables
2. Gothelf, J. Lean UX: Getting out of the deliverables business. Smashing Magazine. Mar. 7, 2011; http://uxdesign.smashingmagazine.com/2011/03/07/lean-ux-getting-out-of-the-deliverables-business/
Author
Elizabeth Goodman is a Ph.D. candidate at UC Berkeley's School of Information. Her dissertation research focuses on commercial interaction design practice and ubiquitous computing.
©2012 ACM 1072-5220/12/0900 $15.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2012 ACM, Inc.
Post Comment
No Comments Found