Redesigning the front door

NHS Digital

Taking a registration flow back to first principles. Redesigning how a user registers for NHS login, a secure way for users to manage their health online.

Reading time

8 minutes

Time

3 months

Role

UX designer

Giving 25 million people a secure way to manage their healthcare

Overview

An emergent trend in healthcare is empowering users to take control of their health. Digital communication has served as one of the primary ways to achieve this, reducing burden on strained front-line services.

NHS login

For a user to take greater control over their health, they need access to their healthcare records and data. A high level of trust is needed that the user is who they say they are before they can access their records, which is where NHS login comes in.

You can think of NHS login as the healthcare-equivalent of a Google or Facebook single-sign-on (SSO), which can be used across a lot of different healthcare services.

Business goal

We needed an improved registration flow experience for NHS login. Partner services such as the NHS App were receiving poor app-store ratings due to the sign-up process.

Outcomes

  • Significantly improved accessibility to WCAG AA rating
  • Improved team understanding of the users experience
  • Reduced journey time by 40%
  • Improved conversion by 5.2% (to 95.6%)

NHS login

NHS login is an identity authenticator service. It checks who the user says who they are.

The goal of creating an NHS login is a single re-usable account across multiple digital healthcare services, such as the NHS App, EMIS, or Ask NHS.

The problem

Looking at the analytics

One of my core responsibilities was to focus on the registration flow - how a user signs up, before they need to prove who they are.

When I joined the project, we were already in private-beta. Shortly after I joined, I sat down with our team to take stock of how the product was performing, and looked at some of the metrics available to us.

Improving the conversion which would have compounding effects on the rest of the service (if we can address a bigger chunk of drop-out here, it will have even larger knock-on effects later in the journey). The proportion of users who confirm their account (a successful registration journey) is directly related to the proportion of users who verify their ID (a successful final journey).

In private beta:

150k

Weekly registrations

88%

Existing conversion rate

0.4%

Increase in conversion (annual)

95%

Target conversion rate

Existing
pain points

Identifying the pain points

Analytics only painted an overview of how the product was performing. To really understand how we could improve the experience, we needed to look at the research. Looking into research showed the following problems.

do you have an NHS login screenmid-registration login screen

1.

Unneccessary cognitive load

The flow begins by asking a user 'do you have an NHS login?'. We know from user research that NHS login isn't well understood as a concept, so putting the burden on the user straight away to self-report whether they have one leads to inevitable errors and frustration.

We also identified causes of friction from unnecessary pages in the journey. For example, the user has to log in mid-way through the registration journey - despite having only just entered their email and password, but before linking their phone number. Pretty confusing.

2.

Green button syndrome

Some users enter a flow state when moving through the product, clicking green buttons without reading the content. Usually this can be avoided with an element that requires intentional action to progress, such as an input field.

But the 'check your email' page causes multiple problems as users don't read the content and instead click the green button, without having confirmed their email.

At this point, they are prompted to enter their login details and see an error, causing drop-off and frustration. A unique constraint is we can't dead-end a user, we need to provide a way to continue the journey. This is because NHS login is used in the context of it's partner services, for example the in-app NHS App browser (due to security requirements).

3.

Inaccessible design

We knew from research with visually impaired users that the current username, password + confirm password page isn’t very accessible.

This is due to too many field inputs on one page. If a users enters one field incorrectly, multiple fields present on the page makes it difficult for them to correct their error.

For a user with a cognitive impairment, inputting so many things on one page can be a tiring and confusing experience. It would work better for all users if this page was broken down.

We also know users can become frustrated when registering that they can’t see the password they have entered, resulting in an increased rate of errors.

4.

No preparation for onwards journey

The registration process wasn't the final step in the users journey, they needed to continue and prove their identity. This involves taking a selfie, a video selfie and a photo of their ID for it to be matched to.

Users only found out they needed to do that during their journey, causing a significant amount of frustration. Not every user had the time or appropriate social-setting to take a photo of themselves, nevermind a video.

There's an inherent level of complexity and preparation (having the necessary documents ready) needed that we need to help users with.

User journey map

I created a user journey map to collate all the great insights we had floating around, centering us on one shared problem space.

User flow

I mapped all user journeys through the login and registration flow, and created a 'to-be' future state, to reflect the end goal. This was a great resource when communicating my early ideas to the team and developers.

Problem
statements

Once we'd analysed research we created some problem statements to help us focus our effort.

How might we create a seamless
sign-up process?

How might we prepare a user for their onward journey?

Good
registration
principles

Great user experience

Ultimately, it needs to be easy. This is true for all products, but particularly for NHS login given the user has tasks to complete after registration. The registration needs to be designed to be used by anyone who uses the NHS - the vast majority of the british public.

Solid security

NHS login exists to give access to and protect its users healthcare information. We require two-factor authentication building a sign-in mechanism opens up service to agents who may act with malicious intent. This is number 1 principle. Federated login platform is a gateway to other applications so if account is hacked (NHS login) then multiple other accounts could be jeopardised

Good partner and developer experience

This will be used in context of partner-services and needs to be well-documented and developer-friendly for those without the domain knowledge we have.

Wireframe

Our team explored some initial ideas. We used iconography as a visual anchor.

Mockup

We researched to see if the information on the page was helpful for users.

Iteration

I re-ordered the information hierarchy and began to spec out all use cases.

Managing expectations

The service needed to prepare users for what to expect. We knew from research that when a user got to the step they needed to take a photo of their I.D. they didn't always have it to hand. This frustration was confirmed by a high drop-off rate (the second highest in the service).

We designed different variations of this page based on whether the user was going through the full or a user journey which required a lower level of authentication (see below).

Wireframe

I took the sketches and created a few wireframes to take out to pop-up research we had planned.

Mockup

We refined the visual design and began to think about how our use of colour can convey different statuses.

Iteration

We iterated the use of colour to be clearer and renamed rename the level 'low' to 'basic'.

Security levels

We needed to match a users mental model about how they think of their accounts security. Because NHS login is designed to be reused across different healthcare services, who each need a different level of account security, we needed to communicate to a user why some services sometimes asked for more information.

We created the concept of security 'levels' which explained the users current level, the level they needed to use the service they were signing up for, with information about why it was needed.

The
design
process

Early team involvement

I began by holding an ideation workshop with my team, thinking of as many ideas as possible. We time-boxed myself and did crazy 8's until I had a stack of ideas to think about.

After that, I refined the ideas and used them to create a series of user flows. Once I had a few user flows I discussed with the developers to see if the ideas were feasible.

Design crits

After chatting with the devs I picked the flows that ones made the most sense and jumped straight into VS Code to begin prototyping, using the NHS.UK design system.

Once I had some flows designed, I opened up the ideas to more of a formal critique, inviting the programme (not just designers) to share their thoughts on my ideas as I clicked through a prototype.

Doing the hard work

We stopped the reliance on users self-reporting whether they had an NHS login or not.

Instead, we ask the user for their email address and perform a look-up based to see if they have one or not. Based on the result, we display password entry screens to either log-in or to create an NHS login.

Guidance for onward journeys

A lot of users became frustrated when they were asked to provide photo ID to prove who they are, due to the lack of up-front information.

We know users scanned the information in registration, so we added a simple illustration to provide a visual anchor to slow the users down.

Improved form logic

Central to any transactional service are forms and input fields. The existing input fields handled errors incorrectly and were misleading.

We focused our efforts on error prevention. We reduced the chance of error, such as through the show password feature.

In times when that wasn't enough, we worked on providing users helpful and concise error messages.

Increased friction, when needed

A registration flow needs to be seamless. But one action that a user needs to take is to confirm their email.

A lot of users don't do this, and see an error on the following page (log in).

As well as removing the log in page, we added a lookup to check if the user had confirmed their email when they pressed continue. If they hadn't, we would display a screen with a checkbox which when selected, enables the button.

Back to
research

Pop-up research

We quickly got feedback on the designs to validate our assumptions. We spent a day at Leeds University and Leeds City Council One Stop, speaking to 25+ users. The mix of users we had was great, with 4 users where English was a second language, and 2 cognitively impaired users.

Usability testing

Once we had confidence in our assumptions and designs we booked a round of usability testing. Context was key here, we wanted to examine how the registration flow worked in the end-to-end experience. The insights we gathered began to firm-up some possible problems we had an inkling about in pop-up research, mostly relating to the 'what you need' preparation page.

Accessibility audit

The final piece of our research puzzle was to get the product researched by specialists at the Digital Accessibility Centre based in Swansea, Wales.

53

Users spoken to

27%

Reduction in errors

20%

Reduction in completion time

4

Users with English as a second language

Iterations

Adding in 'just enough' friction

We noticed some users still had what I referred to earlier as 'green-button syndrome'. A small proportion of users chose to select continue without checking their email.

Knowing this was a problem, we tested adding some intentional friction in the journey. We ran a look-up to see if the user had confirmed their email, if they hadn't - we displayed a screen with a tickbox and disabled button which became enabled when the tickbox was selected.

Influencing business decisions

We used our research findings to help the business pivot away from highly-confusing information about needing GP registration details to prove their identity.

This was a difficult task. Using GP registration details has no cost-per-transaction, whereas its alternative (photo I.D. and face scan) did.

This was probably one of the best victories the design team had, resulting in a conversion improvement of 8% and a marked reduction in confusion from users.

Working with
developers

When developing the prototypes, we introduced something called 'DevMode'. This is a toggle which developers or researchers can toggle on / off to view different error messages and non-happy path user journeys.

As well as the initial involvement in designing the solution, we found it helped massively bridging the gap between design and development when it came to handoff. This is something we contributed back to the wider gov.uk and nhs.uk design community.

I've put the example on Codepen.

Final
reflections

This project was one of the best experiences I've had as a designer.

I learned a bunch about collaborating effectively with different team members in a tight timeframe. The complexity of what we were trying to achieve took my technical knowledge to a next level - and communicating that knowledge to different team members helped to cement how I translate my ideas from pixels into words.

It was nice to delve into the analytics and marry those insights up with the user research we had, which I felt helped to tell a really compelling story of the product to stakeholders (and hopefully to you too).