Orbital design system

Taking ownership of TSB’s design system and resolving legacy change.

Role
Covered multiple roles throughout:
Senior UI Designer
Design System Manager (former)
Lead UI Designer (currently acting)

Industry
Banking

Timeframe
2023 — 2025

Evolution of the mobile banking app

A quick overview

I moved teams in late-2022 into the UX/UI design team as a Senior UI Designer. Specialising in delivering app and web designs across multiple development teams, the UX/UI team had a newly launched design system, but no strategy in place to manage its usage or develop it further.

An additional layer of complexity revolved around the way legacy designs were handled. The first mobile app redesign, dubbed ‘App 2.0’, was launched in 2021 and preceded TSB’s rebrand and the Orbital design system. This created an interesting challenge where designs from the earlier App 2.0 implementation didn’t conform to the Orbital design system, despite sharing the same look and feel, leaving us with a very muddled and often confused looking app.

Over the next 2 years at TSB I...

delivered A11y and WCAG AA-compliant designs for app and web across 20+ development teams in parallel
contributed to and maintained the Orbital design system as a sole IC (individual contributor)
audited existing design system components and planned phased removal of legacy components
resolved legacy accessibility issues in 6 months
rebuilt and optimised 200+ components across the app and web libraries to be fully responsive and ready for dark mode
optimised existing iconography and identified opportunities to bring 4 different icon styles in-line with Orbital
documented 100+ app components with in-depth best practices, accessibility considerations, and content guidelines
documented ways of working, acceptance criteria, and UX/UI definition of done
documented 12+ key design patterns used in the banking app, like capturing consents, entering data, and managing accounts

How the TSB banking app looked before I joined as Senior UI.

My challenge was to deliver a best in class UI, seek opportunities to strategically replace off-brand and legacy interface elements in development, and to pull all of our simultaneous initiatives across the organisation into a consistent experience by wielding the power of the design system.

When I first joined TSB I led a team of 5 off-shore, contract UI designers and worked cross-functionally with 12+ product development teams to deliver the Change portfolio.

In 2024, in the midst of an internal restructure, the UI team was regretfully reduced and I became the sole UI specialist delivering change across the organisation.

Today I am delivering across 20+ feature teams in parallel to deliver the organisation’s portfolio. With this in mind, I have had to strategically choose where I can best affect design and push the Orbital design system forwards, with my main mission centred on:

enforcing design consistency in look and feel
improving the inclusivity of our interaction patterns
preparing the design system and team to scale up

Building a designer and dev-friendly system

Building a design system is the fun part. The uphill battle comes with maintenance and ensuring that stakeholders remain engaged and understand it’s a tech enabler for scaleability, not just a system for designers and developers. This is crucial to keeping momentum when delivering change across the current design system and legacy codebases.

Migrating to Figma in 2023 gave me space to assess our overall design maturity as a team, and an opportunity to address the key issues and blockers designers experienced with the Orbital design system.

Issues raised by the design team included:

Components not behaving as expected: either components needed to be detached in order to be edited, or they didn’t adhere to expected device breakpoints. This created unnecessary rework for the design team.
No ‘best practices’ or rules on when to use components: documentation was either difficult to find, minimal in detail, or didn’t exist from Orbital’s original implementation.
Inconsistencies in built components: either the designs not matching build, or the built components not matching the designs. A fun problem to solve for every design system.
One-off variants and ‘snowflakes’: This was a sympton of a lack of documentation; when designers couldn’t figure out how a component should be used, they tweaked it just enough to suit their use case resulting in numerous ‘snowflake’ components.
Time spent creating final screens for delivery *

* At TSB, every design file was created in Sketch, uploaded to InVision, and then handed over to development teams with mobile, tablet, and desktop breakpoints, and text zoom variants up to 3x, to account for native font-size scaling on handhed devices and in web browsers.

This created an interesting challenge whereby the bulk of a UI designer’s time was spent painstakingly producing individual screens for each device breakpoint. As an example, it would take 1 UI designer 3.5 days to create the mobile, tablet, and 3x font-size views for an app journey containing 50+ screens.

Working smarter, not harder

I was able to automate many of these tasks once we migrated to Figma by:

Adopting atomic design principles and rebuilding 200+ app and web components to follow this methodology.
Creating a new library of 50+ variables for typography styles, colours, spacing, and other reusable UI properties – this will enable us to design for adaptive interfaces (think folding phones!) and utilise colour themes in future.
Optimising components to resize dynamically according to device breakpoints, or scale up to mimic OS-specific font sizing.

It’s not an exaggeration to say that these optimisations improved design efficiency by up to 1,500%. That manual resize job that used to take 1 unlucky designer 3.5 days? Now it takes 2 hours max. That’s less time pixel-pushing and more time spent doing meaningful design.

Demo of rebuilt components, utilising variables and autolayout

Demo of our template library

Less time spent faffing, more time making design decisions

Once I had optimised and rebuilt our components, I produced a library of editable screen templates to enable easier prototyping by the design system and enforce consistency across journeys.

These templates consisted of core, repeatable entry points across user journeys (like the Home screen) or content-editable templates to enforce consistency with information hierarchy, component types, or layouts.

Prior to Figma, a criticism we used to receive centred around inaccuracies in design versus build. Often these inaccuracies occured within core entry points; when managing change across multiple teams, small incremental updates weren’t communicated in time and would cause confusion for teams when comparing the static designs versus the latest app build.

With this template library, I was able to bring all of these changes into one place and push updates centrally. Instead of comparing screenshots with stakeholders and developers and manually updating, designers only need to accept the library update to receive the most up to date view.

Documenting design standards and patterns

For 2 months, whilst delivering ongoing projects, I audited and documented all of our app components and design patterns with 2 Senior Product Designers, Kirsti Wade and Susie Starr. We looked to industry leaders for inspiration, such as the Human Interface Guidelines, Material 3, Carbon Design System and A11y.

We defined design patterns as guidance to handle common taks and actions the user will take when using the TSB app. An example would be ‘managing consent’ and detailing how we would treat GDPR consent requests differently from a hard credit check request. With financial regulations and legislature in mind, these patterns need to be recorded to ensure we’re presenting customers with a fair experience that applies good UX and accessibility practices.

New design patterns that we create are now backed by user research, usability testing, and behaviourial science collected through TSB’s Money Confidence initiative.

Maintaining the Orbital design system

Although I’m the current guardian for TSB’s design system, it needs to be able to work for future teams as the organisation scales up, and it needs to crucially work when I’m not there.

I’ve written several user guides for TSB colleagues to handle Figma’s admin permissions, workspace organisation, and a colleague-wide ‘Welcome to Figma’ guide for anyone looking to use the app as a first-time user.

I’ve written a 20+ page document for my team detailing the following topics:

Guidance on contributing to the design system
How the design system is organised
How to make and push changes org-wide
How to manage and revert version changes
Documenting component behaviour
Best practices on when to use existing components, create a variant, or when a snowflake is appropriate

So how has the Orbital design system performed?

Well done for making it this far. Here’s some juicy stats to gnaw on.

100% adoption across TSB, used by product designers, marketing, mobile and web developers, and stakeholders across the business

350+
team members across the business actively using

~ 95% of the design system components are utilised, with the remaining % earmarked for removal

1,500% increase in design efficiency

Planning for the future

IThe biggest challenge in moving towards a fully scaleable design system has always been the upfront costs, development time, and business priorities.

As a solo IC (individual contributor), I’ve learnt to be resourceful and empathetic to stakeholder needs. I knew that if I wanted the design system to reach its full potential that it wouldn’t be achieved within a year. Many organisations take several years to transition from one system to the other as existing codebase and tooling complexity can take time and money to untangle. But to help push us on the right path, I had a simple strategy to achieve design system nirvana.

Befriend the developers

This has never failed me before. It was vital to share my vision with the lead engineers for a fully scaleable, front-end design system.

By ensuring we work towards a common goal, I could be kept in the loop with tech stack changes and influence the way design was implemented in front-end. Similarly, I could get the heads up on build discrepancies from design and work closely with development to resolve issues.

Keeping one eye on the big picture

Working cross-functionally has its benefits in seeing how all of the org-wide initiatives form the whole. Previously, designers worked across their one project and wouldn’t have a view to parallel-running projects and the decisions made within sub-teams. This resulted in conflicting design patterns and varying content treatment.

By working across all developments teams, I was able to strategically reuse components I designed across journeys, reuse signed-off content to minimise unnecessary rewrites, and rework existing components to have wider application across future journeys. In turn, the time saved by reusing UI elements and content could be dedicated towards UX improvements that were originally marked as ‘out of scope’.

Advocate for scaleability

Decisions can be made and swayed without warning at an enterprise-level organisation. To prevent the design system from being sidelined in the midst of new propositions, I engaged department heads and business stakeholders to:

educate on what our current design system does
explain the current inefficiencies we face
illustrating the cost savings potential from reusable front-end componentry

By repeatedly banging the drum on design system thinking, I was able to persuade my design peers, and in turn, key decision makers, to join in my march. Most recently, we’ve had front-end design system implementation allocated to a new epic called ‘App 3.0’.

Our goals with App 3.0 are to:

Transition front-end developers from hard-coded design values to reusable front-end compenentry, using atomic design methodology
Bring remaining legacy journeys into parity with App 2.0; once the app is consistently using one codebase per platform, we can efficiently transition to a total redesign
Adopt a 100% responsive and scaleable front-end design system, to support handheld orientation in the app and new adaptive UIs
Automate accessibility to prevent costly fixes when defects enter build
Test UI components in islation, so that we can identify and fix issues before they enter the app build

Curious how the design system looks in action?