Building the Constellation Design System

I spent three and a half years building a multi-brand, multi-platform design system for Lloyds Banking Group.

Lloyds is the UK's largest retail banking group with over 30 million customers. It was an interesting journey; taking a product from small beginnings through to an established design system with an engaged community. Like any system, we changed and evolved based on user needs.

The Constellation Design system website
The Constellation Design system website

It wasn't always plain sailing but smooth seas don’t make good sailors! I’m proud of my small team’s achievements. The design system is not open-sourced so here is a case study to share the journey.

What problem does it solve?

The aim of Constellation is to bring consistency across a visually fragmented digital estate. Historically, there have been different interpretations of the brand guidelines across value streams and product areas. Each team individually designing and coding their own interpretation of core components (headers, form fields, buttons) has led to significant variation.

Visual consistency is proven to help customer engagement. Inconsistent branding ultimately erodes customer loyalty and brand trust. Consistency is not limited to visual assets but extends to copy and shared conventions.

Graphic showing 26 different button variations on the Halifax website.
The 26 variations of a button on our live Halifax public site vs the clarity and consistency offered by our design system

Getting started

When I joined the team, we had the catchy name of ‘Unified Design System’ or UDF. Being associated with an acronym best known for a Northern Irish paramilitary group didn’t do much for the inclusive and welcoming nature of the team 🤗 so we decided to rebrand. We mooted lots of names, many horse related (pegasus? stallion?). We put it out to our end users who voted on Constellation. Constellations are recognisable patterns that help people to navigate so it seemed fitting.

Our junior designer created us a super logo. However, it wasn’t until we had stickers printed that we finally felt like a PROPER design system.

Constellation logo
New team logo

What to include?

Before I joined, the team had decided to focus on form components. This was the quickest way to add value as application journeys feature heavily across the banks’ products and platforms.

Initially, one of the most difficult decisions we faced was naming components and deciding on a structure. To ensure the system worked for our users our Product Owner arranged a card sort. We printed off paper versions of components and invited designers, developers, conversation designers, and product owners to name components and sort them into categories. We based our structure and naming conventions on these findings.

Constellation covers four brands; Lloyds, Halifax, Bank of Scotland and MBNA. The complexity of building a multi-brand system has bought its challenges but the upside is any improvements are propagated out exponentially.

Printed out website design components on a table.
Naming the thing is much more difficult than making the thing! We found Nathan Curtis's articles on Medium a valuable resource.


Our components are built with React and code is our system’s source of truth. Our original developer built us a simple pattern library website that exposed the React library. It was purely functional and meant that the team could see a live version of each code component without needing GitHub access. We have built out this site over time and it now offers:

  • Editable props for live components, showing states and variations
  • Links to install Sketch libraries and download sample Sketch layouts
  • UX best practice guidance for each component
  • Content best practice and Plain English guidelines
  • How to write for each brand
  • Accessibility guidelines
The Constellation pattern library website, showing a component in design and code views
The Constellation pattern library website, showing a component in design and code views

The site has been through a few iterations. We’ve learned from user feedback what’s working and what needs improvement. We initially had a Hudl inspired switch between a design and code view. It’s a really effective switch on the Hudl site and it looks super cool but our users just didn’t get it and completely missed the point. We eventually removed it and replaced with buttons on each component page. The simplest solutions are often the best! The site is still very much an MVP and our ethos has been to regularly ship small iterations, get the correct content up there, then go back and prettify it when we have time.

Sketch libraries

We started with a basic Sketch ‘kit’ for each brand with Sketch symbols as closely aligned to the code as the design tool would allow. Flat images of components were displayed on InVision with the corresponding Sketch source files to download.

The problem with static kits is they quickly go out of date. Designers would download the kit once and save locally so would miss out on any updates. Our federated designers loved this system as it’s easy to work from one file you have ownership of. This system was always set to fail though as when design files got to engineering, components looked different to the code and time was wasted questioning which version was correct.

Screen grab showing components in the Halifax Sketch design library
A small grab from form components from our newly rebranded Halifax Sketch library

In an effort to maintain one ‘source of truth’ for design we needed a way to push Sketch libraries out to designers. I discovered Sketch had just released a way to install libraries through an RSS link. You could host a Sketch library file on any online server, publish an RSS that points to it and have Sketch subscribe to the RSS to get updates when the library is updated. Bingo! This meant designers could install Sketch libraries from our website, we could push releases and everyone would always be served the latest components. Sketch hasn’t published detailed documentation on how to do this so here’s a useful guide.

We saved our Sketch libraries on GitHub and our delivery manager built us a nifty little Apple Script tool, aka the ‘Deploy-o-tron’, that uploads the new Sketch file, versions and archives the old. We adopted a semantic versioning system to number releases and denote a bug fix/patch, regular release and a breaking change.

Taking away designers’ Sketch kits resulted in a lot of frustration and complaints.

People hate changing their ways of working and I totally empathise. But sometimes you have to make things messier short term to improve long term. And help folks to navigate the messy bit with some support and kindness.

Sketch brand swapper

Another goal we have been working towards is consistent naming between Sketch libraries. If symbol, layer and text style names are consistent, you can use a Sketch symbol swapper plugin to swap one brand layout into another brand. It’s still a long way from perfect but it is a bit of a time-saver if you’re producing the same layout across multiple brands.

Image showing a screen shot of a bank eligibility screen in 4 different brands.
Same journey swapping brand with Sketch symbol swapper plugin

Another possible application of this would be to create a white-labelled library for brand-agnostic prototyping. Branding and design often get in the way of testing user flows. Creating a white-labelled version of the library would allow you to hack together a quick prototype, then apply all the styles with two clicks. Perhaps one for the future?

Versioning design files within the team

Initially there was me and one other designer working on Sketch libraries. Our versioning system involved shouting “close that file, I’m updating icons!” across the office. This works great when there are two of you but is wildly inefficient, prone to error and doesn’t scale.

As the team grew, we needed a proper versioning system for design files. We did a spike to test various systems; from hacky GitHub Sketch plugins through to fancy new systems like InVision Design System Manager and Adobe Experience Manager. Both companies very kindly gave us a face-to-face product demo.

We then had a call with Abstract and decided to trial it. Onboarding was easy and the app was so effective we have been using it ever since. Abstract is like a GitHub for designers; allowing you to branch off a master and fork from each other’s branch. Since installing Abstract we haven’t lost or overwritten any work and it’s proved an essential tool for designer collaboration.


In the beginning, not many people knew about our product and what we had to offer. At Lloyds there is no single platform to communicate to the masses and it’s hard to get noticed. Our team has travelled the country to advocate the system and to encourage product teams to get on board and contributing. We’ve attended hackathons and arranged demos and workshops to give our code visibility and show folks how easy it is to use.

Our most successful outreach has been a weekly drop-in session. We set aside each Thursday afternoon and sent an open invite to swing by or phone in. To begin with we sat there pretty lonely but over time word has spread and it’s become a popular session. Teams who are using our design and code visit, we get their journey up on a screen and run through. It’s a great place to get lots of eyes on a problem and get input from UI, UX and engineers.

We've also run a quarterly design systems meetup with the wider community. It’s a pretty informal get-together where we invite other design systems teams in to chat about a theme; multi-brand, breaking changes, advocacy, tooling. It’s been useful to learn from the other systems teams and to appreciate that everyone is facing the same challenges. We share the invite on the Design Systems Slack city-london channel as it's where most of of wider audience congregate.

Bumps in the journey.

There have been many!

Imposter syndrome

When you’re starting out it’s hard not to compare yourself to established systems. I used to regularly pipe up with “when we’re a proper design system like xyz” to be reminded by our PO we were designing a system for a bank with 30 million customers 🤦‍♀️. Everyone’s design system will always appear fancier than yours from the outside (in the same way everyone’s life looks more interesting than yours on social media). We learned not to beat ourselves up and to celebrate the small victories.

Move slow and fix things

I joined from a startup environment where I was used to working in an iterative way – running A/B tests on hunches, learning from the data and making small, incremental improvements to the user experience. We initially made some UI changes without consulting our wider audience of designers and developers. These changes were based on findings from Customer Labs testing which we thought was enough of a justification for the change. What we didn’t do was take our consumers along for the journey. Going forward we have shared with our users and invited them to contribute their research, opinions and thoughts before making any UI changes.

User contribution and feedback

We set up a Jira service desk where product teams can log bugs and provide feedback. This has had good uptake with developers. We also accept code contributions on GitHub. We're still working on a proper contribution framework. Our aim is to become curators and allow teams to contribute part-complete or untested components for other teams to develop.


Not all the components we inherited passed WCAG 2.1 AA accessibility criteria. We’ve had support from AbilityNet who spent a fortnight at our office testing our components and helping us to improve. We also have a monthly drop-in session from the Digital Accessibility Centre who give us expert guidance.

Incompatible tech stacks

Large, complex organisations like Lloyds have lots of legacy code. We’ve had teams keen to consume our libraries but unable to do so because they are using old versions of React. Our policy has been to use the latest version and keep updating. Teams can plan to use us when they are in a position to update.

Relying on third-party plugins

My gut says never to use a third-party plugin or app – it can conflict with the core and you are relying on the maker to update it. This came back to haunt me when Sketch introduced their Smart Layout functionality in Version 58. We had been relying heavily on AutoLayout, a Sketch plugin, to make our components responsive. When Sketch V58 was introduced all our responsive components misaligned causing pain for our users. We had to own it, send out comms telling designers how to manage the problem, then spent a sprint providing a fix. No-one died but it did make me appreciate how important testing the beta version is before it’s released and work this into our process.

Resources I’ve learned from:

Next steps?

It’s been an interesting journey, taking a product from small beginnings through to a thriving community. Our team has fought a lot of battles to get to our MVP but we’ve made a positive impact on both cost savings and the way designers and developers collaborate. Over two years we’ve apparently saved the bank £7 million in design and build costs! Not bad for a team full of imposters : )

On our roadmap is applying a content-first strategy, maintaining and improving accessibility standards and leading the roll-out of new branding for Halifax.

Feedback on this piece:

Continue reading

Freelance UI design for startups

Prev project

Scaling accessibility with a design system

Next project
Headshot of Geri Reid, a white woman with long dark hair, wearing a blue and white striped top, looking off to the side

About me

I've designed digital products for the past two decades.

As design and accessibility lead on NewsKit design system, I helped some of the UK's largest media and broadcast brands to design at scale. I was design lead on the Constellation design system at Lloyds Banking Group and set up design system foundations at and BPP. Way back, I designed digital products at UBS and Bank of America.

Over time, my design roles have become more strategic: planning, training and writing technical specs and docs. My work on systems has also made me a keen accessibility advocate. Through care and attention, I've learned how a design system can provide a solid foundation for product accessibility.