COLLABORATIVE WORKFLOW | HYPER A | STRUCTURE

This project was developed as part of the Collaborative Workflows course, which ran in parallel to our main Studio project. In the Studio, we worked in teams to design a Hyper Building—a complex, multi-neighborhood architectural system. As the Structural Team, our responsibility was to design and coordinate the structural system supporting the building.

The Collaborative Workflows course focused on digital collaboration tools and processes, such as Speckle and Rhino Compute. These tools allowed us to develop automated, cloud-based design workflows, which we applied directly to our studio project to improve efficiency across and within teams.

Design inputs & outputs

Our main design inputs came from two other teams:

• The Service Team, which provided the overall building massing and the neighborhood distributions;
• The Façade Team, which delivered the envelope and final shape of the building.

Our structural role centered on sustaining and connecting neighborhoods through topologically optimized cores. Each neighborhood was given a structural node, which allowed us to distribute forces efficiently across the system. Surrounding these nodes, we developed a structural exoskeleton, which supports the slabs and complements the internal core system.

Once defined, these structural elements were exported and used by other teams as shared geometry within their own design workflows. For the purposes of the Collaborative Workflow course, we mainly focused on the outputs of the slabs and exoskeleton.

Internal collaboration

As a team of two our internal data exchange was mainly through slack, as we can see in the file logs shown at the bottom. This showed to be the most straightforward path given the flexibility we needed to share tasks and scripts on the go.

The inputs and outputs moved from informal exchanges through drive to orderly, official updates in speckle.

External collaboration

To visualize our role, we developed a flowchart representing our external dependencies and contributions.

We were engaged in two main workflows:

1. Collaborative massing development with the Service Team;
2. Structural adjustments and coordination with the Façade Team as the design matured.

Our contribution was both downstream and upstream—we consumed data from other teams but also created structured outputs that became inputs for others. This circular exchange required careful tracking of versions and exports, which we managed through Speckle branches and naming conventions.

Reflections on collaboration

Throughout the process, several lessons emerged:

1. Speckle proved excellent for importing and exporting geometry between teams, especially when we needed specific objects without transferring entire files. However, it was less practical during active script development, where we often needed to iterate on the same Grasshopper file simultaneously.
2. The data team’s framework for defining collaboration methods (branch naming, update protocols, export tags) was crucial. Once this structure was in place, it offered a solid base for inter-team coordination.
3. A major pain point was the manual update process. Our structural scripts relied heavily on geometry from other teams, and each update required:
   1. Downloading new geometry,
   2. Running the Grasshopper definition,
   3. Exporting the results,
   4. Re-uploading them to our Speckle stream.

The need for automation

This led us to explore automation. Our structural outputs (slabs and exoskeleton) are generated from upstream geometry that changes frequently. Each time a source model was updated, we needed to manually respond.

To solve this, we developed an automated pipeline that triggers when the input model changes and outputs the new structural geometry automatically.

The automation relies on three tools:

• Speckle: Our data exchange platform. It stores both input and output models as streams, which can be tracked and versioned.
• Rhino.Compute: A cloud-based service that runs Grasshopper scripts on demand, without the need for opening Rhino manually.
• Fly: A middleware platform that orchestrates the workflow. Fly listens to updates in a Speckle model, sends the relevant data to Rhino.Compute, triggers the computation of the Grasshopper definition, and posts the resulting geometry back to a new Speckle stream.

This fully closes the loop: input changes → automatic compute → output delivery.

By introducing this automation, we removed friction from our process, freed up time for design iterations, and ensured that our structural model was always in sync with the latest architectural context.

Demo of automated workflow

Final thoughts

This project gave us a deep understanding of what real collaborative workflows can look like when powered by computational tools. The integration of automation platforms like Fly and cloud-based computation through Rhino.Compute represents a shift away from manual, file-based processes to live, event-driven design systems.

As architectural practice becomes more collaborative and parametric, we believe these kinds of workflows will be essential—not just for structure, but across all design disciplines.