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.

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.

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.

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:

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.

“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.

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.

An early iteration attempted to lump everything together into a single timeline. Users hated it.

In their minds, they made a clear distinction between:

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.

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.