Computational Design (CoDe) intersects multiple domains simultaneously, making it challenging to communicate a design process to those unfamiliar with the entire field. Especially, if you work with others in a cross-disciplinary project.

My current role as a CoDe engineer is a good example of this. Since the company I work for is primarily a structural engineering consultancy, almost everyone is unfamiliar with any computational design principles.

💡 The figure above simplifies my current CoDe involvement. In reality, it involves many other domains.

However, explaining how changes in one area, like the computer science side, can impact the structural engineering side of the project to people not directly involved can be difficult.

i.e. It’s like trying to convince someone how a completely unrelated field affects their work.

Essentially, the question is: how do we communicate a cross-disciplinary design process to everyone involved in the project, regardless of their current involvement?

The answer isn’t as straightforward as one might hope. I don’t believe to have solved it but do think that I have a mental model may help the situation. It’s not an original idea but I adapted what I read from this article and it seems to work quite well.

I believe it's all about context. It's about understanding what is relevant and what people want to know. Our role in CoDe is to be a bridge and deliver the right amount of information at the right time because we are the only field that spans across all the domains. But being relevant does mean that we won’t get to communicate our entire design.

The functional to developer scale

This scale helps to determine the “level” of technical information someone on the project needs at any given time. Using the scale, we can tailor the information given, depending on the audience.

This helps us effectively communicate our designs to others. It also means that people are less likely to checkout as we aren’t bombarding them with technical jargon or irrelevant information.

Functional People

Functional people don’t need to know the intricacies of the design or the projects. These are typically managers or clients.

These are individuals that only want to know a high-level overview of how things work without the raw specifics. The normally just want to know the brief overview and the results. As such, I often just use simple diagrams and text to present the design, rather than demonstrating the actual tool or program I am using.

The idea is that these people just want a basic understanding of the overall process, not to become hands-on with the project. To ensure the approach is right, I imagine explaining my work to a 10-year-old.

Users

Users may be the trickiest category to explain the process to because they're typically involved in only certain parts of the project or will be using what we're building.

It's a balance between providing high-level and low-level information. If the information is too technical, we risk bombarding them with jargon. If it is too high-level, they don’t get any useful information.

To solve this, I first set a base level of understanding to ensure that everyone starts from the same point. Then, I introduce them to the design and how it connects back to theirs and the overall project.

Understanding their context is important. We need to know what they need from us and what they plan to do with that information. it also really helps if we can connect our design to their work and help them make that connection. The most effective way to do this is to hold multiple workshops and have frequent discussions.

Developers

Developers are people that are in the weeds with you. They're often your fellow CoDe peers working on the project alongside you.

💡 I use “Developer” here because that's what the original scale used. It means the people in this category are directly modifying and contributing to your work. They need to know the design process in detail to be useful.

Although people in this category might have CoDe experience, it’s still important to consider how to explain the design process to them, especially if they join the project at a later stage.

To do that, introduce them to the project in stages. This normally means I begin with an overall context of the project then how the current design process works as a whole and finally the specifics of the design.

A useful approach is to delegate a small task to them, which immerses them in the project and builds their experience with the current design.

Final Thoughts

As Computational Design spans multiple domains, we are the bridge that connects other domains. Because of that, we are in a great position to help everyone involved better understand the project as whole.

The Functional to Developer scale is a guide to understanding the level of information required by different people in the project. I brought up the main three categories as a way to frame the communication but some people may fall between the three categories. In other words, you might have functional-users or user-developers.

Effective communication in a cross-disciplinary project isn't about divulging every detail; it's about giving the right information to the right people at the right time.

Thanks for reading

Braden.