What is design automation, and how can you optimise it for your next project?
February 02, 2022
7 questions to ask yourself when considering automating design tasks
Share
As designers in the 21st century, we are constantly adapting to new and emerging tools and technologies that help us do our jobs better—and more efficiently. One of the more prevalent tools in the industry as of late has been computational design. It allows us to solve design challenges by encoding design decisions and includes design automation, option generation, and design optimisation.
Computational design is used across a variety of sectors for many project types. And design automation, especially, has been utilised broadly in the industry since it can save a significant amount of time and money. This reduces time spent on repetitive tasks while limiting the number of errors in the process.
Design activities can—and are—being improved and augmented with design automation, with applications ranging from automating simple daily tasks to automating complex analysis and design problems. Our teams at Stantec have been actively utilising design automation technology to improve our design and delivery workflows. We can use it for a wide array of projects, such as automating the interior layout of a building, pump station design, levee and floodwall design, stream design, pipe network design, bridge design, and more.
Share
It’s important to ask questions when considering the value of design automation.
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 generalising 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.
Don’t just think about how much you could gain with the technology. Think about how much you could lose by not utilising it.
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 utilised 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 utilised 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 organisation. It’s possible that a similar tool has already been developed within the company. Good communication and knowledge sharing within an organisation 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.
One of the key questions when considering design automation: What can’t or shouldn’t be automated?
7. Could you sell your script and commercialise it so you can increase the ROI?
Besides utilizing the tool internally, think about selling the tool externally to increase the ROI. But to commercialise 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 maximise 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 utilising 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.