Integrating NHS Digital’s new Design System into NHS Jobs Beta
So we all know the benefits to Research, Design and Development of an active and well-maintained Design System (especially across national Public Sector organisations).
Well, not necessarily. For those new to the conversation, consider starting here — we all like to preach to the converted (or is that just me?!).
Where to start? Well, here on NHS Jobs (part of NHSBSA) we decided to be one of the first services outside of NHS Digital to use their new design system. A risky business you might think? Thankfully not! Let’s see why…
Firstly — some context. The design system being used previously at NHSBSA by the digital teams was a hybrid of GOV.UK and NHSBSA patterns and components, which caused challenges in terms of rapid prototyping, consistency and future-proofing.
We’d prototyped an Alpha MVP for NHS Jobs using this old design system, which had passed a GDS Assessment and so Beta development had started.
We wanted our Development team to migrate this Beta front-end over to the NHS Digital design system while our UX Designers also used it to create, test and iterate other areas of the service.
Confused? We were!
Thankfully, we’ve come up with a process to make the transition as smooth as possible. We’re still in the process of working through this, but I wanted to capture our progress now before this post gets too out of hand!
1. Brainstorming.
At NHS Jobs, we like our brainstorming sessions to be lively, creative affairs — just like this (very!) loosely related music video from 1985 entitled (Design) System Addict. Bleeding edge work, I think you’ll agree.
Anyway, back to 2019 (thankfully) — the brainstorming session between our Designers and User Researchers produced the following perceived benefits and process:
— Consistency: taking advantage of the benefits of a maintained design system with an active backlog and wide community of teams and organisations using and extending it;
— Efficiency: rapid prototyping for ideation, hypothesis driven user testing and further iteration.
— More effective and persuasive stakeholder communication — subconsciously an audience trusts a clean, well-designed user interface which means they’ll also be more likely to trust our team’s approach to solving a particular service challenge.
— Scale. Quicker development at scale during Beta because the front-end build library uses the same CSS classes as the NHS Digital prototyping toolkit we’re using during our design sprints.
— Potentially extending the components and patterns with the design system for our colleagues in the wider NHSBSA and NHS Digital communities.
2. Involve wider team and stakeholders
We also involved other stakeholders in this process to understand their needs, for example Dean Vipond at NHS Digital and our Front-end Developers working on the Beta production code for NHS Jobs.
With our Front-end Developers, we agreed the leanest and least confusing way of migrating elements such as html code and css classes over, out for pitfalls which could bloat the somewhat arduous task further.
3. Focus on grids, patterns and components
We decided to use the NHS Digital design system to replicate only key pages of the existing build with layouts, patterns or components not yet featured in the pattern library.
This meant that developers would have access to every HTML and CSS component needed in order to migrate the front-end of the production code over to the new design system (regardless of whether this came as standard from the NHS Digital code, or from this own migration work).
For example, this job advert page from the Alpha MVP:
4. Share the work and check our backlog
The next stage is to feed our ‘candidates’ and testing findings back into the NHSBSA Digital design system (created with love, blood sweat and tears by our tireless Service Design Lead Helen Spires) backlog for discussion and potentially further testing.
The 3 stage process at NHSBSA for this is:
— Sharing the work. Talking about the pattern or component to the NHSBSA Design community is the best place to start, as other service teams might be working on the same thing. Gathering feedback and potentially other examples from this community is the most effective first step.
— Then checking the backlog (see screenshot below). If the pattern or component is already on the backlog, comment and post screenshots of the example.
— Raising a new issue. If the idea has been discussed and is not on the backlog, we raise an issue. It’s important to provide context by explaining why it should be included in our own design system — therefore we include screenshots and research notes.
5. Raise an issue on our own Design System backlog
We add any unique components, or components (used in a context not yet considered by the pattern library) onto the NHSBSA design system backlog.
If a standard component (such as an NHS Jobs header) or a non-standard component, pattern or unique context is tested and approved, then an NHSBSA Front-end Developer will build our ‘quick and dirty’ prototype component with more elegant and secure code.
These may naturally includes elements from the GOV.UKdesign system such as the character count component which need to be modified (usually visually, less so functionally).
We‘re not reinventing the wheel and duplicating the hard work already done on either the GOV.UK or NHS Digital Design systems. It’s about catering for the task context of NHS Jobs users.
6. Create some internal guidelines
It’s become clear from this process that we need some brief internal guidelines and examples to help the NHS Jobs team maintain visual consistency.
For example, defining how to use different heading styles across different contexts — for example transactional tasks versus summaries of information — for the most efficient visual hierarchy.
This was needed because we found that using too many variants of the core NHS font ‘Frutiger’ increased cognitive load, which is detrimental to users’ content comprehension and task completion rates.
7. Contribute to the community
Finally, we’re also working with our colleagues at NHS Digital to share and discuss any patterns/components/findings we’re working on.
They may decide to include some of our components and patterns within the NHS Design System for use across the NHS. Then in turn, some of these backlog items might then be added to the GOV.UK Working Group backlog for use across multiple Government organisations.
Therefore, we’re keen to solidify and improve the feedback loop between ourselves, NHS Digital and the GOV.UK Design System team.
What’s next?
No doubt the experienced reader has noticed that this article is more descriptive than analytical in nature. This is because we’re still in the early days of this process, and so I may write another piece covering lessons learnt.
For now, we’ll keep sharing the NHS Jobs team’s common solutions to common problems to this ever-growing community in order to to help other services create consistent, recognisable (and reassuring) designs which build at scale quickly while having the flexibity to meet their own public service-specific needs. Sounds like a win to me!
If you want to know more about Design Systems, here’s some reading— from lighter articles to ‘get down and dirty’ guides to building your own!
Further Design System reading:
Lighter reads —
Top 20 Design Systems
Design Systems (by Figma)
Six lessons learned by creating a design system at a fast-moving start-up
When your Design System fails
In depth —
Design Systems (a ‘Smashing’ book)
Atomic Design (Brad Frost et al, based on https://patternlab.io/ principles)
List of Design System Books
