Tag Archives: details

A Framework for Understanding Details


Well thought out details are the essence and foundation of good engineering design. Too often engineers are tempted to reuse something that has already been developed without analyzing whether it is the right solution for the project at hand. Details must respond to the specific programmatic, environmental and physical constraints that are imposed on the project. When details miss this goal, the project falls short of what it could have been, even if no real problem is created. When they are successful though, the project has the opportunity to reach its full potential.

My vision in developing this blog is to use my perspective and experience as a civil engineer to promote and demonstrate the design processes behind the infrastructure that surrounds us. By analyzing engineering details we see a microcosm of these processes – a slice of design that can be understood independently from the larger project. Before we can approach this analysis though, we need a framework for understanding what a detail is and what it does.

Fight as we may, the truth is that every project has a list of solutions that would be great, but for different reasons don’t quite work. For example, by building roads out of permeable pavements we could significantly change how our infrastructure affects natural water quality and flow patterns, but the materials presently available just can’t support the level and type of traffic carried on even a typical city street. Maybe instead we could put our road network underground; then stormwater would never come in contact with pavement and we could use any material we like. It may not surprise you that the price alone of such a project would prevent it from being considered, particularly in an age when transportation funding can barely keep up with road maintenance costs.

It is then not hard to argue that many of the most significant design criteria for a project are in place before the design team ever begins work. For the sake of our framework, I am going to break these constraints into three categories.

Programmatic constraints are the limitations imposed by the person or group that oversees the project. This could be a public agency, a private developer or people in any number of other positions. By the time the design team has begun work, this owner has usually established much of the program for the project including what functions the site will serve, how much area will be committed to each of these functions and how much money will be made available for the project. Programmatic constraints must be observed because it is difficult to justify spending money to develop a project if that project does not meet them.

Environmental constraints are the limitations imposed by the interaction between a project and the surrounding environment – both upstream and downstream. This is not limited to the ecological environment – though that is certainly included – but extends to all outside interactions including elements like traffic. Upstream interactions – how the environment affects the project – are created independently from the project, and the designer has no control over them. The designer has more control over downstream interactions – how the project affects the environment – but this control is still limited. In either direction, the project will not fit into the bigger picture without close attention to environmental constraints.

Physical constraints are the limitations imposed by such aspects as location, topography and constructibility. These are real world issues with an active presence on the site. Physical constraints are primarily determined by the project site, the properties of the selected materials and the means and methods available to the contractor. A good idea is a wonderful thing, but that idea won’t become a reality if it doesn’t work with the physical constraints.

In order to be a good solution for a particular project, a design must simultaneously respond to all of these constraints. Showing this requirement as a Venn diagram results in the following infographic.


Projects are rarely equally constrained in all three categories. One category or another will often dominate the system. In general, imposing more constraints will lead to having fewer options, shrinking the circle and its intersection with the other categories. Conversely, imposing fewer constraints results in more options, expanding both circle and intersection. This change can be shown visually by making a few small changes to our original diagram. The main point here is that fewer constraints and more available solutions will usually lead to more flexibility in design and a better final solution.


In addition to representative circle size, the amount of overlap between categories can vary. In a perfect world you would find a long list of solutions that work for multiple categories. Occasionally one category will even be completely contained as a subset of another. On the flip side though, it is possible for projects to be constrained to the point that one category is completely separated from the others. Such an overly constrained system leaves no design options that fit the overall project and means that a change has to be made to some programmatic, environmental or physical element for the project to be viable. Again revising our original Venn diagram results in the following graphic, showing how a more closely aligned set of constraints leads to more flexibility in design.


In applying this framework to design work, it is important to note that there is a difference between given constraints and self imposed constraints. Again, by the time the design team begins work on a project, many of the constraints are already established. Seeking flexibility and creativity in our solutions and design work, we should avoid adding to these constraints when possible or at least recognize when we are doing so. For example, by limiting ourselves to designs that have a standard detail or designs that we have worked through on previous projects, we can artificially make the circles in our Venn diagram smaller across the board. This is not always a problem, but it is important for this to be a conscious decision.

Next, while it is important to identify self imposed constraints, it is equally important not to dwell on things that can’t be changed. It can be tempting to argue editing a project element to make a seemingly otherwise perfect idea fit, and doing this can be an important part of an open creative process. There is a point though where we have to realize what is possible and what isn’t and direct our energy and creative effort toward the former.

Finally, whether you agree with the way I have categorized project constraints or not, hopefully it is clear that grouping these things in some way will allow you to see the options you have in approaching design challenges. Design is a creative process and it is easy to hit a dead end and not know what to do next. By stepping back and approaching the project through the lens of a different group of constraints, you can continue to make progress while giving your mind the time and space it needs to work through the more difficult problems.

I hope this post has given you some new ideas that you can put to work in your own design efforts. I would love to hear how this framework compares to your own views on the subject and I encourage you to post your thoughts in the comments section below. Moving forward, I plan to use this framework to explore the process that goes into developing details, to analyze common designs and to continue to explore the form and function of the infrastructure around us.