A value scenario for the use of metaphor in design
Metaphor has a power to mislead and misdirect. Kensing and Madsen (1991) introduce it as a tool to start conversations about a new design and to open up fresh possibilities along the way. Their librarians reason from known activities in one context to coalesce vague ideas about a different one into forms amenable to evaluation and further refinement. Much like graphical design representations, metaphor can make intangible ideas real and available for critique. Key to those benefits is the authors’ presumption of analogy between the familiar context and the new one. Differences may highlight points for design consideration, just as similarities do, provided all stakeholders recognize the gap. But metaphor does its work by bridging conceptual gaps. It blurs lines once presumed to be distinct, which allows meaning to flow across those former boundaries.
My former employer fell into such a gap when it wanted a new system for selling digital assets (mainly PDF files). The documents represented substantial existing knowledge assets, and a repository of rich metadata about them already was in place, thanks to forethought by the company librarian. The new project needed only an interface for users to select the documents and code to process the sale transactions and deliver the files. This presumed marketing/sales effort kicked off with an objective to give the new system a name that would establish the right identity. One morning, the Director of Publishing announced that she’d had an insight at home, and she thought we might call it The Water Library. Product managers from Publishing were thrilled that the name evoked good feelings associated with libraries along with the organization’s image as a knowledge repository for its industry. IT was happy enough that some name had been chosen so the real work of developing functional requirements and code could begin.
Product managers reviewed every existing digital library they could find, compiling an extensive dossier of functions and features they wanted in their new system. Graphic designers from Pubs busily developed logo treatments and screen mock-ups, which were reviewed, modified, and finalized by an extended team. IT took the finished design package and worked with product managers to craft formal functional requirements.
The project fell apart in development. Coders showed working prototypes with functional changes previously discussed but without changes in screen text and formatting that were more important to the Pubs staff. The coders knew they’d get those curtains in the windows eventually, and they wanted approval of the important functional stuff. Designers from Pubs knew little about the working guts of the thing and cared less, incensed as they were that their prior input on essential questions of branding and user instructions had been ignored. Simmering frustration boiled over in an impasse about integration with the existing storefront for print versions of those same PDF documents. The library metaphor didn’t carry over at all to that e-commerce environment, which IT regarded as already determined by existing, working technology that might be changed, if at all, only in some future project.
Deep animosities emerged when product managers felt disregard for their personal commitment to the project’s library metaphor, established by that choice of name and given shape and emotional meaning through the process of researching functionality and finalizing a design to fulfill the implied vision. Any variation from that fully realized design felt like an insult to the effort of developing it and the expertise of those who had staked so much on it. Customers did eventually get access to the documents and happily paid, although they complained about accessing print and digital versions via separate interfaces.
A better outcome might have emerged by reversing Kensing & Madsen’s statement (1991, p. 170) that “[P]arts left out or hidden [by one metaphor] would be likely candidates for other metaphors.” In this case, one comprehensive metaphor governed all the details and left no room for negotiation; multiple metaphors for smaller components might have allowed creation of a flexible, functional assemblage to better meet users’ needs. The project might also have benefited from Poltrock & Grudin’s advice (1994) to keep management and user proxies from speaking for users themselves and imposing presumptions that distort real needs and priorities. Finally, the project needed a realistic vision of functional goals in light of available implementation technologies and resources. Its central metaphor, conceived in a flash outside the practical implementation context, ignored a central reality that this new e-commerce project would exist alongside related functions, and it could more effectively serve users if integrated with them rather than standing alone as some separate, perfect vision. Kensing & Madsen (1991) urge separation of Fantasy from concerns of Implementation, which encourages conflict between new plans and existing infrastructure, with a high risk of lasting harm.
Works Cited
Kensing, F., & Madsen, K. H. (1991). Generating visions: Future workshops and metaphorical design. In J. Greenbaum and M. Kyng (Eds.), Design at work: cooperative design of computer systems. Hillsdale, NJ: Lawrence Erlbaum: 155-168.
Poltrock, S. E. & Grudin, J. (1994). Organizational obstacles to interface design and development: two participant-observer studies. ACM transactions on computer-human interaction, 1(1): 52-80.