Collaborative Workflows and Techniques for Façade Design .

We explored both internal and external collaboration strategies with all design teams at HYPER A. Our team focused on three key areas: adaptive façades, energy efficiency, and smart architectural systems. To guide our design process, we established clear performance metrics, including Daylight Factor, Panelization strategies, and Energy Production Optimization.

Meet the Team:

Christina Christoforou – The Panelizer, responsible for creating innovative kinetic elements that could adapt to the building’s changing environmental conditions.

Andrea Ardizzi – The Typologist, responsible for establishing the facade’s logical structure and overall geometry.

Giulia Tortorella – The role of Climate Wizard, managing performance metrics like energy efficiency and daylight optimization.

Input & Output

Building geometry was received from the service team via Speckle. The geometry was then panelized, relevant façade typologies were applied, and performance analyses were conducted to ensure alignment with the established performance metrics.

Early Internal Collaboration workflow diagrams

The following section presents internal workflow diagrams outlining each team member’s tasks. Throughout the process, both the workflow and individual responsibilities evolved, requiring continuous adaptation of strategies. To support this adaptability, a flexible, rule-based system was developed capable of responding to any input resulting in a highly dynamic and responsive workflow. Despite this flexibility, clearly defined roles were established from the outset to maintain clarity and coordination across the team.

21 January 2025

04 February 2025

10 February 2025

17 February 2025

Internal Collaboration workflow

As the project progressed, the workflow was refined to enhance both efficiency and adaptability. The process began by integrating geometry and data from other teams, followed by the application of façade design logic aligned with established performance goals. To streamline computational tasks, responsibilities were strategically divided within the team, minimizing redundancy and improving overall efficiency. Speckle played a key role in enabling seamless internal data exchange throughout the process.

External Collaboration workflow

The façade design was shaped by strict geometric constraints. Initially, the building envelope was adapted based on the massing and program provided by the Services and Industrial teams. This was later refined through slight massing adjustments, leading to a fully coordinated design. Close collaboration with the Industrial and Structural teams was essential, as their input helped balance performance goals with the building’s geometric limitations.

Workflow Organization

As the Grasshopper definition grew in complexity, managing it became increasingly challenging. To maintain clarity and control, the building was divided into distinct “neighborhoods,” with tasks distributed across separate workflows to simplify development and coordination. Speckle played a crucial role in this process, enabling efficient data exchange and ensuring consistent collaboration among team members.

App: Automation Concept .

Key tasks were automated using Speckle, Grasshopper, Compute Bot, and Webhooks. Since panelization and planarization were the most time-consuming parts of the script, efforts were focused on automating this initial process. This significantly improved efficiency and enabled seamless sharing of the generated planar hexagon surfaces and edges with the Structural team.

Input/Output of the application

To break down the process: the building mass was first received from the Services team via Speckle, then scaled and filleted to ensure smooth integration with the hexagonal panels. Due to incompatibility between the Dentro plug-in and Rhino Compute, the application was created after the filleting step. The mass was then divided into eight neighborhood sections and converted into a Speckle object, which was sent back into the system. A synchronous receiver picked up the data, initiating the hexagonal panelization using the Zombie solver. The resulting mesh was planarized and returned via a synchronous sender. Finally, the panelized mass was received in Speckle, ready for further use by other teams.

By leveraging Speckle, Grasshopper, Python with Fly.io, and compute servers, several parts of the process were successfully optimized. Looking ahead, there is strong potential to further enhance this system—ultimately enabling greater automation of the workflow and significantly improving speed and overall efficiency.

Final Take Out

01 Internal Collaboration

GH definition complexity: Soon the GH definition became heavy and complicated, with some bottleneck and the necessity to receive different data from other Teams in order to inform the model


Definition steps: the definition was splitted in 4 separated steps, making Speckle the data exchange Hub

Good: GH definition was clearly identified, no need of explanation and easy to run


Bad: Splitted data and geometry by Neighborhood allowed a fast computation, but required manually data exchange with Speckle. Final complete model was too heavy to be uploaded to Speckle

02 Exchange Data and Geometry

UnFormatted Received data: Geometry from HyperA teams is not directly usable for panelization / trimmed surface needs to be reconstructed and Meshed


ReFormatting of data: The neighborhoods “blocks” have to be elaborated separately,functions Voxels are sorted and separated in order to be available for the next steps

Good: Format the received Data give us the opportunity to better control the input/output

Bad: Geometry exchange (receive and send data from Speckle) was time consuming, and some data was faster exchanged by internalized file shared via GDrive

03 External Collaboration

Geometry application: Facade is very dependant from overall geometry of the building, that evolved and changed till the last weeks. Have to deal with different geometry logic from Massing (Voronoi) to Functions (Voxels)

Adaptable solution: An adaptable and scalable solution was found to be able to adapt to every 3d configuration of the building

Good: Collaboration with external Teams was easy as we set a reference model to Receive from, that was always updated with relevant and constant information

Bad: Being able to suggest to other Teams what kind of information was needed, focusing more on adapting strategy then requesting particular geometry and data