Let's talk about something we do like about Computational Design: being impactful.
Not just for us, but for others, for the project.
This is the biggest challenge.
Being impactful for a computational designer doesn't rely on your own satisfaction, but on others.
It depends on how often your colleagues will be using it.
It depends on how efficiently it automates its aimed task.

At this stage, creating an impactful solution as a Computational Designer means being able to create a solution which not only solves a problem but most importantly matches people's ways of working.
Without them questioning constantly which actions is done under the hood, which calculations have been performed, which formula is used or even why is the result not the one expected.

If they use it, they expect the tool to provide the right answer, the correct results.
Because yeah. As a computational designer, you have only one chance. Engineers' trust takes years to obtain, and seconds to lose.
They won't give you a second chance. The first tool you give them has to work.
Here are simple actions to maximize your chances:

1. Analyze the workflow

Whenever you upgrade something in your car, you make sure it's compatible with everything else right?
That's the same with developing a tool or a script:
Analyze what are the inputs, outputs and constraints the solution need to consider.
Why it matters?

Because by doing so, you maximize your chances of adoption.
It makes sense for the user to use your tool. He/she knows what you feed to the tool and what the outcome will be.
And the value of this tool? It is much faster than manually done! (Another article coming soon :) )

Same inputs, same outputs (or better), less actions. There are only benefits in using your tool. Sounds like a win to me.
The adoption efforts from your users is minimized. And engineers HATE to change working methods.

Key factors to consider for inputs:
- Which data do you need?
- What is the format of those data?
- Where are they stored?
- Who updates them?
- How are they updated?

Key factors to consider for outputs:
- Which type of output is it?
- What's the format of the output?
- Is it used by another software downhill?
- Does this software support any automation?

2. Build for the workflow, not for you.

Something I noticed when diving into computational design is that I wanted others to use my tools.
But I can't force them right? So I built solutions and script that matched as close as possible their workflows. That's why I usually ends up spending more time studying how the overall process flows rather than developing itself. I would say for a script, I spend 60% of my time evaluating the process and 30% developing. The rest goes into testing.

Interesting point I'd like to raise.
Analyzing the workflow might have lead you to a weird conclusion: You don't need to develop anything.
Yes. We don't talk enough about this but not every problem needs a coded solution. For me and at PatchWork, Developing a solution means to implement something that solves a problem. Meaning, a simple change of habits, changing folder hierarchy or even merging excel files can be a solution. Not necessarily diving in code right away.

In any case, you now have sufficient information to create a solution.
In your opinion, which of the key factors listed for the inputs will shape your solution?
It is the How and the Who.
Any idea why?
Because Who and How involve people. 

Let me make it more clear:
2 chefs with EXACT same background have the same list of ingredients (=same data & format) and will serve their respective VIPs.
Very honestly, do you think they will cook the same dish despite having the same ingredients?
Of course not!
Because the people they cook for have different preferences.
A little saltier or sweeter.
Crunchy or soft.
Warm or cold meal.

 Satisfying those preferences, or I would say "main requirements", will make the dish delicious in the eyes of the customer.
That's the same with creating a solution: my main requirements are the people.
Their actions.
Their preferences.
Because the people shape the workflow.
So, build for the workflow, build for the people. 

3. Test it with people who know you.

It is important to carefully consider the testers. You don’t want to involve everyone at the same time.
The reason is they don't have the same interest in automated working method, they're not all innovation-sensitive.
The colleagues who know and approach you are genuinely interested in what you do.
You have more chances to have valuable feedback and see the adoption rate grow.
If you did well, they will use it naturally. Their colleagues will see them and may be interested in it too. Step by step, you might see a growing interest in their eyes toward your solutions.

4. Deploy small, then scale it.

Finally, I want to finish with the biggest killer move in computational design: Overdesigning the 1st version.
Many of my students want to create the perfect script doing nearly everything.
But in the end, they never release it because they are stuck on 3 features while 10 others are remaining.
Worse, some manage to deploy and test it, but the users are not satisfied. They spend more time giving feedbacks than actually using it.
On your side, you will be overwhelmed updating all those things. Once it is done, they're not here anymore.
You lost them by being too greedy in the functionalities.
For this reason, I advise to select one functionality only and make it as clean as possible.
Deploy it and see how people respond. You can always build additional features above it after. 

Thanks for reading, and as always, I'm here to support you in your journey! For those looking for extra guidance, check out my newsletter, explore my courses or join our community.

Let's grow together!
Benjamin Tan