Podium Design System
Podium · Design System Owner · 2022–2025 · Two major versions
This case study highlights my three-year experience in maintaining a design system through two major versions, a company rebrand, and a full organisational spin-out.
When I took on the Podium design system, designers were working around it more than with it. Duplicated components, conflicting patterns, and a growing gap between what was in Figma and what was in production.
There was never a dedicated design system team. I owned the library end to end, audit, component design, tokens, documentation, and governance working with a front-end engineer on implementation.
~80% parity
Figma to Production
240 > 90
~200K
insertions with 364 detached in a year window
10 designers
4 products
served across consumer-facing and internal tools
In short
Challenge
The design team was designing around the Podium design system rather than with it. Issues such as component duplication, conflicting design patterns, and an increasing distance between what we had in design mockups and what was going out in production.
What I did
I owned the design system for three years through two major versions, a company rebrand, and a full organisational spin-out. Rebuild the design system into one unified system with design tokens, reusable components, and tooling for a 3D modelling B2B platform.
Outcome
Reached ~80% Figma-to-production parity, and at its peak, 10 designers working from one unified system across 4 consumer-facing and internal products.
The v2.0 rebuild consolidated 240 components down to 90, 5 different component libraries to 3 library. By mid-2025, Figma analytics showed over 200K insertions, with 364 detached rate across the team in a year window, with the top ten components accounting for roughly 70% of all usage.
Podium Platform UIs: the 3D design environment used by architects and engineers on the left,
and the supplier-facing portal on the right
The challenge
Silos, duplicates, and a system that everyone finds challenging
After running a workshop and digging into Figma's component library analytics, the picture became clear.
Core issues
Inconsistent UI across platforms and between products
A significant gap between what was in Figma and what was in production
Components were hard to find and harder to understand. Designers spent more time deciphering the library than designing
Handoff was painful, with engineering regularly having to resolve ambiguity that the system should have resolved for them
Duplicated and conflicting components made scaling new features slower than it needed to be
Constraints
No dedicated design system resource. Design system work ran alongside feature delivery.
A platform built primarily around 3D design tooling. The system had to serve both highly visual 3D scenes and conventional product UI like forms, tables, and dashboards.
A growing set of products spanning two consumer-facing and two internal tools, each with their own edge cases.
Pain points from the workshop, grouped by theme and component analysis, end 2022
Impact-effort prioritisation and the work plan to decide what to fix first and what to leave for later.
The solution
The north star
"How do we design our design system for our designers to enable productivity & creativity while providing a simplified, flexible, easy-to-consume and maintainable library?"
I set that question out at the start and used it as guiding principle whether we were debating a component structure or pushing back on a scope increase. I split the goals into two horizons so we had something achievable near-term without losing sight of where we needed to get to.
Short-term (6 to 8 months): stakeholder buy-in, improved searchability, simplified components, documentation, and standardised usage across product surfaces.
Long-term: design tokens, a federated model, a published design system site, and versioned releases.
Design System v1.1
Getting the basics right
After six months of planning, design reviews, iteration, and implementation work with engineering, we shipped v1.1. Every week, I designed a component, reviewed it with the team, tested it, iterated, published. Every two weeks, I host a joint session with engineering to prioritise implementation and manage migration.
By 2023, Podium was running two consumer-facing products and two internal tools. With this extension of product range, I introduced visualisation components, advanced table layouts, and form displays that hadn't previously existed.
Design System v1.1 in use across two product surfaces; the 3D construction environment and the property analytics dashboard, both running off the same system.
The extended components introduced in v1.1 to serve Podium's internal tools, data-dense layouts, financial tables, and reporting dashboards that didn't exist in the original library.
Design System v2.0
A clean break with the past
At the end of 2023, Podium separated from Lendlease and became an independent start-up. Teams restructured and product lines were redefined. I used the opportunity to do what v1.1 couldn't: start fresh.
v2.0 was a full rebuild. New branding, new design language, new foundation library from scratch. Every component and icon was converted to align with the new visual identity. Design tokens were introduced properly for the first time.
Design System v2.0 foundation, type scale, icon set, and the full colour system documented
for the first time as proper design tokens.
Design System v2.0 applied to Podium's core product with new branding, new UI patterns.
Design System v2.0 components serving the supplier portal. Product detail forms and bulk data import, both built on the new foundation library.
Product Catalogue and Product listings view for Supplier Portal
Communication
Making the system feel shared
As part of the design system governance and maintenance, I set up three channels to create visibility without adding overhead.
A dedicated Slack channel for updates, feedback, and quick questions.
A bi-monthly newsletter highlighting changes, new releases, and best practices.
And a bug report workflow so designers had a clear path to flag issues rather than quietly working around them.
The dedicated Slack channel and bi-monthly design system newsletter.
Outcomes
What the data said
We didn’t set out with a formal metrics framework, which is something I’d approach differently now. But Figma’s component analytics and designers feedback gave us reliable insights. Consistent findings highlights faster onboarding for new designers and engineers, fewer UI inconsistencies across products, better searchability, and a noticeably smoother handoff process.
The v2.0 rebuild consolidated 240 components down to 90, 5 different component libraries to 3 library. By mid-2025, Figma analytics showed over 200K insertions, with 364 detached components across the team in a year window, with the top ten components accounting for roughly 70% of all usage.
Figma component analytics from 2025 alongside feedback from the design team.
Reflections
What I’d do differently
These past years, I have learnt that a design system is never done. There’s always a backlog for better documentation, a more complete colour system, tighter design-dev governance. That list just goes on and on.
The thing I came to understand is that the design system is the product itself. It needs investment, roadmapping, and users who feel ownership over it. Without those things, it decays no matter how well it’s built.
Future
As of early 2026, our team has decided to move away from our own design system and adopted the shadcn component library. The decision came as the whole team was moving toward AI-assisted development. LLMs have no training context on a private component library. shadcn is one of the most widely-used, open-source UI libraries, which means AI tools understand it natively.
We also assessed that the completeness of the library such as being community-maintained, Radix-based for accessibility, and well-documented library would be far better off in user experience and development than keep on maintaining on our own design system. Currently, we are in the midst of migrating and this would be another case study for the future.