We have detected that you are using Internet Explorer to visit this website. Internet Explorer is now being phased out by Microsoft. As a result, NHS Digital no longer supports any version of Internet Explorer for our web-based products, as it involves considerable extra effort and expense, which cannot be justified from public funds. Some features on this site will not work. You should use a modern browser such as Edge, Chrome, Firefox, or Safari. If you have difficulty installing or accessing a different browser, contact your IT support team.
Demystifying the integration process for the NHS App
James Reith, Content Designer for the NHS App, explains how the NHS App integration team have improved their integration process to make it easier for partner services to innovate.
19 November 2020
A key principle of the NHS App is that it should be open to new ideas from a variety of sources. As Matthew Gould, NHSX Chief Executive, put it, we “create the right platform and let others innovate on it”.
But making that vision a practical reality for partners, while not undermining the usability of the app, requires a predictable, clear and user-centred integration process for partner services.
Initial attempts to integrate NHS partner services drew on a mix of overlapping, pre-existing NHS processes – for security, information governance and so on – as well as some tactical improvisation.
Getting the first partner service live had proved complex and had taken longer than expected. Something wasn’t working. We needed to find out what, and how to make it better.
Crucially, all of it assumed partners already wanted to integrate with the NHS App. Nowhere did we tell partners the benefit of doing so.
Learning from similar processes
Our team was created to design an integration process for the NHS App, using the same user-centred methodology that underpinned the app itself.
However, we were not the first product integration team at NHS Digital. We worked particularly closely with the NHS login integration team, who have been going for 2 years. Their users overlap substantially with ours, so their experience and user research gave us a solid foundation to build on. Most app integrations require NHS login too, so we’re still collaborating and learning from each other.
Mapping what we had
All our internal stakeholders had a slightly different idea of what the existing process was. By mapping it out, and getting agreement on it, we could break the component steps down, isolate problems and recognise opportunities. Most importantly, however, it meant we could then discuss the existing process in concrete terms with our users.
Identifying gaps and assumptions
We critically reviewed what information was publicly available for NHS partners. There wasn’t much. Most of it came from partner events, so could not be found online. And, crucially, all of it assumed partners already wanted to integrate with the NHS App. Nowhere did we tell partners the benefits of doing so.
Designers often make a crude distinction between users and stakeholders. But our stakeholders are users too.
Interviewing NHS partners
User-centred design is not just about usability. At root, you need to be addressing user needs.
So we mocked up a low-res wireframe providing an overview of the existing, semi-structured process. We then spoke with representatives from 6 NHS partners, using the wireframe as research stimulus.
If they were considering integrating, we wanted to know who needed what and when.
Broadly, we found that partners wouldn’t commit to integrating because they had no idea:
how difficult it would be
how it would benefit them
if they’d have to repeat steps from other NHS processes
We also found that specific user types – chief executives, project managers, technical officers – needed different information before they could consider integrating.
From these interviews, we started to create a content strategy for our integration process.
Broadening our user base
True innovation can come from anywhere, so a guiding aim for us was to demystify the NHS App integration process.
Integration is also a collaboration between the partner and the NHS. Designers often make a crude distinction between users and stakeholders. But our stakeholders are users too. Both need to have the right information, at the right time, for the collaboration to work. Otherwise they will become obstacles to each other.
Reordering the steps of a process can prevent showstopping surprises later on. We do not want partners to build until we’ve made a firm commitment to them. And we do not want to spend time integrating a product or service, only to find it doesn’t yet meet our standards. So we now ask about data handling right at the start. And subject all products and services to a comprehensive usability and data assessment.
Testing, testing, testing
Service design is one of the most important, but least tangible, design disciplines. It manifests in the output of others. Testing an end-to-end service before it goes live is difficult. You can only really simulate part of it. Our NHS App for partners and developers webpages represents our collective work.
Our aim was to test if information on the webpages was clear and could be found.
We conducted 9 remote usability testing sessions with users from a range of roles – chief executives, product managers and developers – all of whom needed something from these webpages.
An early iteration attempted to lump everything together into a single timeline. Users hated it.
In their minds, they made a clear distinction between:
documents to fill in
the integration process itself
It took 3 further iterations to regroup the information so the different user types knew where to look.
Illustrating: an accessibility issue
Although making things more accessible tends to benefit everyone, there can be tensions in meeting different access needs. Dyslexic users, for instance, can benefit from diagrams and images, but making diagrams and images integral to your content creates a barrier for users of screen readers or with low vision.
Almost every user we spoke with wanted a process diagram. The need is to understand the process; a diagram is just one way of doing that. We resisted, at first. After 3 text-only iterations, we arrived at a design that was clear for people who read it. But partners who were familiar with other NHS integration processes still wanted an ‘at a glance’ version.
So we have a diagram. It simply summarises our final text-only design. We’ve followed gov.uk guidance to make the process diagram as accessible as possible. If you use a screen reader or have low vision, and work in healthtech, we’d love your feedback.
What happens next
Design is never done. We’ll keep iterating on the process, based on feedback from our users.
We will also be introducing new NHS App features for partners to use, such as push notifications and messaging.