Design Automation for Architectural Design in Small Steps

BRIEF

PROBLEM: Architectural design is a complex process that often involves repetitive tasks, human errors, and inefficiencies that can slow down workflows. While Building Information Modeling (BIM) tools like Autodesk Revit have significantly improved design and documentation processes, the absence of structured automation continues to limit optimization, particularly for architectural design firms. Many firms struggle to implement automation effectively due to the overwhelming complexity of scripting and computational design tools.

SOLUTION: A stepwise approach to automation is needed to enhance efficiency without overwhelming complexity. By integrating parametric scripting and rule-based automation in small steps, architects can enhance efficiency while maintaining design control.

OUR FOCUS: This research focuses on the potential of stepwise automation using Revit Dynamo, a visual programming tool that enables parametric design and process automation within Revit. The study investigates how structured implementation of automation can streamline workflows, reduce human errors, and improve overall efficiency in architectural design. By making automation more accessible and manageable, this approach aims to bridge the gap between traditional design methods and advanced computational tools, ultimately empowering architects to work more effectively.

PODCAST QUESTION

INTRODUCTION PART

Angelica: Welcome to today’s episode of MACAD IAAC podcasts. I’m Angelica Ignateva.

Scott: And I’m Scott Lebow. Today, we’re diving into the world of architectural design automation—specifically, how firms can implement automation in manageable, incremental steps rather than overwhelming overhauls.

Angelica: That’s right, Scott. While BIM tools like Revit have significantly changed how architects work now, many firms still struggle with implementing structured automation that could dramatically improve efficiency and reduce errors.

Scott: We would like to welcome our guest, Mostafa El Ayoubi El Idrissi. Mostafa is the CEO and Co-Founder of Orkestra Online and the creator of Data-Shapes Dynamo package and focuses on creation and deployment of design automation tools. Much of Mostafa’s work explores lowering the barrier for AEC designers to transition into automation tool creators.

Angelica: Mostafa, welcome to our podcast! Thanks for joining!

Mostafa: Hey! Well, thanks a lot for having me!

QUESTIONS PART

Question 1

Mostafa: I would say that design automation is anything that enables faster iteration. That’s mostly what I try and focus on because that’s where it’s getting crucial. Project turnovers are getting faster and faster and harder and harder. So the idea of being able to iterate faster, think, a very competitive, I mean, gives a competitive edge.

Scott: Let’s start at the beginning. Mostafa, how would you define design automation in architectural design, and why is it essential today?

Question 2

Scott: So, speaking of those iterations, you’re very focused on Dynamo in your work. So we think it would be helpful if we could define Dynamo and how you see it being used specifically in streamlining those iterations.

Mostafa: Okay, so defining Dynamo, I’d say like if I was to introduce someone who’s never heard of it before, I’d say it’s a visual programming environment. And what it means is that it’s the same thing as programming, where you type code and you’re giving instructions to a computer. But instead of doing that with code, because that takes a lot of training and well knowledge that architects and engineers in the AEC industry don’t necessarily have, you get to do that. give the computer instructions, but through a visual interface, which is easier to approach and to wrap your head around when you’re not familiar with coding. So that’s what Dynamo is. It’s a way to do code when you don’t know how to code, but you put it differently. And that’s why it’s very valuable because people in the industry have their knowledge, like they have their field knowledge. They know exactly what they need to do, what it is that they need to produce better than a programmer that has no knowledge of the AEC industry at all. But yeah, it’s a way for them to get that automation going with their very specific knowledge. Does it make sense?

Scott: Yeah, thank you.

Question 3

Angelica: You’ve created tools that extend Dynamo’s capabilities. Can you tell us more about Data Shapes and Orkestra Online? How do they help professionals in automation?

Mostafa: Yeah, well, in a funny way, DataShapes and Orkestra Online sort of do the same thing in the grand scheme of things, but it wasn’t planned this way. So what happened, to give you a little bit of history, is I was on a project that could not really be made without Dynamo because it was geometrically complex and it was, Revit was a requirement and we had to do it in Revit. And at the time, like you had no Rhino inside Revit or things like that that could help with these types of things. So Dynamo really sort of became the only solution. And that’s what got me into it. It was one of my first experiences working with Dynamo and I was building tools, but, at some point, I had to share those tools with other people who needed to use them, but that’s where I realized that not everyone was happy to work in that spaghetti environment. I had a lot of fun doing that, but it could become intimidating for other people, especially when it got big. You would come up with errors that you wouldn’t necessarily understand, so it would become a hard thing for them to adopt. And that was actually the origin of data shapes. I needed those tools to be usable for other people who did not want to have to open scripts or like to interact directly with the nodes. So that’s what Orkestra was about. And it sort of resonated with the general community of Dynamo because I think there were lots of people in my situation building valuable tools that really addressed a very specific issue that they were having within their firms. So they had that value, but it was hard to share. And they needed an interface, like just a user interface. It’s just as simple as that. Having a user interface slapped over whatever is going on at the backend and making it easier to use for them. And that’s how we got some traction and people started using it. And I think that’s a pretty well welcomed package in the Dynamo environment. And then Orkestra is taking the next step of being able to, well, share those tools in a very, very seamless way. i know, like once you’ve managed to build a tool that people can use, it’s pretty cool, but you still are going to stumble across things, stumble upon things like packages. You need to make sure that everyone has the right packages on their computers. For example, if you’re using data shapes, you need to make sure that they have the right version of data shapes to work with. whatever version of private they’re in, et cetera. Another thing is documentation. You can have lots of tools, but if you don’t explain what they do in an easy to browse way, like an easy to find way, people are not even going to be aware of what tools are out there. Just like to take the case of architecture firms where there’s a large turnover, people come, people go. You can have hundreds of tools. that do very specific tasks and that are very valuable. If people don’t know that those tools exist, they’re going to redo the work manually. So that’s why having a platform like Orkestra or other tools that enable you to build a knowledge base comes in handy. So that’s really what I’ve been doing with data shapes and then Orkestra trying to ground their way.

Scott: Yeah, I think I found similar issues where we can create lots of scripts and they can do a lot of meaningful helpful work and time saving. But if people are not able to understand them or deploy them on their own, then it’s not worth the time that we spent.

Question 4

Angelica: It’s fascinating to see how you’re making automation more accessible. Can you share your journey into design automation? How did you transition from a Dynamo user to a specialist?

Mostafa: So, I guess, yeah, that first experiment that I had, actually, yeah, I’ll just share like one very simple thing, which was… So, you mentioned it earlier that there was a project that got me into Dynamo because I had no choice. And it was the subway in Doha, Qatar. That was back in like 2015. So there was, what did I type here? Yeah, maybe I’ll type in UN Studio as well. Because there was a concept by UN Studio that looked something like this, right? And it was very modular, right? So it had logic. Architecture teams that were to deploy this schematic design had a sort of a guide, like a guidebook with guidelines. Dubai? No, subway.

Mostafa: And they had the actual geometry of their stations and the actual conditions of the stations. But they had to adapt this work into that actual geometry. This was theoretical work, and it had to be made realistically feasible. And all of the stations had this branding. They called it the branding with very specific elements, like these things. Those were the downlights. Those were the vaults. These things were called shelters. When you read those rules, they would go like, okay, we start one point, then we draw a spline that goes like six meters, and then the control points would be at 40% height, et cetera. But all of this would be calculated based on constraints, like geometric constraints that you would have on site. And yeah, that was the job. And it had to be done in Revit. So you would start manually building an adaptive component or whatever, but it would break so many times. The rate of iteration was so fast that there was no other choice than to try and automate this. And so I started working with Dynamo and started building scripts. And I found this old thing here, which is like one of the elements. it’s the vault here that you can see in this picture. And this was the script building it. And this was sort of like the final form of the script. Before this, it was like, as I was learning, I was doing lots of bad things and like I had hundreds of nodes all over the place. And by the end, I sort of decided to go with Design Squared for a more condensed approach of things. yeah, it would look like this. And this was really what got me into this. And then I realized that it could apply to many, many other things, whether it’s like, so the documentation part of things is also something that is very repetitive and needs to be updated with very few errors. So that is also something that I spent a lot of time automating, documentation work. And I guess I somehow fell in love with the process at some point and started typing Diver into this and developing the package. And I guess that’s where you could say I sort of became a specialist because people would come to me for this type of work. So it happened gradually and naturally. And yeah, that’s how it happened.

Scott: Thank you for sharing this. I think a lot of people’s journeys are similar, especially with Dynamo. And I think it’s very interesting that you also think it’s like a middle step for a lot of people to have a mix of Python script and nodes and design script. I sometimes open my old scripts and I see that and it’s very nostalgic to see for me too.

Mostafa: Yeah, for sure. You could see those steps. It’s almost visual!

Question 5

Scott: So, for firms who are new to automation, and this is, I think, the key to what we’re trying to explore in this interview, what’s the smallest meaningful step that they can take to start deploying Dynamo for Revit in their firm?

Mostafa: So, there’s the deployment part and then there’s like the creating the tools part. So like, yeah, you’re more focused on the deployment. I think what we want to focus on is not so much how you would create a tool, but more how you would take the tool that’s been created and take it from being the single user who created it, who’s using it, to everybody having access and everybody being familiar. This topic is very, like it’s a very dear topic to me, like I’ve, I’ve spent so much time thinking about this because I went through all of the steps and the blunders, you know, like that you could go through. And yeah, that’s again, what was behind Dynamo and DataShapes and Orkestra I mean, I guess what I could do here is share again.

Mostafa: Maybe a couple of slides. So those slides are from when I ever introduced people to Orchestra. And I really don’t mean this to be like in any way a commercial or anything. So I’ll just focus on these parts here, which start the reasons that can get you to think deeper about your deployments, right? Like it’s not just about throwing files somewhere because that’s just not going to work. And the reason why it’s not going to work is all of the pain points that, well, I’ve identified along the way. First one, and this is the biggest roadblock is the packages. So you need to figure this out. Absolutely. Now you were talking about small meaningful steps. One way, I mean, one of the first things to identify if you’re really serious about getting tools to go out there is to either limit yourself to like, no use, not using packages at all. Or if you are using packages, you absolutely need to have a strategy on how to get them across because this is what’s going to make things not work at all. not like a sort of work. It simply will not work and it needs to be figured out. Then there’s the other pain points that are revolving. like from a user standpoint, you’re on questions such as what definitions are there? You know, if they’re not aware of the content that’s being made available to them, they’re less likely to use it. So it’s very important to communicate. That would be a very meaningful thing, a meaningful step to take if you’re trying to get tools across. You need to communicate. And it can be many things. the things I do for firms that I work with as a consultant on these topics is a weekly 15 minute video presentation, like on Teams. People would all jump in the Teams for 15 minutes because everyone has 15 minutes to listen to it like a radio show. And I would cover one topic that would usually be something that came up during the week and that we solved in some interesting way. And we just share that with other people. And that makes them more aware of things that are possible. So they either have the exact same problem and they know how to fix it. And they know that there’s a tool for it. Or they have something that gives them the idea of going through the same process. So yeah, it’s just like raising awareness. Then there’s things like, what does this definition do? How do I use it? So documentation is very, very important. You can’t throw a script out there and just name it in some way and expect people to understand how it’s going to work and what it does. You have to document it and plenty of solutions out there. Now, Notion is great for knowledge bases. You can even have a SharePoint. can have many things. Orchestra does this in its own way. That’s the most efficient way I could think of. And then there’s the versioning and version control. It’s also something to really be wary of, especially Dynamo has sometimes different behaviors and different versions of Revit with different nodes that are going to exist or not, or API methods that don’t exist in versions of Revit and things like that. It’s also something to be very worried about and to try to address. So you need to make sure that people are looking at the right tools for the environment that they’re working on in order for things to just go as smoothly as possible. And then there’s another thing that I would recommend for admins. they’re, mean, what I call admin is a person who’s building tools and trying to share them and get some usage. I would strongly encourage them to figure out a way to know how the adoption is going. So this can go many ways. Like there are some extensions, there’s a binoculars extension that gets your usage information written into like a Google Sheets. There’s also, you can have a little node that writes into an Excel sheet. You can come up with many ways to do this, but it’s important because if a tool is not being used at all, there’s two reasons. Either it’s not as useful as you think it is, or people are just not aware that it exists. And in both cases, there’s an action to be taken by the person who’s building that tool. So you either figure out why people are not using it, make it better, or just communicate more about it. And yeah, the documentation part, but still the same issue, just a different way to look at it when you’re the person building the content. But yeah, definitely important to figure out a way to get some feedback as automated as possible. From the users.

Question 6

Angelica: Yeah, thank you very much. It was very insightful. And what do think how these firms can build a structural automation framework to expand on these initial steps?

Mostafa: Well, if we’re talking about Dynamo, actually, I guess this could apply to Dynamo or RhinoInsideRevit, any tool you’re trying to deploy. I would say that it’s important to, like for firms who want to be serious about it, it’s important to give it the right amount of investment and, by that, mean like time wise and, you know, sometimes money wise, but yeah, you can’t just expect it to work. It’s a job and it’s a job that needs tools, you know, for the same reason people need Revit to, to build, like do their drawings. If you want to automate tools and deploy automation, you’re going to have to manage enough time and resources for some people to do it. And it’s very important to, yeah, raise awareness about that too, because, what happens too often is someone gets passionate about it and starts doing it and then it starts to become a burden on their shoulders because people are sort of like they have that expectation that it’s going to go fast if this person is doing it or whatever and it’s just like usually something that starts coming on top of other things that that person has to do like on a on regular basis and It just becomes hard to maintain you get people burning out to get people to just like get disgusted by it. And it can be so different by just identifying that this has value and providing these people who have this value with the resource to do the work.

Question 7

Scott: Yeah, I would say that this is one of the most crucial things for this type of strategy to pick up. I think you’re describing a lot of the fellow students in this program too. Because we’re all enthusiasts who have industry experience. And I think many of us have the same story where we need that extra education and support and you don’t always find it in the workplace. So briefly, do you think you could identify a real world case where you’ve seen a success story and what lessons you might have learned from that to adjust your thinking on implementation? Speaking of firms, can you walk us through a real-world case where you helped a firm scale from minimal to advanced automation?

Mostafa: Real life use, mean success stories. Well, I have a couple that come to mind, but I guess they were at different stages of my own journey. It was this, yeah, I guess the case that I was mentioning earlier, the subway in Qatar, that was a success story of its own because at first I was like, advocating for doing it this way. And people would not necessarily agree because like not everyone was able to do it, but with enough effort and communication and, and training and documentation and, now, like going through all of the process of making a business case for this methodology. I got people to accept it. And even at the end of the day, what happened is people were starting to commission us for building scripts. So we sort of had a framework to deliver scripts. And yeah, I guess that was a success story and probably one that motivated me into pushing, now, keeping pushing in this way. So yeah, the way it started again is it was not at all on the table. It just felt like a good idea to do it this way. And then it took some work to get people on board. And in order to get people on board, I had to like to structure it. When you just came up with a dynamo file and then you ran it and it worked, it was not enough. It needed to be more than that. And you need to be like a whole way of how it gets delivered and how it get used by people and where’s the documentation and how do we version it? How do we adapt? How do we make a request for an adaptation and yeah, many, many conversations that were not planned at the beginning, sort of like became a very crucial part to the whole process in that project. was a success story. I guess another one is one that I witnessed that I was not a part of, at least not directly. It was like two orchestras where there was a very large international engineering firm that started using that and it was the initiative of two small teams at first who started it without even knowing that they were doing it at the same time. So it was a branch of this firm in Australia and then a branch of the same firm in the US. And at some point they sort of connected through Orchestra and started growing the user base for their tools together on the platform. I sort of recognized all of the same steps where it went through first having tools that had value. That’s like, you know, the beginning of everything. You have to have tools that have value, but then it’s the communication and it’s the documentation and it’s the, the tracking and the troubleshooting and the, the, the automated feedback that made it work. I don’t have visuals. I mean, I guess they could do a presentation about this at Autodesk University. I guess I could share that with you guys because they made it public. you may. Yeah, you may use that maybe. I think if you can share the link, we can include that in the notes and then any listeners can go investigate too. I think I may have even seen the presentation in the past.

Question 8

Angelica: Thanks for sharing. It’s impressive to see how automation can transform workflows. But we are actually kind of curious about the boundaries, other aspects of the design process that should remain human centric. As an industry, where should we not apply automation tools?

Mostafa: It’s a good question and one that I would, I mean, the answer is, think automation has its place pretty much everywhere in every process. But yeah, for sure. It starts with someone having the right idea, right? I guess you can’t expect automation to come up with the solution. You sort of have to come up with the solution yourself. That’s the human part of it. I mean, I say this, many, many other people say this, like it’s not for me, but first steps to any programming is like with a pen and paper. Well, we have to, where you have to, you know, sort of come up with the idea and what, what, what are like, what is the problem that you’re going to resolve and how you’re going to resolve it. And then the automation appears. But yeah, I think automation can apply to pretty much anything really. But it starts from a human for sure. At least for now.

Question 9

Scott: So, that leads us into our last question. And this is about the future of design automation and future tools. So how do you see existing tools compare with emerging technology, specifically thinking about large language models or neural networks, but not limited to that too?

Mostafa:  It’s definitely been a shift and the way things have been working. Like I don’t think anyone expected this five years ago. It then picked up so fast and it’s really fascinating. And it’s a topic that I think about often and discuss often with colleagues and people who are interested in all of this. so my view of it is right now it’s another tool in the box and a very powerful one. So, you illustrated, I would say that I’m still doing exactly the same stuff. You know, like I’m building a program or something like that. I’m still doing the same stuff. It’s just that I’m super powered by some helpers, helper tools. So if I’m going to like to develop something, you know, people seem to forget how it was before, but like I didn’t know all of the code in my head. I would go to Stack Overflow and Google and search things for hours and then come up with the code that was going to work for me. Now it’s just made like a thousand times faster because you would like to ask the AI or whatever model you want to use. it would not only come up with a solution, but it would also be super specific to what you’re asking. If you give it the name of your variables, it’s going to use that and like there’s less adaptation. So it’s been an incredible productivity gain doing the same tasks. That’s where I am right now. It hasn’t changed what I do. It just changed the way I do it. And I’m still, I think it’s going at some points, it’s going to take more of the work that then it does now. Cause now like you come up with the idea and you sort of have like this idea of you’re going to do it and it helps you code it. It helps you make it. I still think that you’re going to have to prompt it for something someday. So that’s still a human doing that. I don’t know exactly where it’s going to stop. Honestly, it’s a moving boundary. It moves every day. It’s fascinating to watch. And I think it’s important to not be afraid of it, to sort of embrace it and try and gain all of the value that it has to bring. And yeah, adapt. Because if you don’t, yeah, that’s where you might be left behind.

CLOSING PART

Scott:  Yeah, thank you for the perspective. It’s very insightful and I think similar to what a lot of what we’ve been covering and will be covering in this program. And also thank you for sharing all of your expertise today. It’s been a very, very good conversation. Thank you very much. Yeah, thank you. was really insightful. It was a great pleasure to talk to you.

Angelica: I think you’ve given our listeners a clear roadmap for implementing automation in manageable steps, which I think is exactly what many firms need. It was a great pleasure to talk to you, Mostafa. We’re looking forward to seeing your next project. And to our listeners, thank you for tuning in to another episode of MACAD IAAC Podcasts. So until next time.

Scott: Mostafa, our listeners can get more information about you from datasheets.net and orchestrate it online and on LinkedIn. Is there any other location that you’d like to direct them towards? I mean, I share some of my work in progress stuff on Twitter. That’s a place where I like to throw in little gist little videos. So if they’re interested in that, they can find me there. Perfect. And we’ll include links to all of this in our notes.

Angelica: It was a great pleasure to talk with you, Mostafa. We look forward to seeing your next project! And to our listeners, thank you for tuning in to another episode of MACAD IAAC Podcast. So, until next time! 

Mostafa: All right, thank you so much! Bye! Cheers!

Afterward

After the interview, Mostafa asked us to include a link to the Autodesk University Class: A Guide to Successful Automation in Revit

Links to Mostafa’s Work and Profile

• https://orkestra.online
• https://data-shapes.io/
• https://www.linkedin.com/in/data-shapes
• https://x.com/data_shapes