Migrating TSB’s Design System

Switching tools is never easy, but here's how we successfully migrated TSB's design system from Sketch to Figma, onboarded the team, and delivered ongoing projects using Figma — all in just four months.

Skills
Design Operations
Strategy
Design System

In house
TSB

Role
Lead UI Designer

Year
2023

The Project

Context

Prior to joining TSB, the design team had already launched the first iteration of the Orbital design system within InVision and Sketch in 2021, but were keen to stay on top of new software that would keep the team efficient and competitively placed. In particular, there was strong interest across the team to adopt an open design culture in order to foster stronger relationships with stakeholders and prepare the team to scale up in future. Our existing tooling, unfortunately, prevented us from doing this in its current form.

Problems to address

Design handover is an important part of delivery, and unfortunately my experience was mired by tooling complexity. Sketch was used exclusively by the designers with handoff happening within InVision Prototypes, and full user flows maintained within InVision Freehand.

To summarise the problems we faced:

Stakeholders felt frustrated by the ‘lag’ between giving feedback and seeing designs updated
Software updates slowed down the design team, leading to delays up to 2 days
Designers spent time maintaining one project across 3 different tools
Designers had to ‘over-communicate’ with stakeholders, in order to maintain the relationship and inform on progress
Bad habits formed out of a need to work faster; file management became unruly, files were saved offline for faster load times, and filenames were non-descriptive or inconsistent across design tools

Alongside the tooling complexity, managing the design system added friction to every designer’s day. Common complaints included:

Components needing to be detached in order to work responsively
Existing documentation was too high-level and impractical for designer or developer use
Documentation was hosted in another tool and designers did not all have access to it
Synching issues between Sketch and InVision, leaving design libraries out of date and causing a cascade effect throughout project build

Fixing all of these issues involves more than switching to a new, fancy tool, but the migration gave us the time and space to examine our existing pain points and devise a better way of working for the whole team.

Measure of success

As with every project, we had to be able to justify the cost to the business and measure its success in quantifiable metrics.

Using Figma, we were able to:

Begin measuring the Orbital design system’s usage overtime against channels and teams
Verify a 100% adoption rate of the design system across TSB
Track over 95% usage of all components in live journeys
Increase designer accuracy through the implementation of design templates, allowing us to generate common screens in the app and web as library components
Reduce the number of defects entering build by at least 25% (this is a conservative measure, as we weren’t previously tracking this metric)
Reduce time spent creating responsive and magnified designs by 1,500%, through the implementation of design tokens and variables within Figma

The Migration

However, migrating to a new tool is no easy feat. My previous experiences were relatively pain-free within smaller teams, but it would be decidedly more complex to rollout for a team managing 20+ major features and collaborating across multiple development squads.

A fresh start with a new tool provided a straightforward solution, as Figma boasted several features that would help us work efficiently, future-proof our design system, and allow us to adopt a more open design culture across TSB.

So this is how we did it. I won’t give away all my trade secrets, but I can say that working group calls and a massive FigJam board to map out our next steps were vital to our success.

Audit and reorganise
Categorising components
Rebuild everything, sometimes from scratch
Onboard and introduce everyone!
Establish a new way of working

1. Audit and reorganise

Our previous design system in Sketch consisted of three libraries: Foundations (shared brand assets and styles), Web, and App. While it appeared straightforward, it was unclear to designers across the business whether components had been implemented fully for all channels or not. This contributed to a high number of defects entering build, whereby components were duplicated in build or implemented in incorrect channels, leading to accessibility issues and increased costs to the project.

To address this complexity, I categorised and split all of our components and styles into eight separate design libraries. These libraries were organised by type and channel usage for clearer ownership.

This method allowed teams to freely disable irrelevant libraries and confidently supply the correct components to developers.

2. Categorising components

Keeping the design system’s primary users in mind, I wanted all of the components to be:

logically organised by use (for example, all components used for navigating through the interface to be situated under the Navigation section)
easy to search for using predictable and indexable keywords
named in a predictable way for the designers and developers to understand

A button should be called ‘button’ for instance to accurately represent its role and function, regardless of whether its colloquially called a ‘link’ or a ‘call to action’.

Sorting components into variants, as pictured above, helped reduce the total number of searchable components per library for a more focused view.

Previously in Sketch, each interaction state and variant was represented as an individual component, giving us an overwhelming 80+ ‘button’ styles to maintain. In Figma, all of these states were condensed into just 3 searchable components, with all interaction states and configurations represented as variants.

To make it easier for everyone to use components appropriately, I added in high level style guidelines as a viewable panel for every component, with links to its in-depth documentation.

3. Rebuild everything, sometimes from scratch

Moving to a new tool involves some design effort to rebuild. I spent four weeks rebuilding components alongside my direct report, utilising Figma’s Auto Layout feature to accurately mirror how content would shrink and stretch at different breakpoints for our banking app interface and website.

Our go-live goal was to optimise all existing components for responsive design. Since then, I’ve further optimised our design library to integrate tokens for colour theming (necessary for future dark mode enablement), and text magnification for improved accessibility.

The time spent generating responsive designs decreased by a shocking 1,500% (I know!! 🤩) and the accuracy of our delivered designs have dramatically reduced the number of defects found in testing.

4. Onboard and introduce everyone!

Ensuring the team were on board with Figma was a lingering concern for us; we suspected downsizing tools would enable us to work faster and more efficiently than before, but we were also asking the team to drop a tool they were intimately familiar with and relearn a new tool immediately, all whilst delivering the entire 2023 change portfolio on time.

To address these concerns head on and encourage adoption, we:

hosted showcases and progress updates to the team throughout the migration process
organised weekly onboarding calls with the US-based Figma team and tutorials for the design team
informed and personally onboarded product owners, developers, and other interested stakeholders across the business onto the platform

5. Establish a new way of working

With a new tool comes the opportunity for working in a new way, so I took the lead in writing our new ‘Best Practices’ guide for the wider team, and an ‘Intro to Figma’ guide for new joiners and busy stakeholders.

With the team’s future in mind and predictions of scaling up swirling in the background, I documented several of our newly implemented design standards for an easier onboarding process for new starters.

The guides I’ve written have helped people across the business embrace the Figma platform and, in particular, get involved with the design discovery process earlier than ever! It’s also helped encourage other teams to adopt Figma and FigJam into their processes, to the extent that our social media, customer experience, and marketing teams have made the jump fully into Figma.

Final Thoughts

The big debate: start fresh or rebuild everything?

We debated whether to keep in-flight projects running in Sketch while picking up new work in Figma, or to make a clean break and switch entirely to Figma once the migration was complete. The team favoured a clean break to Figma, but we had concerns about disrupting development for in-flight projects.

In the end we opted for a phased rollout which took us a month to complete. New feature work was immediately moved into Figma and I worked 1-on-1 with affected designers, copywriters and stakeholders to onboard them with minimise disruption.

In-flight projects required a more considered approach. Some teams were eager to switch to Figma due to shared frustrations with InVision and Sketch, with synching issues hampering their progress, so I dedicated time to rebuilding their files 1:1 within Figma and prioritised their onboarding to avoid further delays.

Once all of the development teams had been onboarded onto Figma we felt the benefits immediately. Collaboration was smoother and stakeholders loved seeing designers and developers working together within the file. Trust was restored quickly between teams, as we were able to collaborate in real time and stakeholders had visibility of entire files and version history, allowing for a strengthened understanding of the design process.

Get in touch