2020-05-21

Presentation about Nucleus to Waitrose

Nucleus - British Gas design system

Hi there and good afternoon.

I'm Drew Jones, and I'm in the design system team at British Gas.

I'd like to thank Darren for inviting me to join you all today. And I'd like to say Hi to Almos and Darryl if you're in the room!

Thank you also, to Lewis for his presentation last week on accessibility and the checkout. I was heartened to see how seriously inclusivi-ty is taken here. Myself and my colleague Jon snuck in the back door at last weeks Techbyte.

British Gas Digital

British Gas Digital comprises about 180 cross-discipline people responsible for the customer facing websites and apps.

We currently have 14 product teams who are responsible for somewhere in the region of 34 products.

They include:

• Energy - a variety of different energy tarrifs

• Home Services which include, our HomeCare products, Insurance, Home repairs

• Smart Home where we have the Hive Active Heating range

• Customer Help and support

• Identity - which is My account

A Design System - 1

A design system can be many things to many people.

For a new starter, it can be a place to immerse their mind on all things related to digital products.

For a director it may present itself as community adhering to common ways of working.

A Design System - 2

Ultimately, it's what each individual perceives it to be.

A design system exists to solve everybody's problems, not every individual's problem.

And for those that are well versed in the world of design systems. Here, Jina Anne and Brad Frost extrapolate "Design System" into a metaphor for working together.

At the beginning - 1

Before my time, a concerted effort from a few key advocates to research, understand, promote, demonstrate and educate decision makers on the benefits of a design system had been a success.

The timing coincided with the commitment to rebrand the British Gas website, and it was agreed that the design system was the right vehicle for the rebrand. This is where we acquired the funding to begin.

The project kicked off almost two years ago - in July 2018.

Leading the design system would be the engineering department, which in my opinion was a very wise choice as one of our primary mantra's is that the "code IS the product" alongside a very close relationship with the UX community and leadership.

There were 5 core members at the start. 2 engineers, 1 brand, 1 designer and a product owner.

Here, we focussed on building our foundations with close collaboration with the brand agency to introduce the colours, typography, shapes, and the like.

At the beginning - 2

With the scope of "only the content managed pages", ignoring - for now, the digital journies.

You can call these the brocureware pages. This was due to the influence the brand had on our product at the time due to their heavy investment.

At the beginning - 3

Having printed out the pretty looking scamps of the website we got our scissors out and chopped it up and made piles of solutions and similar user interface patterns.

This was essentially our first audit, where we disassembled the brand vision and familiarised ourselves with the problems that the existing site had and chose suitable candidates which we thought may replace existing components.

From the 294 different colours contained within our existing CSS and a vast array of font sizes it was clear that the existing style library had gone rogue.

At the beginning - 4

The Nucleus team quickly ramped up to include 2 more designers, a scrum master, project manager, a visual tester and two CMS developers. So quite early on our team was pretty big while we focussed on delivering a target for the rebrand. Which certainly affected our focus away from the design system and towards satisfying a brand deadline. But was key to the perceived success of Nucleus.

At the beginning - 5

The core team scaled back to focus on the community, our vision and mission, defining principles, processes, conceiving tools, refining and documenting our foundations. And settling on the working habits that we found mostly reflected our principles.

And we evolved and itterated over our components to better resolve the problems we were aware of. With the help of user and accessibility testing with our partners at the Digital Accessibility Centre.

Along the way we had identified that our physical proximity to the majority of the product teams had an adverse effect on our success to engage the community as we were located in a quiet part of the office. So we set out on a range of promotional and educational activities.

At the beginning - 6

Here we invited anyone - litterally anyone! To join us and hear what we had been up to and the impact the design system was having on those that were engaged.

Here we are sharing the experience of the CMS team who had seen a decreae in the time taken to deliver a content managed page.

Where we are now

Nucleus is considered a relatively mature product; but it's still in its adolescence. It is recognised by each and every product team and is firmly embedded with everyone across digital. But there's a long way to go to achieve the goal of 'full coverage' (what ever that really means).

We are now 4 engineers, 2 designers, 1 test analyst, product owner, scrum master and design Ops.

The driving force of the design system is our community. And at the centre of this is our Request For Change process where we invite anyone who has identified a customer need or a problem to initiate an open conversation with Nucleus and the rest of the business.

This RFC process can cater for the biggest challenges that we are likely to face, to small improvements to existing solutions.

Principles

We refined three sets of principles:

Accessibility principles, which we derived from the Web Content Accessibility Guidelines - WCAG 2.1 Which are

• Perceivable

• Operable

• Understandable

• Robust

Experience principles, which evolved from a concerted effort from the brand team

• Tailored to individuals

• Leave no one out

• Always there

• Make life simple

• Go beyond

And creative principles, which were carefully considered by the brand agency

• Modern and dynamic

• Clean and fresh

• Warm and friendly

Tools

We have developed our own tools and have embraced those that we found work for us.

Github

• Request for change

• Our team's Kanban board

• Docunment Support requests

• Code repository

• Stories

• Discovery

• Research

• Testing

PaDL, is our own tool, stands for - Pattern Design Library System

• Generates all the files that a developer would need for a new component

• Creates a kickass development environment

• Bundles and tree shakes all the needed files together in to one Javascript file [Nucleus.js]

Storybook

• Components

• Working examples

• Code snippets

• Automated testing

• Programatic accessibility checking

• Embedded documentation

Tools - 2

Documentation site [docs.britishgas.design]

• Markdown

• Gitbook

Prototyping tools different shapes

• Advocase Designing in code - [support those]

• Closer representation

• Identifying needs and issues before develoemnt

• Also, providing guard-rails to designers

A Sketch library, the focus of which has changed dramatically as we now advocatging designing in code with the prototyping tools and is destined to contain only the foundations which will be used to help ideate new design concepts.

Conversation

• Slack

• Github

• Sessions like these TechBytes

• Workshops [focus]

Technology

Before the project team was assembled, some fundamental technology decisions were made. The most important of which was deciding to build the design system with Web Components. If you're not familiar with Web Components, Wikipedia cites them as:

"A set of features that provide a standard component model for the Web, allowing for encapsulation and interoperability of individual HTML elements."

Primary technologies used to create them include:

• Custom Elements: which are essentially APIs to define your own HTML elements

• The Shadow DOM: encapsulated Document Object Model and styling for each web components

• HTML Templates: which are fragments that are not rendered, but stored until instantiated via JavaScript

[not-making-our-ds-not-beholden-to-any-technology-framework-agnistic-separated-holds-its-own-tech] So, at its core, [Web Compoents] HTML, CSS and Javascript.

Web Components were introduced in 2011 and all major browsers [native] support them.

Accessibility

We put accessibility at the forefront. It's a continuous process to promote and empower colleagues to improve the accessibility of everything they do.

And with yesterday being Global Accessibility Awareness Day- and it's mission: To Increase Awareness of Digital Accessibility. I thought I'd mention it to you all, in case it passed you by.

WebAIM do a 6 month audit of the top 1 million most hit homepages of the internet and British Gas are in this list! We are #57,332 of 1,000,000

Waitrose is there too - [add-link-and-stats]

WebAIM rank these million against the A/AA WCAG 2 criteria. The audits ran in February and August 2019 and recently in March 2020. Our rankings: 59,813/1,000,000 in Feb. 2019 52,109/1,000,000 in Aug. 2019 41,386/1,000,000 in Mar. 2020 This new improved ranking puts us in the top 5% of all homepages for accessibility, but we still have 2 accessibility errors on the homepage which is a real shame.

To put this in context, accessibility errors on the top 1 million have increased in the past year from 97.8% to 98.1% with an average of 60.9 accessibility errors per homepage.

Performance

We are heavily focussed on performance.

• We are reliant on native Javascrip APIs

• We lazyload

• Build using Web Components

• Make things as simple as possible for the browser

We try to build Nucleus as close to the metal of the browser as possible.

We can see that our mesaure of speed is slow at the moment, so this gives us a benchmark in which to improve on.

Considered changes can make a vast improvement in performance.

Process

As I mentioned earlier the core of our process is our Request For Change, it exists as an issue template within Github and it encourages anyone wishing to make a change to the design system to describe the problem and justify it along with an understanding of the impact IF the change is not introduced and to provide any research to support the need to solve.

[show-RFC-template]

What are you trying to do?

Provide a brief description.

• Don't provide any solutions at this point.

• Please don't perform user testing on a solution at this point.

Why should this be done?

Provide example scenarios where the problem occurs.

• Is this problem faced by other teams?

• Is there any evidence backing the need?

• What happens if we don't do anything about this problem?

Why should we not do this?

Can we use a component that has already been built?

• Is this going to create complications in the future?

• What are the tradeoffs?

• Are there any designs to be considered?

Has this problem been solved before?

• Add some screenshots or other assets.

• Add any user testing and case studies previously done.

• Is there any user data or other insights?

Have you started to explore a solution?

• Provide initial ideas.

• Add some screenshots, wireframes or other assets (label these as live/concepts).

• Remember that this needs to be understood for all mediums (mobile, app, web).

• Do you have any unresolved questions?

Existing project teams are encouraged to take the opportunity to reimagine their product, taking the Nucleus principles, best practices and all available resources to help them.

A key activity for us is to come up with new, alternative solutions time and time again to see what works best. Some existing solutions might be solid solutions in their own right but might not quite fit the desired experience principles, accessibility criteria, or visual language we're aiming for.

The principles are used to help:

• Ideate to provide constructive constraints

• User research and testing to learn how these principles might best be met

• During design and sprint reviews as shared evaluation criteria

• As metrics to provide cross-team, cross-journey data

• In analytics to track changes over time

THE END

[Storybook-encapuslates-components]

[Components-are-often thought of in context of their journey and not solving the same problem for all]

[phlosophy - code is the source of truth]

[dont version our library, so always the latest and can't go stale anywhere]

[Your DS will grow into something that you wuldn't expect - we are buidling common experiences - we thought teams would build these and contribute back , but that's not the case at the moement.]

[core-team-is-vital to drive the community]

[keeping the community]

[huge amount of time to create the community and now it's stable, but we've dropped the effort as we're focussing on other]

[lots of time was soent taking with stakeholders in the early days.]