In the last blog post I asked a simple question: Where is design intent documented?
If the answer requires searching drawings, specifications, meeting minutes, emails, models, and someone’s memory, perhaps the real answer is that it is not documented very well.
So what would a useful record of design intent look like?
It does not need to be complicated. In fact, making it complicated would probably guarantee that no one uses it.
We have been working with Systems & Performance Descriptions, or SPDs, to create a consistent home for design intent. The concept grows from a practice that has been available to the industry for decades: describe the building by systems and assemblies while the design is developing, and describe the individual work results and products when construction information is required.
Consider a slab on grade.
The drawings might identify the assembly simply as:
A1030.SOG-1 SLAB ON GRADE
Now use the same identification in the SPD.
The first requirement is a description. What is it? How is it constructed? Where is it used?
At the beginning of design the answer might be quite simple: a reinforced concrete slab over granular base and vapor retarder for typical first-floor occupied spaces.
We have not selected every material. We have not specified concrete mixes, reinforcing, vapor-retarder products, curing compounds, joint fillers, or floor treatments.
Do we need those decisions to understand the system? No.
We already have enough information to document an important design decision and enough information for an experienced estimator to begin understanding its cost.
As the design progresses, the description progresses with it.
Add a simple graphic.
This is not intended to become another construction detail. In fact, keeping the graphic simple is important. Imagine cutting through the middle of the assembly where there are no edges, transitions, openings, penetrations, or other complications.
Show the components and their relationships.
The drawing tells us what the assembly looks like. The written description tells us what the assembly is intended to be. Used together, they communicate far more effectively than either one alone.
The same assembly identification can appear on the drawings, in the model, in the cost estimate, and in the SPD. Instead of independently interpreting several documents, everyone can discuss SOG-1.
That may sound like a minor change. It is not.
Next, record the performance requirements that can be determined by calculation or testing.
What must the slab accomplish? Structural loading belongs here. Flatness or levelness may belong here. Moisture-related requirements may be important depending on the finishes. Other projects will have other requirements.
Performance is different from the product used to achieve the performance.
That distinction becomes extremely useful when evaluating alternatives later. If a proposed change satisfies the documented performance and design requirements, the team has an objective basis for considering it. If it does not, the reason for rejecting the alternative becomes equally clear.
Then document design requirements that can be directly observed or measured. Thickness, configuration, finish, slopes, joint locations, or other characteristics may be appropriate.
Finally, identify the system components as product decisions are made.
Concrete. Reinforcing. Vapor retarder. Granular base. Accessories. Do not invent information simply to complete the list. Say what you know, when you know it.
There is another important distinction.
The architect does not own all the information needed to describe the slab. The structural engineer has requirements. The geotechnical engineer may have requirements. The interior designer may have requirements for finishes affected by slab moisture. The estimator has cost information. The contractor may see constructability issues.
Why wait for these disciplines to discover conflicts by comparing separately produced documents? The SPD can become the place where everyone contributes to a common description of the system along with the WHY that is never .
This is where documenting design intent becomes more than specification writing. It becomes decision management.
I am not suggesting that firms suddenly change every documentation process on every project. That would be a good way to ensure nothing changes.
Pick one system.
Give the system an identifier. Write a short description. Add a simple assembly graphic. Record the known performance requirements, design requirements, and components. Ask the appropriate disciplines to review it.
Then use the information.
Use it during design reviews. Give it to the estimator. Refer to it when discussing alternatives. Use it to develop the construction specifications.
See whether the team has fewer questions about what was intended. If the experiment works, try another system.
Closing the Design Intent Gap may ultimately require significant changes in industry practice. It can begin with something very small: give the design intent a place to live.