A short(ish) history of the NHS design system, Part 4: 2019 — putting the design system ‘out there’
The NHS design system was rooted in the redesign of the NHS website, but it was by no means the limit of what it could be used for. All sorts of services, systems and websites would be able to use this, in order to save time (and public money), improve accessibility, and so on. We encouraged teams to start using it with new work, and existing services to start mixing in new components as they went.
We knew we were sharing a basic kit of components, that would not cover the variety of needs teams were meeting. Our advice was 3-step:
1. Start with what’s in the NHS design system
2. If there isn’t a component you need, take one from GOV.UK, repurpose and test
3. Only when 1 and 2 are exhausted, should you make a new component.
This was a good way of allowing teams the flexibility to kick the tyres and give us feedback.
Whilst this worked for the NHS Digital design community, where we held regular huddles and workshops, we did learn lessons on how we presented this work, and our team, to the wider NHS community. As with any service, it never survives first contact with users, no matter how much you think it will be understood.
On the service manual Slack, we would get requests for components from people in trusts, and when they were likely to expect them to be made. This is understandable. When small teams — sometimes solitary practitioners — in a regional NHS organisation see a (from the outside) well-funded and resourced national-level team sharing components, it’s reasonable to expect there would follow a steady stream of new components to fulfil every scenario.
We needed to take the time to explain that this work would be 2-way. We had a backlog, but only of things we on the NHS website team identified were needed on the NHS website. We encouraged participation on the service manual’s Github backlog, to share experiences and evidence of components, proposals for new ones, and to help the team prioritise things.
Pee and poo
The content design community were equally vital to the success of the service manual, as the design community. Shareable content patterns and language usage went through the same rigour as design components, even getting media attention through its use of simple words such as ‘pee’ and ‘poo’. The team also published extensive guidance on asking good questions in forms, which would prove vital in the coming years.
Wait, not like that!
We also learned a lot about component guidance — naming components so their purpose is understandable, and how and when to specify their usage. We found lots of people started using the care card components in their services, likely as they are one of the more visually striking parts of the system. But their usage is very strictly governed, so we had to rewrite rules around that.
Likewise, even though we made decisions not to make certain components available in the design system (for example, if they were too specific to NHS.UK, such as the homepage ‘welcome’ component), teams would just take code from the live site and use them anyway. There’s little we can do to stop this, but the intent of a design system is to encourage consistency, not mandate uniformity. So there is more to be done there, in the future. We do not need, or desire, every homepage of every NHS website to have the same image/graphic layout or function.
Autonomy versus governance
While all this community-based activity was going on, the team were also busy making a prototype kit, and running internal training with both designers and other colleagues. NHS Digital has exceptional content designers, who were keen to try mocking up their content with the new suite of components, without having to rely on the availability of a frontend developer, for example.
The team trialled new methods of governance, and ways of managing new submissions to the design system. This is difficult work. Different teams have different levels of maturity, and differing amounts of time in their schedules to make components or patterns shareable on something like the design system. Balance is hard — how do you encourage busy teams to contribute, but also exercise enough rigour to ensure the submission is worthy of inclusion? After all, every new element to a design system has a maintenance overhead — code, guidance, governance, not to mention adjustments, should the overall design change in the future. Getting this right will continue to be a challenge for any design system.
So while 2019 didn’t have the whizz-bang releases of 2018, the depth and breadth of work around the design system was profound, as advocacy, process, user experience and community were the focus. The team reviewed, researched and redesigned the information architecture of the service manual, to better meet people’s needs. This was presented in the February 2020 Gov Design meetup by the incomparable Misaki Hata, and we were looking forward to what the team should do next.
If only we knew…
