What Do You Actually Deliver?

A Solution or a workflow or a system ?

When you work with someone in computational design, it’s hard to know what you get at the end.

Is it a script? Is it a plugin? What is it?

A few years ago, I wrapped up a project for a client, let’s call him David. We’d spent days going back and forth on requirements, I’d built exactly what we discussed, and I sent over the final deliverable. A Dynamo script. Clean, well organised and it solved the problem perfectly.

But well... David called me back. “Do I double click this?” he asked, pointing to the weird “.dyn” file. He thought I was making something that he could just click and it runs. Not a script that he had to open and navigate. He wanted something his team could use easily, not teach them how to use Dynamo.

I technically held up my end of the bargain, we just never talked about what the solution was. I should have known when he was surprised how quickly I gave him the script.

And that’s just one example of miscommunication.

One of the biggest lessons I’ve taken away after working with clients, teams and managers over the past few years is that everyone has a different idea of what computational design actually means.

Some people only think of Grasshopper. Some think computational design is just fancier IT or software development. When someone asks what I do and I don’t want the conversation to go further, I tell them I’m a software developer. It’s quick, easy, and most people can imagine me sitting at a desk, coding away.

But none of it represents what we actually do. There’s no easy way to describe it without sitting down for at least five minutes.

So instead of explaining what I do, I started getting clearer on what people get. And the vocabulary that’s helped me the most is describing my deliverables as Solutions, Systems, and Workflows.

The question that separates them: Are we solving for now, or solving for always?

I know this sounds like I’m being overly pedantic about terminology. But stick with me. Because after years of doing this, I’ve found that these three words prevent more miscommunication than any proposal or scope document ever could. Also, if you ever struggled to explain why people can’t just reuse scripts all the time, this might help.

What’s a Solution?

A solution is my catch-all term for anything digital I can deliver.

This means it could be a series of Grasshopper or Dynamo scripts that make up a workflow. Or it could be a Revit plugin or a standalone program (web or desktop) which functions as a system.

I use the word “solution“ when I don’t yet know what exactly I’m making. In proposals and early client conversations, it captures everything that’s possible without implying too much.

I actively avoid words like “script” or “tool” at this stage because they carry baggage. “Scripts” imply one-off, quick, maybe even a hack to solve the problems. “Tools” suggest something big, reusable and maybe expensive. At least solution is neutral, it says we don’t yet know how we’re moving forward, but we are finding a solution to the problem.

Once we do understand the problem better, we move into the next two categories.

A Workflow Solves the Problem Now

A workflow is my term for anything short-term or project-specific. Most commonly, this is a Dynamo or Grasshopper script. These solve actual problems on projects. They can be reused throughout the project’s lifespan and for similar problems, but they’re not scalable.

I avoid calling workflows “scripts” because they’re often multi-step and multi-program. A Grasshopper script that outputs an Excel file that feeds into a Dynamo script, that’s a workflow, not a script.

Workflows aren’t scalable because they often have poor user interfaces or require ritualistic setups. Grasshopper and Dynamo are powerful, but they’re hard to setup, navigate and maintain. Not to mention teaching everyone how to navigate a script is a hard thing to do.

But workflows are extremely valuable when timelines are tight or you’re solving a one-off complex problem. Like Grasshopper still specializes in handling complex geometry, building a system to do the same just won’t cut it.

They are also valuable for exploring what a solution should look like. They let me build things quickly without worrying too much about robustness or the user experience. It’s a great way to prototype something or deliver a quick win on a project.

If you’re after something more stable, though...

A System Is Something You Use Over and Over Again

This is what most people picture when they hear “automation.” It’s a button you click and the system just solves the problem, again and again. It’s closer to traditional software development. And a system is easy to share, easy to use, and quite stable.

Most of the time, these are plugins or standalone programs. A Revit plugin, a web app or even a desktop app. I’ve also built scripts that functioned like systems, but given the lack of deployment tools, that’s rare and usually limited to simple tasks.

Given what you’ve read, it may feel like you should only focus on making systems, after all they are reusable and robust. But they take longer and are more expensive to make. So whether you make a system or a workflow will always depend on what kind of problem you are solving.

And if you already have a workflow, trying to scale a workflow up to a system takes a huge amount of effort. Effort that’s usually unrelated to solving the original problem and instead solving the problems that come with scale. Things like the user interface, deployment, updates, etc.

Sharing an Excel workflow is just handing someone a file. Sharing an Excel plugin as a system means handling IT permissions, installation processes, deployment, and more.

A system is more robust and scalable than a workflow, a button to press in Revit will always be easier than opening a Dynamo script. But it takes more development time, and sometimes it’s the wrong solution entirely.

Using the New Vocabulary

It took me a while to land on these words. But once I did, talking to people about what I do became so much easier.

Now, when someone describes their problem, I use these terms to explain exactly what they need:

• A system for anything reusable and scalable

• A workflow for anything one-off, prototyping, or project-based

• A solution when we don’t yet fully understand the problem

Ideally, you’d establish this vocabulary from the very first conversation. But the reality is, most of these clarifications happen mid-project, when someone realises we’re not on the same page. That’s fine. Better to align late than never. But I tend to use these terms at the start of every engagement now.

The clearer I am about what you get, the more aligned we are on what we’re solving.

Thanks for reading
Subscribe to CodedShapes and I’ll send you my free guide on how to actually do that

P.S. If this helped clarify how you think about what you deliver, or what you’re looking for, I’d love to hear about it. Just reply to this email.