Orbital design system

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

Role
Covered multiple roles throughout:
Senior UI Designer
Lead UI Designer (currently acting)

Industry
Banking

Timeframe
2023 — 2025

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

Overview

Over 2 years, I’ve worked closely with product and engineering teams to unify the Orbital design system through in-depth documentation for the app design system, collaboration with engineering leads, resolving accessibility defects in legacy design, and enforcing consistency across delivered designs through proactive design system audits, component optimisations, and regular design system updates.

Prior to joining the UX/UI team as Senior UI in 2023, TSB had launched a redesign of the app called “App 2.0” in 2021, followed by a rebrand and the launch of the Orbital design system. This resulted in a mix of design system components, early “App 2.0” designs, and legacy designs present in the banking app, creating a disparate experience across TSB’s digital journeys.

My role has seen me:

manage a team of 5 contract, off-shore UI designers
deliver A11y and WCAG AA-compliant designs for app and web across 20+ development teams in parallel
contribute to and maintain the Orbital design system as a sole IC (individual contributor)
audit existing design system components and phase out legacy components
resolve legacy accessibility issues in the retail app within 6 months
rebuild and optimise 200+ components across the app and web libraries to be fully responsive and ready for dark mode
optimise existing iconography and identify opportunities to bring 4 different icon styles in-line with Orbital
document ways of working, acceptance criteria, and UX/UI definition of done
document 100+ app components with in-depth best practices, accessibility considerations, and content guidelines
document 12+ key design patterns used in the banking app for a consistent user experience

Addressing the pain points

In 2023, I migrated the team from Sketch Figma and led the rebuild of the design system in a team of 5. During the rebuild effort, I addressed some key issues and complaints designers had when using the design system:

Components not behaving as expected: either components needed to be detached in order to be edited, or didn’t adhere to expected device breakpoints.
No ‘best practices’ on when to use components: documentation was either minimal in detail or didn’t exist from Orbital’s original implementation.
Inconsistencies with 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 or Zepelin, 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.

The bulk of a UI designer’s time was spent recreating individual screens for each device breakpoint. As an example, it would take 1 UI designer 3.5 days to produce the mobile, tablet, and 3x font-size views for an app journey containing 50+ screens alone.

Demo of rebuilt components, utilising variables and autolayout

Building a designer and dev-friendly system

I was able to automate many of the time-consuming UI 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 and utilise colour themes in future.
Optimising components to resize dynamically according to device breakpoints, or to scale up font-sizing to mimic a user’s OS settings.

These optimisations improved design efficiency by up to 1,500%.

That manual resize job that used to take 1 unlucky designer 3.5 days to rebuild 50+ screens? It now takes 2 hours max. That’s less time pixel-pushing and more time spent doing meaningful design.

Drag the components around!

Demo of our template library

Less time spent faffing, more time making design decisions

Over the last year I have produced and maintained a library of editable screen templates to enable easier prototyping by the design system and enforce consistency across journeys.

These templates consist of core, repeatable entry points we commonly use across user journeys (like the Home screen) or editable templates that are repeatable and must adhere to the same information hierarchy, content guidelines or component groupings (like errors and outcome screens).

The launch of the template library internally increased designer efficiency and consistency – updates are pushed centrally from the design system as a single source of truth. Any inconsistencies detected in build can be easily fixed with this method, compared to individually updating screens within each design file across the organisation.

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.

Design patterns were defined 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

The design system needs to be able to work for future teams as the organisation scales up, have a robust framework to allow for improvements, and and it crucially needs to 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

A sneak peek at my design system guide.

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

The 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?