I sometimes get the opportunity to build computational design (CoDe) tools for others. It could be a Grasshopper workflow to automate a repetitive task, or a Dynamo script designed to solve a Revit problem.

It is actually rare to have someone ask for a tool because the integration of CoDe into existing workflows challenges traditional longstanding practices. So, when people come to us for tools, it’s our job to ensure they feel acknowledged and supported. People’s perception of CoDe, shapes their relationship with you and can influence the design of the tool.

Making a good CoDe tool is quite challenging because, unlike software development, CoDe tools don’t offer a good user experience or interface. There isn’t a way to cleanly separate the user interface (UI) from the logic of the tool. Given that we work with programs like Grasshopper and Dynamo, users will often have to come face to face with the pure logic of the tool which can be overwhelming.

That said, I have been making CoDe tools for over 2 years now and have learned a lot since. If you find yourself making a CoDe tool for others, here are some points to consider:

Consider the Scope

Once collaborators agree to go on a new tool journey with you, it's natural for them to have a lot suggestions. Given that CoDe is a new and unfamiliar concept for many, it's often viewed as a magical "silver bullet" solution. Which means, it falls upon us to temper their expectations and set realistic boundaries. So, before you start developing your tool, you should first define a scope. As in, what your tool does and doesn’t do.

While the ultimate aim is to solve every problem that people have, it’s not possible to do so on the first try. We need to triage all the problems and suggestions that people have and make a CoDe tool that addresses the most meaningful problems first. This is very similar to the practice of coming up with a minimum viable product (MVP) in the software world.

Even if your tool is set out to solve 100 different problems, you should still start with an MVP. The concept is that you should start small and solve the most impactful problems first and then look to solve other problems later. By starting small and prioritizing what to solve first, you can deploy your tool sooner, which means you get feedback sooner. This then kick-starts a design cycle that allows for quicker refinements and improvements to the tool.

So, before developing the tool’s logic, consider having discussions about the scope of the tool. Try to have these discussions early on because most users don’t know the solution. They just know they have inefficient processes that could benefit from some "CoDe magic." It’s our role to set expectations and solve their biggest pain points first. So, gather all the problems and suggestions that people have and prioritize them based on their impact. Then, use this hierarchy to make an MVP and maybe plan for future developments.

Consider the Users

Understanding what your tool does is crucial, but equally important is understanding who will be using it. We already know we can’t avoid users using our CoDe programs, a Grasshopper script needs the Grasshopper environment, but we can minimize how much “mess” they see. By using things like Human UI or Dynamo Player, we can hide the "mess” of the logic from the users.

But by simplifying the user interface, we are taking away control from the user and adding extra complexity to the tools. This means when we create tools, we need to consider how comfortable our users are with our CoDe programs — like Grasshopper or Dynamo. The more willing they are, the more control we can expose to them.

When we get the chance to make CoDe tools for others, it’s essential to view the endeavour not as a product but as a collaborative effort between people of different skills. This collaboration gives us a chance to guide others in using CoDe principles. It also lets us learn from others and gain insight into how CoDe can be used in different facets of the industry.

So, always consider your user’s willingness to use CoDe programs because it can impact the design of the tool. It also influences your interactions with your users. But if they aren’t open to learning or collaborating, we might have no choice but settle on putting in the extra effort for a user interface.

Final Thoughts

The creation of computational design tools is as much a technical endeavour as it is a human one. I believe that CoDe is about enhancing and complementing existing processes, making work simpler and more efficient. Building tools is a great way to get insight into how other people work and how we can help them.

It is not just a task, but a collaborative effort to understand and interpret the problems that others face. It’s a chance to spread some CoDe knowledge, a chance to create something truly impactful to others and a chance to learn more about how other work.

So, the next time someone approaches you with a request or an idea, take a moment to consider what kind of tool they need. Sit down and have the conversations to plan out the work you need to do to help them solve their problem.

Thanks for reading.

Braden.