22 Apr, 2019

Designer Vs Automation

What is design?

I view design as a problem solving activity; where the intent is to reverse the effects of the problem. Further, I think of creativity in problem solving as an overall character evaluated by two parameters: utilization of resources (quantitative/ordinal), and beauty (qualitative/nominal). The first is maximized by meeting the required goal(s) while consuming the least amount of resources. The second is subjectively evaluated by each user experiencing or benefiting from the proposed solution– It is in the eye of the beholder. As such, beauty should not be the basis for any rational discussion about design. It’s personal. This view is not unique to me. A quick online search on the topic will reveal several such views in design methods, optimization, engineering, etc.

Why we automate

There are plenty of good [old] reasons to consider automation: eliminating human-error, delegating mechanical (and at times boring) tasks, ensure consistency, reducing production time, efficient use of resources, and quick sampling of solution spaces, among others. I believe the most important one for design is Mass customization

How to automate, an example

The above is a Rhino 4 Plugin (Yep, I made this back in 2007). It falls under what I described previously as Interactivetive Computation (in these posts).

The idea was to encode a set of design language elements, that are at times conflicting; resolve those conflicts by numerical evaluation and heuristic (subjective) decision-making; and eventually produce a set of house designs that conform to a given style (the one defined by me–the architect).

The plugin allows for generating many options with various entrance designs, different balcony and garden layouts, as well as with columns distribution and window-paneling. The more decisions the user makes, the more constrained the solution becomes.

The process of building this plugin started with a site, (actual) client, and an aesthetics-based exploration coupled with considerations of function. This was followed by iterations of writing Shape Grammar rules to describe the generated designs, which were translated to algorithms and eventually written as a Rhino plugin.

Some benefits

The plugin (tool) provides the following:

  • Encoding of architectural style (completely subjective)
  • Enabling users to contribute to the creation of their own house, but within the guidelines defined by the architect. Thus supporting a process of mass-customization.
  • Support the creation of meaningful alternatives by integrating user feedback where fit. This is in sharp contrast to the common approach of generating 1000s of alternatives while completely eliminating user feedback. The result of which, in many cases, amounts to noise.

Is the designer still involved?

The short answer is “Yes, if they want to.” Here is the thing though, automation is not easy:
– It requires clear, pragmatic, and rational thinking.
– It reduces reliance on design accidents– more conveniently called “aha moments”.
– It removes the opportunity to post-rationalize a project, which is often done to add mystical reasoning for how the design came about; something done quite often but rarely admitted.

Approaching design from a pragmatic lens requires finding a balance and allocating weights [of importance] to the different requirements in a desired solution: culture, client preferences, designer’s style, function, city regulations, cost, time, workflow, etc. Of course, this is not to say that such a process is easy or even recommended. However, it is completely doable.


Automation should come after a less constrained design process. One where designers assume new goals, make up new contexts, and change course without having to deal with concrete real world issues. It should come after experimentation.


The academic and theoretical discussion of encoding design into algorithms is not new, but it’s not old either. It is an on going discussion. Here is a sample of resources on the topic:
Algorithmic-Aesthetics: Computer-Models-Criticism

Automation can serve as a vehicle for mass customization and guided exploration of solutions. It does not alienate designers, but rather formalizes the design process. It is not always suitable or feasible to implement. However, when the time is right, it can increase a design firm’s capacity many folds.

I realize this is a controversial topic in design. So I welcome comments and counter arguments.

Tags: ,

About : Maher Elkhaldi

Maher Elkhaldi is a senior applications engineer at Tesla Motors. He founded the 3DXAutomation blog to help make knowledge of programming CATIA easier to find, and contribute to the open-source community.

3 thoughts on “Designer Vs Automation”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.