I once had a summer job working for an established architect. His office had a closet full of old sets of rolled up construction documents, and my first task was to organize them. This required that I examine each roll one by one. I found many drawings for buildings I was familiar with, but the most interesting thing I found was plans for an addition to a house designed by the office of Frank Lloyd Wright. As a young architecture student, I was enthralled. Frank Lloyd Wright! But nobody else cared. The documents were crumbling, forgotten in storage.
This is as it should be. The map is not the territory and the plans are not the house. A set of technical drawings for a house may be of historical and cultural interest, but it’s far less interesting and useful than the actual house they describe. When the crew is on the job site swinging sledgehammers and pouring concrete, these documents are critical. Once the structure is built, their value rapidly declines.
It’s been many years since I worked as an architect (of buildings), but in my brief experience, I never saw a client ask to specify the form documents should take. Clients understood they were hiring the architect to design them a house, an office, an abattoir. Never once did they confuse the drawings with the finished product, nor did they ask the architect to price the project based on them.
Often, one of the first conversations that happens when starting on the design of an information environment is the one around deliverables. The client has many questions. What documents will you be producing? What form will they take? What do they look like? (Show me!) How many will there be? And so on. Although it’s not that frequent anymore, I’ve even seen RFPs that ask designers to price the project based on how many of these documents will be created.
I don’t like this word, “deliverables.” It implies these artifacts are the product we’re being asked to deliver. They’re not. We’re designing an information environment. That is the product. Wireframes, sitemaps, conceptual models, etc. are communications tools that help designers, stakeholders, and developers establish a generative dialog towards producing the built environment.
In an emerging field, such as our own, there will be many questions about the artifacts we use to communicate intent. This is understandable, and we need to address those questions. But we also need to make sure we’ve framed the conversation, so tools and means do not become the focus of the engagement. The focus should always be on the goal: the quality of the environment we’re designing together. “Deliverables” are the means to get there, not the destination.