top of page
Top
DL - Logo.png

A digital healthcare platform designed to empower

patients to take greater control of their health
and enable them to gain access to the right care

at the right time.

Screen Shot 2019-04-08 at 11.30.51.png

DoctorLink servers as a platform for the NHS (GP, Pharmacies) and patients,  the objective of the app to improve the availability of personnel, save time and cost to both the practices as well as the patients.

 

The services require registration, login details, and offers a list of functionalities such as check symptoms, book appointments, repeat prescription and check other services nearby.

 

In order to use the Doctorlink app a patient needs to be registered at a GP database. only then patient and security authentication will happen.

Introduction

Patient's data protection is very important to the health industry, at Doctorlink there was the awareness that not every GP uses a standard system for their patient's history.

So far DoctorLink was dealing with GPs that use the same database system which was straight forward, each time a user logs in to the app an API call is set to check the patients records against the GP records.

 

Doctorlink has managed to engage with a list of GPs that are using Emis system. It was important to set that connection right from the start. What I could not understand is why this was not part of the MVP list until a deadline was set of 2 weeks live. 

 

 

The brief 

DoctorLink application needs to connect to the main clinical system Emis, this is used by 30% of GP practices in the UK in order to keep patients medical history. 

Emis' patients need to have a registration letter and Registration key number to be able to register on the app otherwise, the patient can access the app only once and become OSU

(online service user) once the patient has provided all the details it becomes a ROSU (Registered online service user). The objective was to ask for those two extra details somewhere in the user journey. 

 

Patient authentication

Overview

The approach

Discovery

I requested a quick meeting with the architect at DoctorLink who has knowledge about the Amis system.  I understood the why but I needed to know the boundaries to be able to see the options for what, how and when. I prepared a list of questions such as  

 

  • What is the registration journey at the GP 

  • What is manual VS automated 

  • Could connect through an API?   No

  • Could we automate the registration and get the registrations key sent to us?  No

  • Are there reports? Yes, but too complex

  • Could we export data? No

  • Could the registration keys be sent to the patient by email with a reminder link to the app? No

 

The above gave me an indication of how little user was considered, in my mind the user should not know what is happening behind the scenes and both registrations the GP as well as DoctorLink app should be smooth. however, this was more the case of business growth with other GPs using the DoctorLink service.

I also figured that they were not willing to negotiate with another party Emis to create an API, I wondered how many other databases we will need to have access to, so we could prepare in advance. Why are fire fighting here putting patches in the system, we should have a strong team compliance team taking care of APIs access and setting up agreements with GPs. then the user would not be affected in fact no one.

 

Brainstorming 

I invited various members of the team from a Designer, tester, PM and Engineers I thought this would be a good variety of skills to help flag out most of the challenges we could encounter on the development.

With all the knowledge collected I simplified the case and presented the team all the blockers, we had to set boundaries and safe time. I was hoping this will set our creativity by looking inside the box.

 

So the workshop was set as follows:

 

  • 2 mins workshop's goal

  • 8 mins Challenge introduction

  • 5 minutes Blockers 

  • 1 minute, Crazy 8 to highlight the potential blockers

  • 1 minute, crazy 8 for potential benefits 

  • 8 minutes for sketches of the ideal flow

  • 2 minutes per person to present a sketch

  • I took the patterns identified in the presentations

​

​

 

 

Results 

As expected the user flow would be affected making it longer, added friction and perhaps losing patients on registration.  

The blocker's list was a long covering from the technical side to the user experience, lastly, the benefit's list was mainly supporting the business side.

 

We identified 4 stories which helped us create user journeys and ensure we were all on the same path and right track.

 

Scenarios

1. First time user

2. A registered but forgot latter

3. A registered but lost latter

4. Not registered

​

 

Decision

I looked at the initial user journey below to see at which point we should ask for the extra details, also taking into consideration the scenarios above, I suggested we could ask in two places of the journey based on various parameters. 

 

 

User journey

Screen Shot 2019-04-08 at 17.09.40.png

For the above journeys, I needed to consider a happy path and an unhappy path, I also needed to highlight that this would take more than a week to be developed as testing was needed too and this was already my second day. I made sure I kept the stakeholder updated to manage the expectations.  

 

 

New user journey 

Screen Shot 2019-04-08 at 18.41.20.png

As shown above, there is an extra step on capturing the GP registration details right after the registration, however for those who wish to continue straight and do their check symptoms the details will be asked when booking an appointment, to confirm the above we run a test.

Prototyping

To have more clarity, I requested a design critique session with the team of the new registration journey, the design critique is probably one of my favorites stages of the design process as I get to see others points of view and understand different perspectives also because one idea suddenly becomes 5 times better. after the session, I had another round of improvements and the prototype was ready for the real users to test.

Screen Shot 2019-04-08 at 19.27.39.png

Usability Testing

 

To test our assumptions and improve the design even further,  together with the research team we put a list of prototypes we wanted our invited users to test. A script was prepared with the 4 scenarios both successful and unsuccessful in order to get feedback and observe users, my main interest was to see if the registration process was going to be a blocker for the users.

 

  • How was the journey?

  • What did they think of the extra information requested?

  • Would they come back if they didn't have the initial details in hand?

  • Would they prefer to be asked at the beginning of the journey or at the end?

  • How could they trust us?

 

We had invited 6 participants each an hour, each session we took them through the scenarios made observations, we also recorded them with their consent of course and took notes additionality. 

 

​

Analysis

Once we had completed the testing session, we then listed on the board all the areas we wanted the focus on, in this scenario 'Registration' was one of them. we grouped quality levels as good, medium, and poor and used colors stickers with the comment made by the user and place them on the board as shown below 

 

Registration for Emis GPs

IMG_20190301_145251.jpg

Insights

  • Good news, since this service is linked to the NHS people's mindset has set an expectation about personal details will be requested.

  • Having the logo on the app was a big winner as people immediately felt encouraged to enter their details with no hesitation however there was inconsistency the logo was only at the beginning of the journey and if not observant enough people would feel hesitant to continue with the app.

  • Users preferred the details to be asked at the beginning of the journey as this, so they can focus on other areas of the service.

  • Audience age was very interesting to see that the younger the users the faster and careless about content they were, older users had taken time to read instructions and understand what was asked and why they gave really good feedback on content as well as the product overall.

  • The journey was longer, however for a few minutes (1/2) as long as the use had all in hand

  • Some people did not trust at all and rather call the GP as they felt uncomfortable interacting with a machine to  

  • Some people get disengaged by all the information asked at once and felt the service was not as efficient as they hoped.

Design Solution

Simplify the journey by asking for the information at the beginning as most of the users suggested. 

I was aware of the deadline and didn't want to hold any longer the rest of the project, therefore I made final changes to the prototype and presented the final to rest of the team. Approval was given and development took place.

 

However, this was not my final result as I felt this new extra step would be a blocker for potential new users and onboarding would drop, I kept a close look at the analytics to see before and after to continue persuading for a better solution as there were more options such as:

​

 

  • Fast registration

  • Magic link

  • API Call to Emis database

 

bottom of page