Designing a design system

Her Majesty’s Courts and Tribunals Service, 2018

Problem

When I joined the HMCTS reform program in 2018, the design practice consisted of 18 teams made up of 26 researchers, 15 content designers, 14 interaction designers and 3 service designers.

As each team focused on its own service, many designers were working in silos and solving the same problems from scratch. This meant there was wasted effort and inconsistencies across services.

That is, if a citizen needs to upload a marriage certificate when applying for divorce, and a death certificate when applying for probate, the experience of uploading a file should be consistent, and documented as a design pattern.

Weekly design crits and Slack conversations were helpful to an extent in getting people to share work and collaborate. But because decisions and research were not recorded in a central place, it was difficult or even impossible for people to discover or recall them again in the future.

Our first attempt to document patterns

We previously created a pattern library which codified a number of components. Some components had guidance explaining how to use them, others didn’t. It was difficult to integrate the code into the GOV​.​UK Prototype Kit and production codebases.

We hadn’t considered how to let people contribute and keep up to date with what was being worked on. And there wasn't a clear understanding of the naming conventions.

Collapsible component with no guidance and no code snippets

Influenced by the GOV​.​UK Design System

Working with the Design System team at GDS as private beta partners, some of us were testing out the GOV​.​UK Design System in our prototypes. Using the GOV​.​UK Design System, we were able to:

  • find components and use them according to the guidance
  • get help when things went wrong
  • upgrade our prototypes when new versions were released
The GOV​.​UK Design System.

GDS also asked us to contribute a tabs component to the design system as they were testing a cross-government contribution model. We experienced the extent of what's involved in designing a responsive, inclusive, accessible component to the level of quality needed for the design system.

As we were about to start work on our own design system, we met up with GDS to learn from their experience. We wanted to avoid the problems they faced and reuse their solutions where it made sense to do so.

Reusing what we could

It made sense to reuse several things from the GOV​.​UK Design System such as the layout, naming conventions, guidance and backlog processes because their research showed it to be working really well. (It certainly worked well for us.)

There were, however, a number of things we could ignore.

First of all, the GOV​.​UK Design System team has to accommodate the needs of multiple government departments. As such, the amount of quality assurance a contribution needs to go through before it can be published is considerable.

We, on the other hand, only have to worry about our own program. That means we can move faster with less process.

It is, for example, perfectly acceptable to us to include components as experimental, even if they have less research than we would ideally like. As uptake grows, we can gather more research and iterate the component based on teams’ learnings.

Timeline component marked as experimental.

Secondly, we needed to make sure our design system worked alongside the GOV​.​UK Design System. There were many things we could reuse and we needed to make sure our system was compatible and wouldn’t cause conflicts.

Finally, and in relation to the last point, we didn't need to duplicate all the components and patterns in the GOV​.​UK Design System. We only needed to deliver those that were unique to the reform program. If they could be contributed up to the GOV​.​UK Design System later, that's a bonus.

Launch

In order to reduce the duplication of effort and inconsistency we were trying to fix, we needed to make sure teams could use the design system to share their work with others.

Before releasing our design system, we developed a process to allow users to contribute their work easily.

In addition, we needed to make sure that once new contributions were added to the design system, people could easily update their prototypes to include them.

After creating a number of styles, components and patterns, we carried out research to check that people could use them in their own prototypes.

We then audited our old pattern library against the GOV​.​UK Design System to filter out the components that were already provided. We created a backlog of work from what was left (as a separate Github repo) which the design practice could track and contribute to.

The HMCTS Design System backlog

With a launch email sent, a Slack channel created and a support email address setup, we presented the design system in one of the weekly crits. It was warmly received and by the end of the hour, people in the session had already created new backlog tickets ready for prioritisation.

We'll continue to add components and patterns as needed, and iterate the process.

Check out the HMCTS Design System.

‘I’ve not worked with an interaction designer with such skill, focus and confidence. Adam is not only a pleasure to work with but he clearly loves what he does and is exceptional at it.’

Trevor Saint, Interaction Designer