Design Ops

speeding up design delivery: a scalable white-label framework for Playtech Sports

Role

UX & UI Lead

Timeline

2024-2025

Tools

Figma

Deliverables

Figma Asset Architecture, Implementation Workflows, Client Branding Guidelines

Overview

Playtech Sports operates a complex B2B ecosystem where every product deployment must be white-labelled and branded to a specific operator's identity on an aggressive timeline. As the business scaled and concurrent operator launches grew, the traditional design workflow started to become an operational bottleneck.

The problem

Production bottleneck: branding turnarounds could take upwards of four weeks per operator due to a legacy workflow relying on Sketch and fragile, outdated third-party plugins.

Process obsolescence: the old process was designed for a period when Playtech managed fewer operators and prioritised bespoke layouts over delivery speed.

Scope creep: operators historically enjoyed freedom to demand bespoke UI changes, resulting in a heavy maintenance burden for design and development teams.

Self-service future: the business needed to reduce design overhead, enable developers to implement client branding independently, and lay the groundwork for a future self-service client CMS portal.

multiple B2C brands, one platform

multiple B2C brands, one platform

The solution

While migration to Figma was already underway to unify product design patterns, standardising basic assets wasn't enough. We needed an architectural solution. I designed a multi-tiered Figma library framework that used native library swapping functionality. To fully realise this workflow, I collaborated with product and account management to define strict, non-negotiable branding boundaries, producing a definitive set of guidelines for operators.

The approach

different brand styling

different brand styling

De-risking the toolchain: we initially tried to replicate our Sketch ecosystem using Figma plugins. however, every option we looked at required ongoing subscriptions and reintroduced the risk of third-party dependency—the exact vulnerability that continued to break our legacy Sketch workflow. As a result, we turned to a native, first-party solution.

Three-tier library architecture: I architected a multi-file system built specifically to exploit Figma’s library swapping feature:

  • Core components: a master file containing the global base components, typography rules, and structural styling exported as a core library.

  • Product screens: a comprehensive file for each product vertical containing every implementation screen and embedded component guidelines.

  • Template branding: A dedicated configuration template setting up the library overrides needed for an operator (logos, colour tokens, font mappings).

White-label workflow: to brand a product, a designer duplicates the template branding file, inserts the client assets, and copies in a subset of required screens from the product screens file. By running library swaps to exchange global pointers for local variables, the entire product suite updates instantly.

Pragmatic constraints: while we explored using Figma Variables for further controls (like corner radii and padding), there was no native swapping logic at the time, which would end up bloating file maintenance. I made the pragmatic decision to defer variable integration to keep the immediate rollout stable.

many figma files, organisation was very important

many Figma files, organisation was very important

The impact

Figma library swapping

Figma library swapping

Velocity: design asset delivery turnaround was cut by over 50%. the optimisation trickled down to development, allowing developers to build and deploy a branded sportsbook up to 25% faster.

Accuracy: establishing boundaries around what colours and fonts could be modified dramatically reduced UI translation defects during handoff.

Alignment: the standardised branding guide aligned Product, Sales, Accounts, QA, and Development. This helped to set clear expectations for operators regarding what could be customised out-of-the-box versus what constituted a bespoke request.

Takeaways

Technical self-reliance: relying on third-party plugins for a core workflow introduces risk. Prioritising native features ensures long-term stability and workflow longevity.

Cross-departmental scope management: workflow optimisation means nothing without organisational guardrails. The success of this framework relied entirely on educating Sales and Product to defend our system constraints.

Pragmatic flexibility: even with defined scope boundaries, operators still required bespoke output at times. Managing sports executives' expectations was key here; I had to clearly communicate that exceptions were acceptable only if the business explicitly embraced the resulting timeline delays and development overhead.