How remote user research helped us to build a patient-initiated messaging platform in just 6 weeks

‍

Hi! My name is Alice, and I’m a User Researcher at accuRx. I joined the company in April 2020, and  was one of the first to be onboarded remotely due to COVID-19, which was definitely a unique experience as far as starting a new job goes! This post covers my first full cycle of user research at accuRx and how it facilitated the development of Patient Triage - a way for patients to contact their GP practice online.

The initial problem

With the outbreak of COVID-19, GP practices have had to shut their doors for the safety of staff and patients alike. Even at the best of times, patients experience difficulty contacting their practice: phone wait times can be long and there are often no other easy alternatives for getting in touch. With our messaging product Chain in 90% of practices at the time, and practices pushing to do more online, we rolled up our sleeves and looked at what we could do to help...

Some questions we had

To design a good online solution, we felt we needed to answer these questions:

• What existing ways do patients initiate communication with their practice?
• What are the problems / pain points with these channels?
• What are the basic needs from both the practice and patient’s perspective?
• What do patients need to get in touch about?

How and why patients get in touch

We conducted some initial exploratory interviews with our GP practice users. We learnt that existing ways patients could get in touch largely fell into three buckets with specific pain points for each:

• Phone - slow, frustrating, not flexible, sometimes uncomfortable if sensitive conversation for patients, have to call up early in the morning to get an appointment.
• Practice email - not linked/saved to the patient’s medical record.
• Practice website/online platforms - often clunky or inaccessible, don’t always capture information needed by the practice to respond effectively.

This is some of the feedback we heard from practices and patients….

“Online forms to contact your GP practice often ask too many questions, which means that we end up with lots of information we don’t need from the patient...”

“I get a bit embarrassed, telling receptionists about my symptoms when I ring up…”

Types of communication largely fell into two categories: clinical queries i.e. wanting a GP response to non-urgent symptoms and administrative queries which had clear categories: fit note requests,repeat prescriptions, queries about test results or referrals, and ‘to whom it may concern’ doctor’s letters..  

“We need a way for patients to report medical symptoms and also make other queries for reception staff such as having a form filled out or a repeat prescription issued.”

Testing low-fidelity mockups

After initial interviews we created some low fidelity mockups (using a prototyping tool called Figma) of an online platform where a patient could get in touch about medical concerns or an administrative query.

‍

We tested with both clinical and administrative staff, and then iterated on designs based on feedback and what the core user needs were:

• A way to triage inbound comms to the most appropriate team member
• To capture enough adequate information for staff to respond
• To avoid overwhelming the practice with inbound messages
• To save inbound comms back to the patient record
• A way of safety-netting patients who present with red flag symptoms (e.g. chest pain)

“We’d love it if there was a button that meant you wouldn’t have to copy and paste the information over when the patient sends it in - you could just click the button and it would automatically be put on the patient’s record for the appropriate member of staff to look at.”

Patient research

After starting out with some exploratory interviews with patients, we also ran a series of task-based semi-moderated testing sessions with patients from a range of backgrounds. This is essentially asking patients to complete a series of tasks using the system so that we could check that it was user-friendly, and find out if there were any pain points in their user journey. An example of a task we set was: ‘You have had back pain for the last 2 weeks. Please use the system to request a fit note’.

From the research, we discovered that patients were very keen on an online method of contacting their practice so that they could have more flexibility around how they can get in touch. They also wanted to be able to have some queries resolved without an appointment with a doctor (such as ordering repeat prescriptions and chasing up referrals) in a quick, easy and accessible way.

“I need to be able to request a phone call or digital response from a doctor as I’m at work a lot of the time, and it’s really inconvenient for me to have to take time off work to sit in the surgery and be seen that way.”

In terms of the usability testing, patients generally liked the mockups and said they would use it. All tasks were completed in 5 minutes on average, and each user’s speed dramatically increased after the first task, as they became more familiar with the platform.

Beta launch

For our initial release, we released a form-based system that deals with both clinical and administrative requests. This allows patients to get in contact without having to call.
‍

‍

It would be easy to fall into a trap of adding everything users say they wanted, but for the first release of the product, we focused on  simplifying the patient experience as much as possible. We released the product as a ‘beta’ to 9 practices to start with so that we could closely monitor how the patients were actually using the forms. This has also been helpful so far in gathering information from the practice about how they want to triage the incoming requests.

Basic features of the beta released version included:

• A clinical flow for medical queries.
• An admin flow for non-medical queries (fit notes, questions about referrals, doctor’s letters).
• A red flags page up-front where patients must confirm that they are not having symptoms that require urgent medical assistance.
• Fields to enter demographic data such as name, date of birth, phone number along with 2 factor authentication so practices can identify the identity of the patient..

We aimed to keep it as simple and short as possible, whilst still capturing the necessary information for the practice.

Reflections  

I really loved doing the usability testing with patients. It was much more engaging to watch them use the software on-screen rather than just ask questions about it, see what pain points they identified, and what they found easy.

It’s tricky finding a balance between creating a system that is so easy patients will use it for perhaps trivial things, and creating one that is so long that patients will rarely use it and just ring the practice instead. Preliminary research with GP practice staff and patients suggests we’ve got a good balance, but this is something we will continue to evaluate.

Looking back, it may have been useful to spend more time with admin staff exploring how they manage incoming communications from patients. This would have helped us determine sooner what requests were feasible and important to offer as part of the beta.

Overall, my team has achieved so much in the last six weeks, and it’s been so exciting to be a part of creating a new product that we hope will make things so much easier for patients and GP practices alike. The most amazing part is I’ve never met any of them in person due to remote working - but we did it!