Taking ownership of TSB’s Orbital design system
Resolving legacy change through documentating components and patterns, rebuilding 200+ components, and phasing out legacy design across three value streams across web and app.Role
Covered multiple roles throughout:
Senior UI Designer
Lead UI Designer (currently acting)
Industry
Banking
Banking
Timeframe
2023 — 2025
Overview
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
- 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.
Building a designer and dev-friendly system
- 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.
Less time spent faffing, more time making design decisions
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
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
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.team members across the business actively using
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.
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.
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’.
Our goals with App 3.0 are to:
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
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