How do You Communicate Basis of Design?

Collecting basis of design product data before starting the project specifications takes time. It takes even more time to get the right information. From the specifier's perspective, data gathering is often an art form rather than a defined process. Absent a process, the results may be unpredictable.

So how can design teams transfer basis of design decisions to specifiers?

Architects and Engineers: What do You Think?
How do you communicate design intent? How do you work with your specifier? How do you wish you could work with your specifier? How can you ensure your specifier knows your basis of design product decisions?

Please tell us your story, from your perspective. Reply to this posting to share your opinions to make the process better, more efficient, and capable of producing the right result.

A Specifier's Story
I sense dependence. Design teams tend to expect specifiers to know what is required for a particular project. Yet, a specifier's knowledge about a project is limited by the readily available data - annotated drawings, selected product cut sheets, project reports, and designer interviews.

Specifiers sift through everything that is available, making notes, creating lists, identifying questions that must be answered. This initial effort yields the first draft table of contents for the project manual. The contents will include the list of expected specifications sections and the basic content and initial questions for each.

The table of contents is shared with the design team for confirmation that the design intent is understood. The table of contents development is a dialog between the design team and specifier that is maintained throughout the construction documentation process. The table of contents becomes the primary coordination tool between the drawings and specifications.

As a specifier, I rely on the road map the table of contents provides. It is a succinct project summary to communicate with the design team and to guide the specifications development. The communication, though, is often unilateral - specifier to design team - with little or no response from the design team.

The usefulness of the table of contents to the design team becomes questionable. And there begins the dependence, a dependence that may not capture the designer's intent.

The Design Team's Story
What is your story? Sign in and leave your comments here.

Alternative Approaches
I have tried other approaches for data collection and communication with the design team. Each method has seen some acceptance, but none seems to be universally accepted as the best or the preferred method. Here is a partial list of what I have tried:

• Master Table of Contents - provided to design team for initial spec section selection
• Checklists - provided to design team in blank and partially completed form
• Basis of Design Narratives - produced by the design team
• Design Team Interviews - based on draft tables of contents
• Design Team Interviews - based on UniFormat systems and assemblies outline
• Preliminary Project Descriptions (PPD) - produced cooperatively by design team and specifier following UniFormat organization.
• Specific Product Questions - posed to design team as specifications are drafted.

The success from using PPDs is promising. Acceptance of PPDs is growing. although, few design teams have opted for this approach. As more experience is gained, we are hopeful PPDs will yield consistently better results. See other blog posts discussing PPDs

We are considering some other alternatives to try to engage the design team and improve the process.

• Electronic interactive decision tree for product attribute selections
• Web based software such as One Note or Evernote for data gathering
• Collaborative software such as Google Docs for managing tables of contents

Will any of these be better? I reserve judgment, pending your response.