Onboarding shouldn’t be an afterthought

Within our own product teams, we have tended to follow a familiar process, scoping out a user need, designing, building and testing an API, getting approvals to get it live because that is what we are good at.

And then – as we head toward that date – we realise we need to consider onboarding. Except that is when we have an experience that is familiar to many developers using our services; we find out that it can take quite a long time to get this right. It would have been worth planning well ahead. This is why our Onboarding process for APIs – NHS Digital is so useful.

We have realised that this is an essential part of building our API products. If we are serious about our vision of the potential for digital technologies to improve health and care services, we need to get every step of that journey right, from designing to testing all the way through to onboarding.

Onboarding, sometimes called assurance, is essential to make sure that products consume our APIs  safely and securely and it makes sense to think about what’s needed during the build process.

As Tony Heap mentioned in his recent blog Making integration easier for people building healthcare software, we identified back in 2019 that developers felt integrating with NHS services can be hard work, and that it is costly for people building healthcare software.

It matters because it raises the barrier to entry, making for a less competitive and responsive market, at a time when we have all seen how responsiveness, particularly when it comes to digital solutions, is critical for NHS services. If you are helping your care provider rapidly deliver digital solutions, you need a clear and unambiguous list of things to do and a timeline to match. 

Challenges identified by our users included overly complex assurance, difficulty in understanding all of the things that you are required to do, and a process that is not necessarily consistent from service to service.

We need to change that.

Our product team is thinking hard about how:

• our onboarding process needs to be as simple as possible
• we should only ask you to do things that are necessary
• we do not compromise clinical safety, privacy or security

This means:

• eliminating obscure processes
• streamlining and standardising our processes
• fully publishing our processes
• making it very clear if something is necessary
• designing services with users at its heart and recognising they are not always technical and/or healthcare experts
• cut down the use of spreadsheets

First stage

Our first version of digitised onboarding was to provide a web page. This was our first Minimum Viable Product (MVP). It described the Supplier Conformance List and was known as the SCAL spreadsheet. This helped facilitate and review the API onboarding process.

It had an immediate impact because the web page answered a lot of their questions. Specialist terms such as SCAL or the Data Security and Protection Toolkit (DSPT) had links to further information or an entry in the glossary of development terms or a link to documentation and standards.

If they did need to ask a question, we make it very clear that they could contact our help and support team who we embedded directly within our onboarding product teams to drive a culture of support.

Second stage

Once we had helped developers to understand what onboarding is and what would be required of them, we needed to make the processes simpler and improve the tooling.

Following user research and consultation with developers and internal service teams, we have progressed digital onboarding to public beta.

This allows developers to:

• create and manage their organisation and product details
• add multiple APIs to their products
• have a single view of all their products and their progress through digital onboarding
• easily review and respond to any required amends
• avoid the inefficiencies of editing spreadsheets and distributing them by email

Come and tell us what you want to see improved when it comes to onboarding as we acknowledge that it is not straightforward.

We love feedback; the more specific the feedback, the better and if you have ideas or suggestions you can use our interactive product backlog to vote for the things you want to see using the tag ‘make onboarding easier’.