The problem
Feasibility studies at an architecture practice have a nasty bottleneck. Before a project can be costed, pitched, or scoped, someone needs to run yield — gross floor area, floor-area ratio, site coverage, shadow envelopes. The inputs change constantly: the client wants more floors, the planner flags a setback, the brief shifts overnight.
At Hayball, that work required a Grasshopper specialist. Days of modelling. Days of revisions. Junior designers couldn't run their own scenarios. Early-stage client conversations were blunt because the numbers weren't ready yet.
What I built
A parametric massing tool in Grasshopper, wrapped in a Human UI front-end so that anyone on the team — architect, graduate, client services — could run their own studies without opening a single Grasshopper canvas.
The UI exposed the knobs that actually matter: site boundary, setbacks, max height, number of floors, podium depth. Everything else was automated.
Under the hood:
- Automated GFA and FAR calculations — updated in real time as parameters changed. No formula re-entry, no spreadsheet cross-reference.
- Shadow study visualisation — real-time shadow envelope for any time of year and building orientation, rendered directly on the massing model.
- Yield comparison — multiple massing scenarios side by side in a single session.
- Export — one-click output to diagrams and PDF reports formatted for client presentations.
The canvas was locked. You couldn't break it. Parameters had hard limits. The tool did one thing and did it correctly every time.
What changed
Feasibility study time dropped from days to hours.
The subtler change: the team stopped waiting. A project architect could run three massing options before lunch, share them with the client by afternoon, and arrive at the next meeting with data instead of sketches. Conversations that used to start with "we'll come back to you on the numbers" started with the numbers.
Non-Grasshopper users — and that's most of the practice — ran their own studies. The specialist was freed from answering the same feasibility questions on repeat and shifted toward harder computational problems.
What I learned
Parametric tools fail adoption when the learning curve is steeper than the payoff. Human UI was the right call — it made the power invisible. Nobody needed to know what was happening behind the panel. They just needed the output.
The hard part wasn't the Grasshopper logic. It was deciding what not to expose. Every additional parameter is a decision the user has to make. Fewer knobs, better tool.
Stack: Grasshopper · Human UI · Rhino · Python. Engagement type: internal tooling lead. Used in production across multiple projects in the AUD 591M+ project pipeline.