The Patient Facing Scheduler

INTRODUCTION

Whilst creating PACO: The Patient and Care Optimiser, I had created 4 main modules. These were:

  1. Analytics – The module to give practices data to make meaningful change, see capacity and demand, and analyse patients and medication use in their practices.
  2. Comms Hub – The key to connecting patients and their practices. This module allows practices to send preselected lists from the analytics module to Comms Hub, and communicate with these patient cohorts via sms and/or email with only a single click.
  3. Patient Facing Scheduler – The first patient facing module in the PACO family, this application allows the user to book appointments sent to them by clinicians (via Comms Hub) to free up practice phone lines, reduce DNAs and reduce the average time for booking a patient into appointments.
  4. Virtual Consult – this module is the final goal along the user journey with PACO. The Virtual consult module uses web chat and video consultations to increase access to patients and allow those hard to reach cohorts the chance to keep up with clinical appointments without leaving their home.

This case study will follow the work carried out to create the scheduler application.

ROLE

Lead UX/UI Designer

Solo designer on this project, taking the design from initial screen sketches after stakeholder meetings and requirement gathering, to the final prototype.

If at first you don’t succeed, try, try again.

As outlined a few times in my portfolio, I’ve been the head of UX at Blinx solutions and worked primarily as the sole designer on most of PACO. The only module I was not involved in to begin with was the Scheduler application. This was done by some junior designers who were with the company at the time, but unfortunately missed the mark and top stakeholders with PACO were not pleased with the results.

This being the case, I decided to step into the project and review this for what it was. A solution to speed up scheduling and make ease of access for patients. So my first approach was to look at a mobile application rather than desktop web app like what had previously designed.

I began by reviewing applications like the NHS app for more close to home examples, as well as applications outside of this market like Hole19, or MyFitness Pal for inspiration on displaying analytical data and for a crisp mobile navigation.

Initial screen sketches

As mentioned before the scheduler application had been partly designed earlier, albeit in the wrong direction – but I was able to use some of the research that had gone into this and pull the required features from this into my app. All that was required for MVP was to allow a user to receive an appointment invite, for that patient to then be able to schedule based on their own time and clinician preferences and finally to be able to choose between which appointment type they’d use (face to face, video, web chat, phone etc).

While looking at other apps in the market I felt that the application had more legs and could potentially be a source of analytical data for a patient that they otherwise wouldn’t know existed. Using the EMIS extract we have access to all different data types which led me to design pages like an ‘attended vs DNA’ chart, calculate which drs they see most often and finally, which prescriptions they have.

Below you will see some screen sketches for the appointment booking flow. I tried to keep this as simple as possible with as few steps as possible to avoid too many clicks. You’ll also notice the clinical feel of my design (even at this early stage) to match that of the NHS. This is to build trust in the application for the user. I took elements of navigation styling from the hole19 and My FitnessPal applications too as I felt this worked really nicely, as well as ensuring there were no more than 5 navigation points in the mobile menu.