01Challenge

With the design team reduced from five to two, following introduced Hub-and-Spoke operating model, I set standards for decentralised UI delivery enabling engineering teams to ship faster without fragmenting the product experience. As a result, 4 teams onboarded, 20% progress in design library development and improved consistency in AI prototyping.

02Problem & Context

As the company restructured toward a new operating model, two things happened simultaneously: the design team scaled down from five designers to two, and access to UI tooling expanded across engineering teams. The result was a dangerous imbalance - velocity increased, but coherence didn't.

The core issues were:

• Consistency of design outcomes was degrading as output volume grew
• Ownership of quality had become unclear as more people produced UI without design accountability
• Teams were shipping faster, but without a shared standard to anchor decisions

This wasn't simply a resourcing problem. The existing model no longer fit the organisation's structure or ambitions. The real challenge was redefining what design was for.

03Role, Team & Constraints

My role

Sole driver of this initiative, owning strategy, stakeholder alignment, and implementation.

Stakeholders

Product leadership, engineering leads, and senior management.

Constraints

• Two-person design team with no capacity to scale headcount
• Engineering teams already moving fast with existing tooling
• Pressure on maintaining production speed

04Research & Insights

I began with a structured discovery phase to understand Hub-and-Spoke methodology and assess how it could be adapted to Lantern's specific team structure and resources.

Three findings emerged that fundamentally shaped the approach:

The model couldn't function without completing the design system's development.

The design system was already designed, documented, and trustworthy but discovery revealed that only 10% of it had been developed in a scalable way. The standards existed on paper; the infrastructure to enforce them didn't. This made completing the design system implementation the first and non-negotiable goal before the Hub-and-Spoke model could operate at all.

Design's quality role had to operate above the delivery layer.

Collaboration with QA revealed that involving design at ticket level wasn't viable given the volume of features being produced. Design would need to govern at the epic level instead setting standards upstream, and auditing outcomes at a system level rather than intervening in every release cycle.

Design's value shifted from producing interfaces to shaping what gets built.

With AI tooling capable of handling rapid UI generation, design's highest-leverage contribution moved earlier in the process into requirements definition and rapid prototyping with AI. Rather than being the bottleneck at the end of the delivery cycle, design could set the direction at the start of it.

05Key Decisions & Tradeoffs

Decision 1: Adopt Hub-and-Spoke methodology

The alternative was to push for headcount restoration. Instead, I proposed a structural shift - one that would make quality scalable regardless of team size.

• Why this: Headcount wasn't going to return in the short term. A governance model could outlast any individual hire.
• Tradeoff: This required engineering teams to take on quality accountability they hadn't previously owned, which needed buy-in rather than mandate.

Decision 2: Integrate the LUX design system with AI tooling (Figma Make + Claude)

With higher volumes of generated UI now coming from both design and product teams, the risk of inconsistency was significant. Rather than rely on manual review alone, we embedded LUX design system components directly into AI tooling to constrain output quality at the point of generation ensuring that whatever teams produced through AI remained anchored to established standards.

• Why this: Manual design review couldn't scale to match the velocity of AI-assisted output. Embedding the system into the tooling moved quality control upstream, making it easier to control.
• Tradeoff: To make a real impact, the design system needed to be fully rolled out first, which meant front-loading component documentation work before the integration could deliver value.

Decision 3: Complete the development of the UI component library

While the design system was well-documented and trustworthy on the design side, only 10% had been developed in a scalable way. Without a complete, development-ready component library, engineering Spokes had no reliable foundation to build from, and the Hub had no enforceable standard to audit against. Completing LUX development became a prerequisite for everything else.

• Why this: A governance model is only as strong as the system it governs. Partial implementation meant partial consistency, which under a decentralised model would compound quickly across teams.
• Tradeoff: This required significant upfront investment from both design and engineering before the new operating model could fully activate, slowing initial momentum in exchange for long-term stability.

06Solution

Hub-and-Spoke Design Operating Model

Design became the central Hub - a quality governance function responsible for standards, reusable tooling, training, and audits. Engineering teams became Spokes - applying those standards in day-to-day delivery, owning release-level QA, and feeding back into the system continuously.

This created a clear separation of accountability:

• Design QA focused on visual consistency and content quality
• Engineering QA focused on end-to-end task completion and accessibility
• Design retained sign-off rights, conducted spot-audits, ensured severity alignment, and identified systemic issues before they compounded

LUX Component Development Process

To make the Hub function reliably, the design system needed to be a stable, well-documented foundation, not a living shortcut. I introduced a mandatory contribution process for all core components:

1. Distinguish LUX Components (standalone, core system) from LUX Widgets (styled to match, but outside the core)
2. Flag intent in the shared channel before starting work
3. Run a Four Amigos call - two developers and one designer aligned before building
4. Build to spec from Figma and Zeroheight documentation, not from existing implementation
5. Design and dev both review PRs before merge

This process applied without exception, regardless of contributor experience to ensure the Hub remained trustworthy as the system scaled.

07Results & Impact

Adoption

The model was implemented across four engineering teams and the product team, with a new squad created to own UI library development - a structural commitment that didn't exist before this initiative.

Quality

Consistency of AI-generated designs produced by the product team improved measurably, reducing the volume of outputs requiring design intervention and validating the decision to embed LUX components directly into AI tooling.

Figma design

Figma Make Prototype leveraging UI library

Design system

Delivery progressed from 10% to 30% in four weeks, which is a significant acceleration given the squad was simultaneously contributing to feature work. This pace validated the contribution process and demonstrated that a governed, structured approach to component development could scale without sacrificing delivery commitments.

08Reflection & Next Steps

What I'd do differently

LUX Guild was working on features and design system work. Retrospectively, I would have pushed to for it to be solely dedicated to design system work. Splitting time slowed progress at the stage where momentum mattered most.

What remains unsolved

• How governance models like this scale as teams grow and what needs to change in the audit process before distribution becomes a liability
• Where the Spoke model needs to evolve to stay effective as team structures shift over time
• How to better embed quality ownership into delivery culture, so standards hold under pressure without relying on design intervention

Where this goes next

• Expanding AI tooling integration as the design system matures and more components become available for embedding
• Formalising a training layer for new Spoke contributors so quality standards transfer without requiring direct design involvement every time
• Establishing a regular system health review cadence to catch systemic issues before they compound across teams