Computational Design (CoDe) intersects multiple domains which makes it a challenge to communicate a design process to those unfamiliar with the field. My current role as a CoDe engineer is a good example of this. Since the company I work for is a structural engineering consultancy firm, almost everyone is unfamiliar with computational design principles yet there are multi-faceted projects that have benefitted from Computational Design.

In these kinds of projects, explaining the process to others is tricky as everyone has different backgrounds and is managing different areas. I.e. Changes in the computer science side can impact the structural engineering side of things. But how do you tell a structural engineer that some code you wrote affects their design?

The bottom line 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 have not solved it but I have a mental model that has improved the situation. It’s not an original idea but I adapted the idea from this article and have been using it since.

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 CoDe is the only field that spans all domains. But this does mean that we don’t get to communicate our entire design all the time.

The Functional Developer Scale

The idea behind this scale is to help identify the “level” of technical information that someone needs at any given time. Using the scale, we can curate the information we present. This curation helps us effectively communicate our designs to others. Not to mention, being relevant means people are more likely to listen.

Let’s break this scale down and start from the left.

Functional People

Functional people don’t need to know the intricacies of the design or the process. These are people that only want to know the high-level stuff — overviews, why things are late, etc. They are typically managers or clients.

They normally just want to know a brief summary, the results and the reason behind those results. As such, I often use simple diagrams and text to communicate the design.

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 on this scale 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 high-level and low-level information. If the information is too technical (too low), we risk overwhelming them with jargon. If it is too high level, we would have wasted their time.

To solve this, I first set a base level of understanding to ensure that everyone starts from the same point. These are simple things like explaining the program I am using, what the project is like or the high-level flow of data in the project. Then, I introduce them to the design and how it connects to the overall project.

Understanding their context is also important. We need to know what they need from us and what they plan to do with that information. it also 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. You can also try delegating small portions of work to them to help them get experience with the process/project.

Developers

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

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. The best way I have found is to introduce them to the project/process in parts and have plenty of time in between parts for the information to sink in.

Again, nothing beats the hands-on experience, so if you can, delegate small portions of work to them. But as far as communications go, developers might be the easiest people because they will be on your wavelength, the complication is more on the project and its context.

Final Thoughts

In Computational Design, we are the bridge that connects other domains. We have this multi-faceted knowledge that other domains don’t have and because of that, we are in a great position to help everyone involved better understand the project as a whole.

The Functional Developer scale is a guide to understanding the level of information required by different people in the project. I brought up the three categories as a way of framing the communication. But people aren’t easily categorised, some of them will fall between the categories. In other words, you might have functional-users or user-developers, in then becomes about instinct and experience about what information to tell them.

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.