We, as computational designers, are innate problem solvers. Every time we are given a problem, we jump straight in, our gears start spinning, and we start thinking about algorithms, workflows, etc. We often prioritize actions without considering the bigger picture first. While this feels productive, this action first approach makes it hard to communicate and collaborate with others.

Software developers understand this dilemma. Before thinking about how users will interact with their application, they will first focus on how they will organize their code. They use a concept called object oriented programming or OOP. OOP has been around for a long time and it’s recognised as best practice for developing large-scale applications. It’s a methodology that allows developers to structure their code in a manner that improves communication and collaboration.

Other industries have recognized these benefits and have started their own object-oriented approaches. UI/UX designers, for example, have OOUX. Now, I propose we make our own object-oriented approach: OOCoDe (Object Oriented Computational Design).

OOCoDe is Better for Teams

The reason that working with objects improves both communication and collaboration is because it better aligns with how we think. By defining objects and aligning everyone with these concepts, we ensure everyone is on the same wavelength. This shared vocabulary elevates the types of discussions that you can have with your team.

In the computational design space, we often convey our ideas through a lengthy step-by-step list. We do this because we think that is what they need to know. Even if this helps them in the short term, they won’t be able to contribute because they don’t have the overall context of the solution.

By only prescribing the steps, it’s hard to understand what we are trying to solve in the first place. Shifting to an object-oriented perspective allows us to create and name objects, weaving them into a story to tell others. Not to mention, we can name these objects after real-world things which can improve understanding.

Using stories and objects can make the information way more digestible and lessens the chances of miscommunication.

It doesn’t change the steps or the work that you need to do but it does change the structure and the way you communicate that work to others. Not to mention, by using objects, you can also split your work into multiple parts. You can then delegate these parts to other team members.

For example, in Grasshopper, every object that you define can be script. You can manage and organize a system of Grasshopper scripts that solves your problem. Specifcally, you can use an approach like the grasshopper Distributed Data Model to help you with this.

Build a Platform of Solutions

As your projects evolves, there is no doubt that you will have to make changes to your solution. In a procedural world, this is quite hard to do. Because all you’re left with, is a step-by-step guide you made to solve a specific problem. To incorporate the change, you must revisit each step and determine where to inject or extract new logic.

Using objects provides a holistic view of your solution’s components. Instead of a vague list, you’re presented with a clear visualization of all the moving pieces. This understanding renders your solution more adaptable, as you're more familiar with each component. Instead of steps, objects give you a heuristic on how you might change your solution.

Drawing insights from software developers, they emphasize the importance of coupling between solutions components. A tightly coupled system is resistant to change. Conversely, a system with loosely coupled components is adaptable and flexible. By defining objects and their roles, you ensure that your solution components are loosely coupled. Procedural solutions on the other hand are tightly coupled systems which makes them resistant to change. Change one step and you might break all the other steps.

How do we shift into OOCoDe

With a better understanding of OOCoDe’s benefits, how do we implement this in our current work ? I think it’s best to show this approach with an example. Typically, every project starts with a brief.

Model a toy airplane with a propeller in front.
I should be able to control the length of the fuselage and the sweep angle of the wings
There should be a tail fin and a landing gear too.

Rather than focusing on the details of how to solve this brief -- our default way of thinking. We should strategize an organized solution using objects that addresses the brief. This planning will be helpful when implementing the solution later on.

1. Identify your Objects

The brief helps us make potential objects of our solution. It’s also a chance to establish a shared vocabulary amongst your team working on this project.

So to do that, we can highlight potential objects and relationships from the brief.

Then we can then lay all the objects out so that it’s easier to visualise and work with

if possible, try to keep the name of the objects as close to the brief’s terminology. This will help when you communicate your work outside your team later. It also maps our technical terminology with the real world objects.

2. Fill in your Objects

Now that we have identified our objects, we should define them. Experience plays a role here, because seasoned designers might have a better understanding of what each objects should contain. This is also a good time to have a discussion with your team to clear any differences in interpretation of these objects.

blue represents things the object has, green represents controls

Here, you can be as specific as you want. The idea is to fill your objects up with things that define them. It’s a chance for you to talk to others that more domain knowledge than you.

For instance, you may not know what a “fuselage” is, so it’s in this object definition phase that you get the chance to understand the problem the better and how that relates to your solution.

3. Define object Relationships

Once your are more familiar with your objects. You can then focus on their interactions. This where we define the object relationships and how data will flow from object to object.

This sets up your solution landscape as it gives you a glimpse of all the moving parts of your solution. It also tells you what component needs to be worked on first and what components depend on each other.

For example, in this case, the visualization of my objects tells me that the fuselage needs to be worked on first because every other object depends on it.

4. Iterate

OOCoDe is inherently recursive. When you first define your objects for your solution, you may not get them right. This will become apparent when you start implementing these objects. You might have to re-define and shuffle your objects around. This is normal and part of object design. We can only guess the objects that we need at the start, only by implementing them, will we get a better understanding of what objects we need to have.

When creating and defining objects, A good rule of thumb is when you feel like your object is doing too many things, then you need to split it into multiple objects. Try to avoid making too many small objects or making too large objects. The best object is normally somewhere in the middle but it does take a few iterations to get there.

In this case, let’s say I started implementing the objects and found out that the fuselage objects is really complicated. I found that the fuselage is really two things, the cockpit and the body of the airplane. I can actually change my object definition to suit this new change.

It’s unrealistic to correctly define all our objects the first time for any problem, it needs to go through feedback loops and iterations to get to the right spot.

Final Thoughts

Hopefully by now, you see the advantages that OOCoDe has to offer. By thinking in objects, we can establish a shared ontology with those around us. This not clarifies your solution but also makes communicating with others much easier. As designers, it's crucial to not only solve problems but to do so in a manner that is understandable and versatile. With OOCoDe, we can achieve a balance, ensuring our designs are both efficient and effectively communicated.