A short(ish) history of the NHS design system, Part 3: 2018 — standardisation and launch!
While we were working towards our September launch of the redesigned website, we were also setting up a separate team to investigate how to standardise what we had, to make it easier for new work to be created. We’d obviously benefited greatly from the GOV.UK design system, and now we had our own emerging system of components, we needed to think about how best to offer them to new teams.
A small discovery team was assembled to investigate this.
We needed to think about what practitioners would need, in order to make their work easier. We also considered what resources non-practitioners might need, so they knew ‘what good looks like’. We did a lot of thinking about the future of something like this. Initially, we were doing this for people inside NHS Digital, but we knew we had the opportunity to open this up to people right across the system, raising standards, creating consistent user experiences, and saving money for local organisations with limited resources.
So often underestimated is the amount of work, and investment, a good design system requires. There had been various attempts to do make frontend libraries, or microsites detailing every component, mostly as side projects by a charitable colleague. But they fall by the wayside when the person who made it becomes too busy, is reassigned, or leaves. A thriving design system needs community management, continuous maintenance, agile thinking to adapt the system’s focus, and ongoing improvement of content, code, accessibility, and so on.
We spoke to our friends at GDS, and also spoke with people from the BBC, to gain their wisdom, and hopefully make sure we did certain things, that others had wish they’d done first time around.
Breaking down silos
One pivotal moment was when we spoke to our colleagues at the NHS Digital Academy. We knew they’d been working on a design system of their own, for designing and building training materials. We wondered whether they might be well ahead of us, and we actually might not need to make something, if we could piggyback on their work. It quickly became apparent that our system-wide vision was probably greater than what they were working on. What I really admired was our colleague Chris Witham’s pragmatic view that they might ultimately retire their resources, if ours gathered traction. I was struck by Chris’s pragmatism, where other people may well have become very protective of the thing they had invested in.
Something that so often holds back real transformation of an organisation, is the protectionism people can exercise, regardless of the visible benefits collaborative work would enable. Sometimes it’s understandable, and there can be unintended consequences of breaking down silos. But in this instance, we had a great example of ‘bigger picture’ thinking. The Academy eventually did adopt the new design system, and even produced an open-source Wordpress theme based on it.
Building the thing
As we were arriving at a solid first iteration of a new design for NHS.UK, the work to actually make that happen across the fragmented digital estate that comprises the website, was going on. This was no mean feat, especially as we were still learning more, and making changes to the design. New, significant areas of the site were still underway, and we had to make the decision to let certain ships sail. Devs were having to work with incomplete or unfinished components, which we knew would have to change later on.
One thing when redesigning a large website (as opposed to just creating a design system), is that it can be hard to fit into an agile approach, unless you have a robust method of altering things that have already been ticked off (which is not something delivery managers or devs are wild about). Once you’ve finished off a card component, it might mean the button design is no longer quite right, and you have to adjust that, which might mean the font size might need tweaking, etc.
Working on a brand new suite of components, colour schemes and measurements, is more akin to starting a sculpture with a big block of marble. You slowly work around it, chipping away at everything. You can’t have a Kanban board with tickets for feet, legs, torso, etc.
So refining the design, when other work was in train, was challenging.
Likewise, the team working on the NHS App were keen to adopt this new design system, and again, we could give them what we had, but had to advise it was all subject to future changes.
Fade to grey
One of the most significant changes we made to the whole site, was the colourscheme. We inverted the site’s header to be NHS blue, rather than white. This was to accommodate more ambitious uses of colour in the future — for campaign sites, or preventative content which could afford to be more ‘lifestyle’. It was unclear at the time what shape those kinds of sites may take, but we didn’t want people to land on a site and not know instantly that this was something endorsed by the NHS, especially on mobile screens.
But by far the biggest change was to make the overall colour of the background a pale grey. It was initially conceived as a way of making content in boxes jump out (if they were white). Most NHS.UK content pages had important information in a box of some kind, and we thought that should have the most standout (rather than, say, a grey box, which may look secondary to the majority of the content).
As we kicked the idea around, we realised that there were accessibility advantages, too. The British Dyslexia Association had published its accessible content guidance, which included the recommendation that content should be presented with dark text on a light (but not white) background.
We hypothesised that most users would not notice the difference, but it would make the content more accessible for those who needed it. We were right — we had been running all our usability testing sessions where all users had access needs of some kind (not just the recommended 1 in 5). We never prompted users to comment, but we would get spontaneous comments during tasks, such as “You know what, this is really good because it’s not too bright.”
So we knew we had a successful design, but here’s the thing: not many people internally liked it. Peers, colleagues, stakeholders… there wasn’t much enthusiasm for this part of the design. We had to deploy all the presentations, haggling, bickering, and more, to convince people.
This was a very stressful period of the project. We’d slowly been building a reputation — the new suites of components were well-received, the blue header felt like a new departure for a ‘digital’ NHS, but the grey background? Nah, mate. Boring. Dull. We would stress to some people the accessibility benefits, while stressing the ‘editorial flexibility’ it afforded us, to others.
To mitigate concerns, we offered an insurance policy, where we could switch it off in the CSS, and reverse the other components, should we need to. But still, there was no getting away from talk about the Grey Background™.
Rebadge it, you fool!
I had an epiphany at one point, around the language everyone was using. I emailed a group of senior people involved with the delivery and implementation of the design, to stop referring to it as the ‘grey background’, and start calling it the Page Tint. My theory was that it made it sound less intimidating and permanent than a grey background. When you are rolling out a grey background to each of the 40,000+ pages on a site with 60 million visitors a month, it can be scary. But adding a page tint? Don’t sweat it, it’s just a tint. You’ll barely notice it.
The worries seemed to reduce overnight. Big changes can be scary, and the language you use to describe them can make all the difference.
Launch!
So in September 2018, the first major overhaul of what we now refer to as the NHS website, was launched. Initial data was very encouraging. Bounce rate reduced significantly, meaning people landing on pages had a better idea of where they were. The next real challenge for the website, would be to improve its information architecture, and the searching experience of the site. But that’s for another blog post.
We had designed the hell out of it. Every pixel was there for a reason. We’d got the typographic scale just so. The basic font size was Very Big (something noted as a positive by author Michael Rosen on a Radio 4 programme). We had a series of content components that felt integrated with pages, rather than feeling stuck on. The buttons had the right amount of buttonyness.
It was also engineered to be extremely lightweight. Engineering is a brand issue, as well as a technical one. Being able to access meningitis content, in an area with sketchy 3G coverage, on an old phone, is an authentic brand experience of a digitally-enabled NHS. Googling ‘chest pains’ and arriving at a page that wastes no time in telling you to call an ambulance, is an authentic brand experience of the NHS.
In many organisations, the brand is owned by a dedicated team, and quite often aligned with marketing. So it can often be a challenge when doing things that embody a brand’s purpose, when they superficially look like they’re being made less interesting. It is also a challenge when trying to convince people who may previously have never thought about brand, to start considering it in their decision making.
Back to sharing
With a successful launch under our belts, we spent the rest of the year building ways of working between the website redesign team, and the team which would eventually produce the service manual. The redesign team had a wiki that documented all the research and design thinking behind each component, and the service manual team started to adapt that to meet the needs they had uncovered during discovery.
The first public release of the service manual and design system happened at the end of 2018. Oh, and a little something called the NHS App also launched.
2019 would be where the real work began…
