What is design automation, and how can you optimize it for your next project?

But before we jump into automating design tasks, there are a few items we need to consider. First, we must conduct enough research to decide whether it makes sense to automate existing workflows—or if it’s even possible. We must also consider the return on investment (ROI). In other words, are we going to save money by automating select design tasks?

To figure these out, we need to ask the right questions before we put time and money into the development. Learning from our previous experience, we’ve listed out the questions to ask before we proceed with development.

1.  Can the workflow logic be written into a code or script?

To encode a workflow, there should be a predefined logic that designers follow. For instance, let’s consider that an engineering calculation process would typically follow building codes. In that case, automating the process will be possible and reasonable.

But if the process mainly requires designers’ experience and decision-making on a case-by-case basis, it won’t be easy to write that into a code since that would require too many user inputs, which would defeat the purpose of design automation.

2.  How many potential users are there if we develop a tool that could automate a workflow?

If the automating script (tool) can be used by more people, it will increase the ROI at the end. For example, if you are automating a workflow that can be used by your entire team, entire office, and even other offices around the globe, your ROI will increase tremendously.

To allow more people to use the tool, we need to consider generalizing it so it can be used more broadly. 

3.  How repetitive is the task?

The more repetitive it is, the more time we will save with the automation method.

For example, let’s say we automated the snow/rain roof load calculations and modeling process. If the roof design changes an average of 4 times per project and there are 5 projects per year, that would be 20 times that the tool could be used for design efficiency. But if we assume that the roof design won’t change, the tool would be used only once per project, resulting in it being used 5 times over the course of a year. In that case, it might not make sense to automate the process due to a low ROI. 

4.   How much time and effort are needed to write and maintain the script?

Most importantly, ROI will always depend on the level of effort needed for the design automation. It would be unreasonable if the time we spent on writing and maintaining the tool is higher than the amount of time we would save with the tool.

Before jumping into development, defining a clear scope and estimating the level of effort is critical so you can decide whether to proceed with the development or not.  If not, you could end up spending more time than you would save by using the tool. 

5.  What can’t—or shouldn’t—be automated?

If we hardcode all steps and values of a particular workflow, the tool will provide no flexibility to its users. Certain inputs and steps should be left as a manual process to allow the tool to be utilized more broadly.

For example, a tool should be developed to allow for different regulatory requirements based on the entity governing a particular project. To allow for this, the tool should allow manual inputs to capture those requirements. This will ensure that the tool can be utilized broadly across many locations.

Also, if the design review process would typically require a manual review process, it would be wise to leave that part to the designers. To ensure that the tools we develop aren’t perceived as black boxes to our designers, engineers, and scientists, we need to make sure that the logic we’ve encoded is transparent and that the values can be exported for a manual review if desired.

6.  Are there any other tools that provide the same functionality you are looking for?

Before developing a new tool, we need to check what’s already available. First, check within your organization. It’s possible that a similar tool has already been developed within the company. Good communication and knowledge sharing within an organization is important, so we don’t spend time and effort duplicating a tool that already exists. Also, investigate if there is a third-party tool that meets your needs. If there is, then compare the cost of buying the tool versus developing your own. There is no single answer to this question, it will vary by the requirements and conditions.

7.  Could you sell your script and commercialize it so you can increase the ROI?

Besides utilizing the tool internally, think about selling the tool externally to increase the ROI. But to commercialize the tool, there are several considerations to keep in mind including the intellectual property, the ownership of the tool, the maintenance of the tool, and if it’s ultimately more valuable as a differentiator to your own business.

At Stantec, we always connect with our legal team for their intellectual property advice, to review if it’s feasible to sell the product, and to decide whether it makes sense to do so.

What are the benefits?

At the end of the day, knowledge is power. So, before you start automating everything, ask the right questions to maximize your ROI. Also, don’t just think about how much you could gain with the technology. Think about how much you could lose by not utilizing it. This is something we should always keep in mind when adopting new technologies and developing custom solutions, as we did several decades ago when we first moved from hand drawing to computer-aided design.

Design automation is a great benefit when used appropriately, saving time and money for countless projects. Want to learn more? Feel free to reach out to me directly.