The NHS design system belongs to everyone who builds NHS services, but in 2021 nobody had an agreed way of deciding what went into it. I set up the design system working group, a regular, cross-profession group that reviews contributions, approves or rejects them, and helps the team decide what to work on next.
At a glance
- Organisation: NHS Digital, the NHS digital service manual team
- My role: Senior Interaction Designer
- When: 2021
- Working with: two fellow interaction designers who co-ran the sessions, user research, and designers, developers, content designers, researchers and product people from across NHS Digital
The NHS design system
The NHS design system is a suite of tools and guidance that helps teams quickly build robust, usable and accessible services: the styles, components and patterns, the frontend library that codes them, and a prototype kit built on top.
It was growing fast. Around six and a half thousand people a month were visiting the service manual for guidance. The frontend library ended 2018 with 2,395 installs and was heading for over 160,000 in 2021. During the pandemic, teams used the prototype kit to build services like "Get an isolation note" in 10 days and "Find your NHS number" in two weeks.
The problem
The design system relies on contributions from the teams who use it. They propose new components and patterns, or changes to existing ones, in an open community backlog on GitHub.
But there was no agreed way to decide what happened next. Proposals waited. The small service manual team was making calls on behalf of a community many times its size, without a clear view of what mattered most to that community or its users. And with more and more teams depending on the system, every decision carried more weight.
What I did
Asking the community what mattered
Before we could decide anything together, we needed to know what people wanted. With another interaction designer I ran a community backlog prioritisation exercise: first with designers inside NHS Digital, then as a survey to the wider design system community on Slack.
Taking it outside the organisation meant doing it properly. I worked with user research to make the survey GDPR compliant and got it signed off, so the results from both groups could be merged and played back.
Designing the group
I did the discovery and planning: looking at what had been tried before, drafting an agenda and principles, and inviting people from a range of professions to a first session in October 2021.
I deliberately didn't present a finished set of rules. Part of the first session was asking the group to decide what the group should be. My aim was a structure clear enough that anyone could chair it once it was agreed, the way the accessibility working group already ran.
Running the first session
Sixteen people came, and 12 completed a live survey we ran alongside the presentations. The session had four parts:
- Purpose and structure. What the group is for, how often it meets, who's in it and how it shares its decisions.
- Contributions. Three teams presented their proposals and the group voted to approve or reject each one, with comments.
- The backlog. I played back the top six items from the community prioritisation exercise, and the group voted on whether each should go forward in its current form.
- A retro, run afterwards, so we could improve the next one.
What the group decided
About itself
- Purpose: to review additions and changes to the design system. One attendee summed it up as "shared leadership, steer and governance".
- How often: monthly, but deliberately delayed if there aren't well-formed proposals to review. Meeting for the sake of it wastes everyone's time.
- Who: a rotating group of members from a range of professions, with some people kept on as a core for continuity.
- Sharing decisions: in more than one format and place — write-ups, show and tells, Slack, GitHub and email — because no single channel reached everyone.
About the contributions
- Start page guidance: approved.
- Moving the care card component to a pattern: approved.
- Smaller radios and checkboxes: rejected, needs more work.
That last one is the group doing exactly what it was for. Several people questioned whether there was a real user need, asked for testing on mobile, and asked a question I'm always glad to hear in a design system review: has accessibility testing been done on this at all? Better that question gets asked in a room of peers than after a component has shipped to dozens of services.
About the backlog
All six of the community's top priorities were voted to continue being developed: a header for logged in users, an alert panel, booking an appointment with a small time slot, stopping users in a journey, confirmation pages and an NHS login button. The votes and comments gave the service manual team the extra information it needed to decide which to progress first.
What happened next
Within weeks the start page pattern was live in the service manual, and the care card work was progressing. We agreed to share each session's outcomes on a staggered basis, so the write-up, the show and tell and the GitHub updates didn't all land at once and get lost.
What I learned
Governance doesn't have to mean gatekeeping. The most useful thing the working group did was put the right questions in front of the right mix of people early, while a proposal was still cheap to change, and let the community own the answers.