Skip to main content
Blog

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.
James Reith working from home.

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 things

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.


Preventing hidden surprises

“Radical transparency” was a guiding principle for us. For partners to make an informed decision, and plan their workload, they need to know what is expected of them.

Not every partner, for instance, has an in-house lawyer to go over agreements and contracts. We worked with various NHS stakeholders to surface examples of documents that are usually hidden until mid-way through an integration. This helps partners to make informed decisions and plan their workload.

We often think of design as creating but, to quote design theorist Cameron Tonkinwise, “most of designing is actually arguing”. The best design meets a need, and sometimes that’s just convincing someone to show what you already have.


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.


Mental models

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
  • developer resources
  • 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.

If you’re someone in healthtech who’d like to be part of the NHS App, but finds the process intimidating, send your feedback to [email protected]

Learn more about the integration process and our plans and priorities for the NHS App going forward.


Author

Last edited: 24 April 2024 8:52 am