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.
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.
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.
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.
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).
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.
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.
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).
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.
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.
Once we'd analysed research we created some problem statements to help us focus our effort.
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.
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.
Our team explored some initial ideas. We used iconography as a visual anchor.
We researched to see if the information on the page was helpful for users.
I re-ordered the information hierarchy and began to spec out all use cases.
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).
I took the sketches and created a few wireframes to take out to pop-up research we had planned.
We refined the visual design and began to think about how our use of colour can convey different statuses.
We iterated the use of colour to be clearer and renamed rename the level 'low' to 'basic'.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The final piece of our research puzzle was to get the product researched by specialists at the Digital Accessibility Centre based in Swansea, Wales.
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.
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.
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.
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).