Building a design system at scale for APRA AMCOS

A multi-platform, multi-product design system built in Figma spanning internal tools and customer-facing products across seven or more distinct surfaces.

The Challenge

When I joined APRA AMCOS there was no shared design language. Each product team was working independently making their own component decisions, applying inconsistent visual treatments, and shipping interfaces that felt like they came from different organisations entirely. There was no shared component library, no agreed-upon patterns, and no systematic thinking applied to the relationship between their internal tools and customer-facing surfaces.

For an organisation managing rights across the music industry, the stakes were high. Their product ecosystem touched a wide range of audiences from rights holders and music publishers navigating complex licensing workflows, to internal staff processing distribution and royalty data. Getting consistency right wasn't cosmetic. It was functional.

My Approach

Starting with a solid foundation
Rather than building from scratch, I made an early strategic call to base the system on MUI (Material UI). This gave us a well-documented, battle-tested component architecture with broad developer familiarity. The decision wasn't about taking shortcuts it was about directing effort where it would matter most: adapting, extending, and making the system genuinely fit-for-purpose rather than reinventing primitives.

In Figma, I built a token-driven component library that mapped directly onto the MUI structure. Design tokens governed colour, typography, spacing, and elevation ensuring that changes at the foundation level propagated through the system consistently, whether a component appeared in an internal admin tool or a public-facing portal.

Designing for complexity
One of the defining challenges was that the design system had to serve fundamentally different contexts simultaneously. Internal tools prioritised information density, workflow efficiency, and task speed. External products needed to feel approachable, trustworthy, and brand-coherent. Designing components that could flex across both required real intentionality at every level from interaction patterns to the semantics of colour use.Key improvements

The design system wasn't a single library it was an architecture. A core foundation layer sat beneath product-specific extensions, allowing teams to inherit shared rules while adapting to their context without fragmenting the system.

I structured the Figma library so that product teams could work within their own space while remaining connected to the shared foundation. Component variants were built to accommodate both internal and external contexts, with modes and properties that gave teams meaningful flexibility without opening the door to inconsistency.

Rolling it out across teams
Designing a system is one challenge. Getting multiple product teams to adopt it is another. I worked directly with designers and developers across those teams to understand their existing workflows and identify where the system added the most immediate value. Early wins built credibility. Clear documentation reduced friction. And being present not just handing over a library made the difference between nominal adoption and genuine integration.

Developer buy-in was a particular focus. I made sure the Figma components were structured to mirror MUI's props model, so the handoff felt familiar and the gap between design and code was narrow. This wasn't just a design-team tool it was a shared vocabulary for all product teams..

Outcomes

Consistency
Unified visual language across 7+ products for the first time

Accessibility
WCAG-compliant foundations baked into the component layer