The NHS digital service manual needs you

Following one of our design principles ‘Make things open. It makes things better’, we intend to work in the open so that:

• people understand how we make decisions about what to include in the service manual and why

• they can find out what we're working on or are planning soon by looking at our ‘backlogs’ of future work

• teams across NHS Digital and the wider health and social care sector can join conversations and share their user research insights with us

By doing this, we will improve the service manual – and the digital services we build.

There’s a long tradition of collaborating on code in the open but we think there are other benefits to opening up our work more widely. By having all the different parts of the service manual (development, design and content style) open in this way, we can also:

• bring our contribution and development processes for different activities into line with each other

• link between issues in our different backlogs – because design, development, and content need to work together (in care card components, for example)

We manage the service manual website on GitHub. If you don’t know GitHub, it’s a free tool traditionally used in software development as a way of storing, managing and tracking changes to code. It is particularly good at allowing large or remote teams to collaborate at the same time. Repositories on GitHub can be public (everyone can see them) or private (you need a password to access them). As well as working together on code, GitHub lets us share our backlogs of future work. It also lets other NHS teams use the NHS.UK code to build their own projects. 

Our colleagues at GOV.UK Design System pioneered working in the open on GitHub a year ago. They explored many collaborative tools, like Google Docs and Dropbox Paper, but found that they couldn’t be used by departments with security restrictions.

We’ve followed their lead in using GitHub and are benefiting from opening up too.   

The coding and design community supporting the NHS website is already really active.  

There are more than 70 public GitHub ‘projects’ building on the service manual code, be it for local trusts or national NHS organisations like NHSX. These numbers mean that across the country people are using our stuff, building things in different contexts and testing with different types of users. That insight helps the manual grow and improve, helping all of the digital teams using it.  

People log issues in GitHub, have conversations and share their own experiences and insight. One recent example is a proposal for a new patient details header component that was raised in GitHub. One NHS Digital team detailed what their problem was, how they had worked on it and their user research evidence. Someone in another NHS Digital team talked about his team’s work and user testing patient details headers. Someone else from an NHS trust shared what she had learnt. This is a perfect example of teams across the country being open, asking for feedback and helping each other. One of them commented:

We’ve gone one step further than the GOV.UK Design System and have started to use GitHub to manage changes to our guidance on writing content for digital services,  So what does this mean in practice? Here’s the content style guide backlog. It allows everybody to see words or phrases or other issues that people using the service manual content style guide have been proposing.

For example: Do users understand and look for information about “PMS” or is “premenstrual syndrome” clearer? (If you’ve got evidence from your users, please let us know.)

We’ve also got some more thorny issues in there, such as something we’ve been calling the “pain scale” for short, which is actually about helping people know whether or not their pain is severe enough to get urgent or emergency care. 

Issues in the content style guide backlog are managed by our content ‘Style Council’ - which meets monthly to review submissions and conversations, consider the evidence and ultimately publish them on the manual. 

By using GitHub to manage our content backhub, we know we are taking this tool beyond its core user base among coders and developers and we appreciate that there might be learning curve for people who aren’t familiar with this way of working. But we feel the benefits are worth the effort. We are keen to help people get involved, starting with our content design community. We’re offering content designers some initial handholding to get them started in GitHub. One of our senior designers is going to run a course to help them improve their HTML and CSS coding skills. And later this year we’re planning on training content designers to work directly in code in GitHub. 

A community is about people and the more minds with different perspectives we have supporting the service manual, the better. If you’re working in user-centred design in health, testing regularly with users, please get involved, ask questions, share knowledge – and help us build world-class digital services.  

We’re particularly interested in user insight, user research or analytics, and in filling gaps that we have in the service manual.