Building A Scalable Design Library for Multi-Platform Consistency

A leading air defence organisation’s digital arm was scaling its internal product ecosystem rapidly—across multiple teams, vendors, and platforms. As delivery velocity increased, design consistency and operational efficiency were at risk.

I was brought in during the early phase of this transformation, where foundational design decisions would significantly shape long-term maintainability, team onboarding, and product coherence.

Strategic Objective

At a systems level, the goal was not merely to produce a UI kit, but to establish a shared design language that could scale across teams, vendors, and future use cases.

The initiative aimed to:

• Create a single source of truth for design decisions

• Enable cross-team consistency without slowing delivery

• Reduce cognitive load for designers and developers

• Ensure the system could scale with operational complexity, not constrain it
  
  

While the original intent was to build a full design system, organisational realities meant the initiative evolved pragmatically into a design library—a deliberate stepping stone rather than a compromise.

Problem Landscape

When I joined the project, several structural challenges were already evident:

• Internal teams were building with MUI, but relied heavily on its default theme, resulting in a generic visual identity.

• External vendors introduced their own design systems (e.g. Carbon, Ant Design), fragmenting the user experience.

• Design decisions were often re-made per project, increasing inconsistency and rework.

• There was no shared governance model to guide how design choices should scale across products.
  
  

Left unchecked, this would have resulted in:

• Increased maintenance cost

• Slower onboarding for new designers and developers

• Inconsistent experiences for servicemen using multiple applications

My Role & Leadership Approach

As one of the two UX designers onboarded at the time, I took ownership of design system direction alongside my product responsibilities.

From a leadership standpoint, my role focused on:

• Setting the strategic direction for a scalable design foundation

• Making deliberate trade-offs between ideal frameworks and organisational readiness

• Aligning designers, developers, and stakeholders around shared principles

• Documenting decisions so the system could outlive individual contributors
  
  

Rather than positioning the design system as a “design deliverable,” I framed it as infrastructure—something teams build on, not around.

Key Constraint: Designing for Adoption, Not Perfection

A critical early decision was determining how ambitious the system should be, given the organisation’s maturity and delivery pressures.

This decision ensured:

• Faster alignment across teams

• Lower risk during active product delivery

• A clearer upgrade path toward a more formalised design system later

System Foundations: Designing for Scale

Rather than starting with components, I established foundational constraints—the rules that prevent fragmentation over time.

From UI Kit to Design Library

Impact

• Adopted by four independent teams

• Reduced design divergence across applications

• Improved development efficiency through reusable patterns

• Established a shared visual and interaction language across internal and external contributors

More importantly, the initiative shifted mindset:
Design consistency became a collective responsibility, not a stylistic preference.

Reflection

This initiative was less about pixels and more about systems leadership:

• Designing constraints that enable autonomy

• Making pragmatic decisions that maximise adoption

• Treating design as organisational infrastructure

In complex, multi-team environments, the success of a design system is not measured by completeness—but by whether teams choose to use it.