Once upon a time, Nucleus

We believe we have a great story, I'm excited to share it with you today. I'll start at the beginning.

Why did we decide to create a design system?

The year is 2018, and we are setting up the DesignOps function within the design team at Centrica.

Our goal: operationalise the design practice to make it more efficient and optimise the design workflow.

We believed that by creating the right environment and providing the right toolkit, our designers could focus on identifying our users' needs and problems and solving them.

We started by co-creating a usability testing report template, this reduced time spent producing usability reports and made them easier to consume for our stakeholders.

We also created easy-to-use templates to design user journey maps and experience maps, using Sketch libraries with all the components needed to quickly create design collaterals. Allowing more time to be spent on research.

All of this really helped re-focusing our designer's time where it had the most value.

During this time we identified a similar challenge, but bigger. We knew we had a fair amount of inconsistency on our website. We used a PDF style guide that was very comprehensive. But it was a static file, with all the inconvenience that brings:

• It goes out of date really quickly
• It's hard work to update
• It's difficult to make sure everyone is using the latest version
• It's a style guide, a reference, there will always be a level of interpretation

We needed to find a way to be better at reducing the amount of inconsistency across our experiences, and reduce the number of redundant patterns.

How about a pattern library?

Our first stab took the form of a pattern library: an online platform that would bring together a guideline on a specific pattern, and ideally coupled to a code snippet.

That was the plan. We needed to find a way to get it done without having a dedicated team and make it a shared effort.

Spotify guilds were the cool thing at the time, and we thought a pattern library guild would be a good first one to set up. We sent a call for volunteers, across the digital teams, trying to gather representation from all disciplines: UX design, front end engineering, content management.

The response was good, very good! Our monthly meetups were well attended and many showed true interest and goodwill to be part of the effort. This was promising!

But as soon as they returned to their product teams, we noticed that they couldn't commit time and effort into the guild's work. The product team's work would always be a priority, and very few were allowed to shift their attention to anything else.

We were unable to convince our stakeholders that investing a small amount of time as a group, into the guild, would have a direct return on each of the teams. The perception was that they were giving away precious time to another team, and the benefit wasn't immediate and direct enough.

Slowly, monthly meetup after monthly meetup, it became apparent that there was little progress towards the guild's vision, and it became almost demoralising for those trying to drive engagement and enthusiasm for this shared repository of design guidelines and code snippets.

It became apparent that we needed a dedicated team, a group of experts that would be able to bring disciplines together around a tool that would serve every other team.

A design system that goes beyond patterns

While we tried to get the pattern library up and running, our design leadership was transforming itself. We started defining and establishing our DesignOps function – a team of leaders that would create the right environment for the practice of human-centred design across our digital teams. The discipline revolved around 4 pillars:

• People
• Tools and methods
• Collaboration
• Design Value

I won't go too deep into this chapter of our design team's history, but if you want to know more, you can read Matt Gottschalk's post.

One of the drivers that cut across all four pillars was something that was being talked about increasingly in the design and engineering community, the next evolution of style guides and pattern libraries: Design Systems.

We started defining what it could be:

• A design system that has its source of truth in the coded components that customers engage with
• A design system that is inclusive: not a designer tool but a tool for everyone
• A design system that increases collaboration, and brings people together
• A design system that has accessibility at its core

We were really excited about it as it would definitely help us in our design operations, so once we exposed our idea to our Head of Design and Digital Director, we took it to the senior leadership (Chief Marketing Officer, Head of Brand, Managing Director, and Digital Director amongst others) to get support and investment. This was probably the most expensive meeting I've ever hosted considering the hourly rate of the attendees 😅.

After defining what the system would be and explaining what benefits and improvements it would bring.

We outlined a 3-stage proposed roadmap:

• Stage 1: proving the value and benefits of a design system
• Stage 2: increase coverage
• Stage 3: enable the system for other brands

We got initial buy-in. We then proposed and agreed on a few key performance metrics: accessibility levels, site performance, search engine optimisation performance, and speed to market. These would tell us if our proof of value is successful or not.

We were on! We had the budget to put a team together and start the discovery work!

Stage 1: Proof of value

Now to deliver on our promises.

We put together a team: a couple of Designers, a couple of Engineers, a Product owner, and a DesignOps manager to look after the team and be the link with stakeholders.

Our work was coinciding with a brand refresh, and it was the perfect delivery opportunity for us: delivering the brand refresh by adopting the design system would be a great driver for adoption (more on that later...).

In order to prove that a design system delivers on its promises, we agreed on key metrics areas for the initial work:

• Accessibility levels
• Page performance (weight, speed, dependencies)
• Search engine performance
• Speed to market

We now had the first iteration of the team put together, and we could get into the system work itself! The first thing was to translate our design system vision and mission into accessibility, experience and creative principles.

These would guide everything that is added to Nucleus from that day forward, so it was important that they were robust and made sense to everyone who would be contributing to the system.

Next, an audit was taken on the existing website alongside the brand refresh. We reached out to as many people as possible to share pages, components and patterns to be included in the audit.

Then we defined the design system foundations: colour, grids, spacing, typography, etc... The team worked together to identify these elements that would be combined together to create components.

Then, based on the set of content pages we decided to use for the proof of value work, the team started identifying the first set of components that we'd need to have in the system: hero banners, buttons, content blocks, etc...

Those first components would be the perfect testbed for deciding on our coding practices, how we would encapsulate the structure and style, and make them accessible and configurable. Each of those components would be accompanied by full documentation with their purpose, a detailed specification, content guidelines and dos and don'ts.

We worked in close collaboration with our brand team and the agency they worked with at the time for the brand refresh. And alongside our digital product leaders, the search engine team, and the content management team.

The result was the release of a selection of content pages to our live site, to a portion of our traffic, starting with 1% to make sure we didn't break anything then ramping up slowly. The metrics we agreed on were all looking good, and we added more pages built with those components, proving that the system was delivering on its performance promises.

Our Google Lighthouse reports were showing improvements in all areas, and the search engine team had similar feedback for us regarding the performance of the new pages.

On the back of these good results, we were given the go-ahead to continue building on what we had achieved so far and increase the number of components to enable teams to start adopting the design system.

Stage 2: increase coverage

The next logical step in our journey was to offer more components to meet the needs of the teams so they could start adopting the design system for their experiences.

That meant that we had to start aligning our backlog and priorities with all the other teams' priorities and backlogs. Continuously having conversations to identify opportunities to maximise the value of anything we released: whenever we saw that more than one team had the same need, it was a good candidate for our next piece of work.

Enabling contributions

While our team grew slightly to welcome one more creative developer and a quality assurance analyst, we also recognised the need to start encouraging contributions from our community. And for that, we needed a workflow/process that worked for them, as well as for us.

We set up a workshop with all the disciplines involved: design, engineering and testing. And we looked at existing contribution models from those who we looked up to when we started working on Nucleus: Carbon, Atlassian, and GDS were some of the models we looked at to set the theme. We then ran a series of ideation rounds to identify the needs, worries and hopes of the group. The outcome was a really good first iteration of a contribution flow that worked nicely with our own teams, their rhythm and ways of working. It was important for us that it came from them, and that we didn't decide for them.

Encouraging adoption

Over the following months, we started releasing more new components, and extending existing ones with new features as we learned from the teams, we were able to get them tested in the context of real user journeys being user tested by the teams. Very soon we were offering components that enabled teams to design and build functional journeys, not just content pages.

Adoption really only happens if there is awareness. And to tackle that, the team started organising events such as weekly Drop-in Cliniques where they would demo the latest work in progress and anyone could ask any Nucleus related questions. Every month we'd showcase everything we released to the entire digital community during our Squad Achievement session, with a different member representing the team every time.

We attended the design team's critique sessions. These were the perfect occasion to see work in progress and provide any advice we had on the best components available for a particular interaction or piece of content.

We set up a kiosk in a high-traffic part of our floor – a simple RaspberryPi and a big screen showing Storybook open on a component so anyone passing by could play with it, change it, and customise it.

Measuring our impact

We needed to see if our work had any impact. We already monitored our KPIs, but what we needed to capture was how widely spread these outcomes were across our digital products.

We set up an analytics tool called Grafana to see how many times our components we re-used, which journeys were consuming Nucleus, understand how fast (or slow) was our growth and who we needed to speak to about the potential benefits a team was missing out on.

We also started capturing team success stories whenever a new journey was released using Nucleus. And for every team adopting the system, there was a happy outcome; lower error rates, higher conversions, better page performance, and increased organic traffic. (We are still waiting to hear of anyone with a horror story, and are quite happy to wait another few years before getting one!).

Stage 3: Scaling the system

One of the buzzwords in the holy trinity of buzzwords of the last decade, together with "agile" and "transformation", is probably "scale". In big organisations, we all have been asked to drive this or that "at scale".

If we were to look at our design system and what it would mean to scale it for the organisation, it would most probably mean that it can be used by as many of our customer-facing experiences as possible. And Centrica does that through a collection of different brands, all with their visual identity and specifics. Can we make the benefits of a design system available to those brands too?

Now, that is an exciting challenge! And just like we started on Nucleus, we worked on a proof of concept. We set out to answer the questions: can we use Nucleus components to build a selection of pages from another brand in our portfolio?

We picked a brand that was being worked on in 2020: British Gas Evolve. An online-only offering that was powered by British Gas. We selected a few pages (homepage, product page, and acquisition journey) and started building a copy of those with Nucleus components, without changing the styling just yet, only matching components that were doing the same job. Once that was done, we started ripping the branding and styling off the components and applying new styles to try and match that one of British Gas Evolve, and ended up with something close to the original (see screenshots below).

With this first proof of concept, we answered the question "can we use our components and apply another visual identity". Yes, we can.

Now, what we did was rip the skin off our components, and glue another skin back. That's not the cleanest and most efficient way to have a repeatable and scalable system that can serve multiple brands. So how could we do that? How could we make our components adopt several looks and feels without changing their fundamental structure?

We found that there are 2 answers to that question. The first answer is obvious: design tokens.

Design tokens

We started separating some styling aspects from the components by creating design tokens for things like spacing, colour, typography, etc.

And to see if it worked, if we could effectively give a different look and feel to our components by only changing the design tokens, we tried to re-build a selection of pages and the acquisition journey of our Irish friends at Bord Gàis.

The result was pretty impressive and got our components to serve a version that was much closer than I expected. I do not think that a customer would've been able to tell the difference. This was very exciting! We now know that we can apply a brand look and feel to our components in a repeatable and efficient way.

The second answer is all about: the future.

Why stop at design tokens?

Enabling multiple brands got us thinking, what if there is a bigger opportunity to it? Could we take our thinking further and de-couple the brand layer even more? Devolve its control to the federated teams across the organisation? Teams do appreciate a certain level of freedom, and we have been brand guardians for a long time now, time to pass the baton!

And maybe within our organisation (or even those outside), a team wants to be able to build their design system because their needs are completely different to those of British Gas, could we give them a solid foundation to build on?

We aim to offer more flexibility, distributed responsibility and accountability where required, and a solid foundation to build on, trying to infuse it with almost 4 years of experience in systemising design and creative engineering.

We have been working hard at this new approach for our design system, and are releasing our first beta internally as I'm writing these lines... I cannot wait for us to tell you all about it!