Computational design is useful when it helps a team make better decisions faster. It is less useful when it becomes a software flex that nobody outside the digital team can understand.
That is why this Perkins&Will conversation is worth revisiting. Nirmala Srinivasa and Mario Romero explain how parametric thinking helped a project team test options, protect the design idea and give contractors more confidence in how the work could be made.
Watch: computational design without losing design intent
Nirmala Srinivasa and Mario Romero talk through how Perkins&Will uses computational workflows to explore options, support fabrication and keep the design idea intact.
Listen: the full Perkins&Will computational design conversation
The audio version gives more context on Rhino, Grasshopper, Revit, fabrication conversations and how the team kept technology in service of the design.
What computational design actually helped with
The project challenge was not abstract. The team had a strong design idea involving sculptural timber fins, but every change to spacing, profile and curve created a lot of modelling pressure.
- Rhino and Grasshopper helped the team test variations quickly.
- Revit still mattered because the design had to connect back into delivery.
- The model helped explain the geometry to people beyond the design team.
- Fabrication thinking came into the conversation earlier.
- The technology supported the concept instead of replacing it.
The career lesson for digital designers
If you want to stand out in computational design, do not only list software. Show how your workflow changed the quality of a decision. Practices want people who can bridge design, data, documentation and delivery.
How to show this in a CV or portfolio
- Show the design problem before the script or workflow.
- Explain what the parameters controlled.
- Include one example of a design option or decision that changed because of the workflow.
- Name the software, but also explain the coordination outcome.
- Show how the work helped a client, contractor, project architect or wider team.
Common mistakes
- Making the portfolio feel like a tool demo rather than an architecture project.
- Showing complex diagrams without explaining the design decision.
- Separating computational work from Revit, documentation or fabrication reality.
- Assuming practices understand your role without a clear caption.
- Talking about AI as a replacement for judgement rather than a way to remove admin or speed up iteration.
Architecture Social view
Stephen’s recruiter view is that digital candidates become more credible when they can translate between people. The strongest technical specialists can speak to designers, project leaders, BIM teams, contractors and clients without losing the point of the design.
Use this as a digital portfolio check
Before sending a computational design portfolio, check whether the reader can understand the value without needing a live walkthrough.
- Can they see the project problem?
- Can they see what the workflow controlled?
- Can they see the decision or saving it created?
- Can they see how your role connected to the wider team?
Next step
Listen to the episode, then review your own CV or portfolio for the same balance: design idea first, workflow second, project value clearly explained.
Add a comment