Computational design (CoDe) projects are notoriously messy. They don’t take on any traditional project structure that most of us know and love (or hate!). This is because computational design can be a part of everything. This wide spectrum of problems means it’s hard to define our own process. Without a process or structure, it’s hard to communicate what we do to others.

As I have been apart of many computational design projects, I have noticed a repeating pattern in them. I think these patterns can loosely form phases of a typical CoDe project. I think for every CoDe project, there should be at least three core phases.

Phase 1 - Explore

When I get engaged on a project or a problem, I don’t actually know whether we can help them or not. People generally have different ideas and expectations to what CoDe can and cannot do. It’s our job to turn those problems into something solvable as well as manage their expectations.

So, this phase is all about exploring the different ways that you can solve the problem. The goal is to understand the context of the problem and how the solution looks like. The most effective way is to have conversations with the key stakeholders of your project/problem.

Here are some points / questions to consider in these conversations

• Is there any existing data that you need to get started ?
  • If so, where can you get them and are they up to date with the project ?
• What does the solution look like ?
  • As in, what are you making ? A tool ? A grasshopper script ? What are you delivering to them ?
• What does the workflow / process look like ?
  • Are there frequent changes to the project ?
    • If so, where do they come from ? clients ? other internal people ?
  • Are you expected to be involved in the entire project ?
• Do we even need a CoDe solution here ?
  • Are there existing products that already do this ?
• What’s the timeline / budget ?

Use this phase to get acquainted with the project/problem. Understand the role that you or your team is playing and explore different potential solutions. At this point, I also find it useful to create prototypes to test the assumptions that people have. These prototypes should just mimic the overall process that the solution might take on but are important because they can “stress test” the current assumptions.

Phase 2 - Develop

By now, you should have some direction on the project in terms of it’s solution. It’s time to do what we do best and just solve the problem. There isn’t anything new to bring up here but here are a couple of points to consider in this phase

Be Open and Communicate Frequent

As you develop your solution, you should frequently communicate with the other stakeholders. Some times as we create scripts or solutions, we get too focused in our work and don’t communicate our progress to other people. Regular updates ensures that everyone important is up to date and that there are no surprises. Also, try to be as open as you can about setbacks and any faults that happened along the way.

Consider Testing

If your problem has measurable outcomes, you should consider testing your solution against them. This may sound obvious but given the pressure and rush of projects, it can be easy to miss this step.

Since I had to create models from engineering plans and mark-ups, testing meant that my model needs to comply with all the dimensions and specifications of the plans. It was a good reference to have to ensure my solution was accurate. Figuring out how you can test your solution will make it more robust and effective.

Consider Creating a System

If you find that you are doing things repeatedly,, consider systemizing the process. Create things that can either automate or expedite the manual processes. But as this can take more time, be sure to communicate the extra time needed and it’s benefits to your stakeholders. Even if you aren’t working on the solution directly, systemizing a process will pay off in the long run.

Phase 3 - Reflect

Once you have something that works, it’s time to do some reflection. Most of us (me included) never take the time to look back on our projects. But it’s good to extract out any lessons from the project and reflecting also feeds our understanding of the way we work. To do that, I like to ask myself these questions after every project

• What went well and what didn’t ?
  • Are there specific lessons that you have learnt from this ?
  • Are there things that you would change if you could start all over ?
• Are these tasks that you can do now to make your future easier ?
  • Meaning, are there things you can organise to make things easier to find in the future ?
  • Are there loose ends that should be tied up ?
  • Can / have you documented the solution?
    • if you were to re-visit the work 6 months for now, can you understand what you have done ?
• Are there universal reusable logic that you can take out ?
• Can you create presentation material out any parts of your solution ?
  • It’s good to extract out any presentable parts for marketing or even just your own portfolio.

Phases aren’t Chronological

In projects, these phases don’t often happen chronologically. It isn’t just a simple phase 1 → 2 → 3. They often jump around and follow something like: phase 1 → 2 → 1 → 2 → 3. Assigning “phases” are just ways of categorising the work that we already do. It’s perfectly normal to go back and forth between phases in a project.

Final Thoughts

These phases are just the way I think about computational design projects. I have benefitted from looking at how other industries defines their stages. Like the double diamond design for creative processes or the Agile way for software developers.

I don’t yet think there is a framework that will perfectly fit every project, but by putting names to things, we can better communicate the way we work. This communication brings clarity and understanding to those around us. They also help shift the mindset when it comes to solving different phases of the problem. I.e. a planning mindset in the first phase and a problem-solving mindset in the second. The phases help encourage the different modes of thinking.

Thanks for reading
Braden