Building and scaling the first design system at Officeworks

How I established a 0-to-1 design system mid-delivery, giving three squads a single source of truth and lifting WCAG AA compliance across all core journeys.

Design Systems 0-to-1 Figma WCAG AA Atomic Design Design Tokens Governance
RoleUX Lead
Duration18 Months
Team3 designers, 3 engineering teams, product owner
SkillsDesign Systems, Figma, Storybook, Confluence
Officeworks design system component library showing tokens, components, and documentation in Figma
Impact at a glance

What this system delivered

92.7%1
Prototype-to-build alignment accuracy
30%2
Reduction in design-to-development handoff time
513
Reusable components adopted across squads
Context

The situation

As UX Lead on the B2B digital replatforming programme at Officeworks, I identified a critical gap: there was no design system in place. Without a shared foundation, every team was making independent decisions, leading to a fragmented product experience, accessibility gaps, and significant rework between design and engineering. At the scale of the replatforming programme, this was a critical risk that needed to be addressed, not deferred.

The gap

No design system existed. Design and implementation needed to move together with project delivery, or the programme would ship inconsistency at scale.

My Role

What I was responsible for

I decided to establish a scalable design system grounded in accessibility, atomic design principles, and close collaboration with engineering, while continuing to deliver against the replatforming programme in parallel.

  • Led a team of three designers in creating the Figma design library while delivering project work simultaneously
  • Partnered with product, engineering, and design teams to define design tokens, reusable components, and interaction patterns aligned to accessibility standards
  • Facilitated cross-functional collaboration and embedded the system into Figma and development workflows
  • Produced clear documentation and governance to support adoption and consistent usage across teams
  • Advocated for systems thinking, influencing stakeholders on the value of scalability, accessibility, and efficiency
My process
Set Foundation
Set the Scope
Plan and Prioritise
Build Components
Sync Design and Dev
Governance
Approach

How I built it

1. Set foundation

I led the team to establish a robust design token framework covering colours, typography, and spacing, with accessibility guidelines baked into each component from the start. This created scalable rules for consistency and gave teams a shared language across design and code.

2. Set the scope

With no existing system to build from, I aligned expectations with product owners to identify where consistency was most critical. I mapped out which component categories were needed, defined the boundaries of the system, and set realistic expectations with stakeholders on delivery.

3. Plan and prioritise

I partnered with Product Owners and the Tech Lead to prioritise component gaps based on delivery needs, frequency of use, and accessibility risk. This ensured the system was useful from day one while building toward a complete, scalable library over time.

4. Build Figma components

Working in real time alongside the replatforming project, I led the team in designing, refining, and documenting 51 UI components and interaction patterns, ensuring quality, WCAG AA accessibility compliance, and cross-platform readiness. I streamlined Figma workflows using libraries, plugins, and automation to improve versioning and reduce friction.

Figma component library using change log plugin with components marked as dev ready
Using change log plugin and ensuring components are dev ready with Figma

5. Sync design and dev

I partnered the design team closely with engineers and QA to ensure seamless implementation in Storybook and front-end builds, running weekly design-and-developer sessions and showcases to align teams and accelerate delivery.

Workflow diagram showing how designer, developer, and QA roles sync during design and dev delivery
Showing workflows between roles to sync design and dev delivery

6. Governance

Together with other designers, I produced clear documentation and established governance structures to support adoption and consistent usage across squads, including agreed contribution workflows, review criteria, and ongoing refinements to reduce friction as the system scaled.

Design system diagram alongside backlog tickets for planned component improvements
Showing design system diagram and backlog tickets for component improvements
Results

Detailed outcomes

Consistency

  • 92.7% reduction in inconsistent UI patterns across B2B platforms4
  • Single source of truth established for designers and engineers across squads
  • Accessibility compliance lifted to WCAG AA across core customer journeys

Design-to-development efficiency

  • 30% reduction in handoff time through tokenisation, documentation, and optimised Figma workflows2
  • 25% drop in clarification requests from developers, streamlining collaboration5

Scale

  • 51 reusable components now adopted across multiple squads3
  • Governance structures and workflows established to ensure long-term scalability and adoption
  • Embedded a design system mindset, nurturing a culture of continuous improvement and best practice
Figma comments from colleagues working on the B2B UI Kit showing collaborative feedback on components
Showing comments from colleagues working on the B2B UI Kit
Method

How the numbers were measured

  1. 1Measured by comparing delivered front-end builds against approved Figma prototypes across 12 sprint cycles. Design QA scored alignment on a component-by-component basis.
  2. 2Calculated from average design-to-development handoff duration before and after design system adoption, tracked across 6 months of sprint retrospectives and team velocity data.
  3. 3Actual count of documented, reviewed, and production-adopted components in the Figma library and Storybook, verified at project completion by design and engineering leads.
  4. 4Measured by a pre- and post-implementation UI pattern audit across 8 core B2B customer journeys. Inconsistencies were catalogued by category and severity.
  5. 5Tracked via Jira clarification tickets and developer Slack channel requests, comparing average requests per sprint before and after the design system launch.
Learnings

What I would carry forward

Key learning

Building a design system in parallel with live delivery is genuinely hard. The discipline was in making it real enough to be useful immediately, while scalable enough to serve the organisation long term. Getting stakeholder buy-in early, through evidence and education, was what made adoption possible.

  • Governance is not bureaucracy: it is what separates a library from a design system. Without it, the system fragments the moment the original team moves on
  • Shipping components in parallel with a live programme requires ruthless prioritisation. The right question is always: what does delivery need next week, and does it exist yet?
Next case study
Influencing a shift to guided UX in the BYOD project