Building the Constellation Design System

Over the past two years our team has built a design system for Lloyds Banking Group. It’s been an interesting journey; taking a product from small beginnings through to a multi-brand design system with an engaged community. Like any system, we have changed and evolved based on user needs.

It hasn’t always been plain sailing but smooth seas don’t make good sailors! I’m proud of our small team’s achievements. Our work is not open-sourced so I wanted to write a post to share our journey so far.

A screen grab of the Constellation website homepage
The Constellation Design system website

What problem do we 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 buttons taken from the Halifax website. There are 26 different variations, each with a different colour, text and icon.
The 26 variations of a button on our Halifax public site are a great example of why we need a 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

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! A card sort with users can help. If you’re struggling to name and structure your components, Nathan Curtis has some wise words.

Website

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 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 our form components 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.

Advocacy

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…like when you have a party and have no mates and no-one shows up. 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 also run the occasional 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. If you’re interested in attending we usually share the invite on the Design Systems Slack city-london channel.

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 boss 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). Don’t beat yourself up and 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: Initially we lacked any mechanism to feed back into the system. We’ve recently set up a board to log bugs, issues, and requests which is slowly getting some uptake. We also accept code contributions on GitHub and actively encourage teams to contribute tested components. We still have no formal process to contribute design. This seems to happen organically, however as the team grows we will benefit from a considered process.

Accessibility: 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 fortnightly drop-in session from the Digital Accessibility Centre who give us expert guidance. Accessibility was a big hole in my skillset when I joined and I’ve needed to quickly upskill. I’m such a nerd that it’s become one of the most interesting parts of my job and I’ve even shifted the focus of my blog to focus on accessibility.

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.


Not bored with the nerdery of it all? Want to chat about Design Systems? Find me on Twitter.

Feedback from you lovely people: