What Circular Wave does
In 2018 the NHS is dogged with insufficient numbers of doctors and nurses to fill hospital shifts. Hospitals will try to fill these empty shifts with ‘bank’ staff, a ‘bank’ of current NHS staff comprising individuals who have previously worked at the hospital and staff who have signed up to the staff ‘bank’ directly. When this 'bank' approach fails to deliver a sufficient number of doctors and nurses to cover a shift, hospital administrators typically resort to (locum) recruitment agencies. The issue here?
Locum agencies cost the NHS an estimated £3.3bn per year
Circular Wave has addressed this problem by developing a scalable software platform that improves communication between hospital administrators (who have shifts to fill) and ‘bank’ staff (who can fill shifts) as well as connect ‘banks’ of staff across multiple hospitals.
Circular Wave's brief
We were briefed to work on the My Availability (actually ‘unavailability’) feature within their mobile application. This functionality allows ‘bank’ staff members to input specific days when they don’t want to receive notifications about shifts. We were asked to develop a granular notification management suite where recurring patterns of unavailability could be entered. The aim of this functionality was to stop users with broad shift eligibility from being deluged with notification. The core screens can be seen below.
Users input unavailability via a calendar interface, one day at a time, to pause notifications.
We followed a double diamond approach (Discover, Define, Develop, Deliver): basically conducting research to help us define the problem and then ideating and prototyping to deliver a solution. The discovery phase included a rigorous review of the existing app as well as competitive research. I've chosen to show the user research below (a combination of usability testing and user interviews).
We spoke to 10 hospital-based junior doctors, all of whom currently work either ‘bank’ or locum shifts. For each participant we conducted 15-minute task-based app usability testing (on the existing app) and then 30-minute user interviews (about their current experience booking ‘bank’ shifts).
Putting the app in front of 10 junior doctors
Having an existing app that we could put in front of users was incredibly useful. After conducting our initial research we set out a meaningful scenario and set of tasks for users to complete as part of testing. Tasks were split between availability features and general shift booking.
We found four key issues:
Issue 1: It wasn’t clear what task could be done on the My Availability screen. And users failed to realise that it was actually a notification management system. Most incorrectly assumed it displayed their upcoming shifts.
Issue 2: Users didn’t understand the circular UI elements in the calendar.
Issue 3: Once they’d gone through the shift booking process, they didn’t receive confirmation of their application and couldn't find the shifts they had applied for in the app.
Issue 4: Most users wanted the option to add the booking directly into their phone calendar.
Talking to junior doctors about how they book shifts
Following our usability testing, we asked the doctors about their current experiences of working locum and ‘bank’ shifts, and then focused on the booking process and their scheduling habits.
We used affinity mapping to explore patterns that arose from the interviews. From the affinity map we created a UX persona and an experience map that further guided the process. Let's start with the persona.
Developing a persona. Meet Kieron
Kieron is a full-time junior doctor with irregular hours who fits occasional ‘bank’ shifts around his main job. He uses ‘bank’ work to get experience in areas of medicine he's interested in but also to meet his saving goals. It’s a struggle to find work/life balance and convoluted NHS admin doesn’t make it any easier. He takes the job and the success of his NHS Trust seriously and will work last minute ‘bank’ shifts if he thinks it will help.
Building out an experience map
First of all, we tried to understand the mechanics of a typical NHS shift booking process. From our research we discovered that this would typically include shifts well in advance as well as last-minute shifts. Then we looked at some of the accompanying thoughts and behaviours that emerged from our affinity mapping exercise.
The diagram below is a simplified overlay from our full experience map, we identified as many as 50 tasks - let's just say it got quite hard to read!
Mapping a typical NHS shift booking process
We found that the 'bank' shift booking process was, in many cases, convoluted and typically differed across hospitals and trusts. Doctors might receive the 'bank' shift rota a fortnight in advance, or might be notified of urgent shifts within 24 hours. Communication was variably done over the phone, by email, in person, via WhatsApp, in Excel, on PDF or on paper. Doctors might have to wait days to hear if they got a shift, and the manual nature of the process opened the possibility for error.
INSIGHT: The Circular Wave app addresses many of the pain points in the typical NHS ‘bank’ shift booking process.
Adding pain point and emotion to the process
The tasks involved in ‘bank’ shift booking only tell part of the story. Our interview also revealed an interesting narrative. Doctors think in terms of availability and not unavailability, and choice is hugely important to them as they often have a complex criteria for selecting a shift. Few found digital notifications annoying - most hated phone calls. Many doctors saw availability as a flexible concept, often willing to switch things around or volunteer for an urgent shift if they thought the "trust was under pressure".
INSIGHT: The development of a notification management feature based on unavailability was unlikely to help users achieve their goals or deliver value.
Taking a new focus: so, what’s the job to be done here?
Combined with our findings from the app usability testing, we decided that there was a case to be made for refocusing on areas of the experience map which not only presented frustrations for our doctors but were also areas of weakness for the Circular Wave app. We proposed the following HMW question to frame this new direction: How might we make shifts applied for clear and visible?
Four days into our two week sprint we met with the client, presented our research and together decided to explore the new HMW statement. We spent our two-hour design studio collaboratively ideating though several sketching/review sessions.
Given the new HMW statement, our focus for the session was the main shift booking screen. The whiteboard sketches (below) represent what we felt to be the strongest designs given the research and our understanding of the user goals. Not super sexy, but there is a lot going on here!
We refined the whiteboard sketches and drew out a paper prototype so we could start to test our ideas. The screens were photographed and uploaded into InVision where basic interactions were applied.
Alongside the prototype we produced a user flow, visualising the path and interactions users would take though the product to complete their tasks. In our case the flow was very streamlined, consisting of 6 steps.
I've chosen to only show one screen below, you can see the existing app screen on the left and the paper prototype on the right. Our design choices were all based on the research, iterating the design in response to user pain points and goals.
The key changes were moving to a scrollable list format for shifts that users can scroll through across day/week/month. Prior to this, shifts were only viewable by day, with the calendar used as the main navigation and point of discovery for available jobs. Tabs were also implemented on the paper prototype, so users are always one tap away from a list of all shifts they have applied for.
Low fidelity prototype
Moving to digital (working in Sketch) we started exploring colour as well as some UI elements we had been unable to render on paper. At this stage we were still making significant changes to the screens as we iterated in response to user testing. Again, I've chosen to only show the home screen here.
Mid fidelity prototype
At mid fidelity we were making much more nuanced changes and decided to introduce brand identity so we could test how/if colour impacted usability. Always pleasing to be making smaller changes because it usually means the UX process is working. We actually found across other screens that it was copy and labelling that was continuing to be problematic for users.
Even at mid fidelity it was fastest to work on the whiteboard, sketching out the screens and collating the test results. This way we could prioritise which changes we would take into the next round of prototyping.
High fidelity screens & prototype
Below are a selection of the final high fidelity screens. The interface is clean and clear, task completion is streamlined, and we have designed a UI that clearly distinguishes shift status while addressing the issue of making shifts applied for clear and visible.
"We were blown away by the quality of work that was produced, but more importantly by the way the team had gone about producing it."
There’s always more to do. This is what we would focus on next:
Explore additional personas: We recognised early on in the project that we only had access to junior doctors and that this limited our research capability. Expanding out to more senior staff members such as consultants would be the next logical step.
Refine the design: Having only spent four days on the design there are definitely areas that would benefit from a review. I’m thinking specifically of some of the wording (‘Book a shift’ is CTA rather than a tab label), button treatment (consistency in how the active buttons are rendered), and icons (the location, email and phone icons need their actions defined).
Integrate long-term shift patterns: While single shifts were our focus during this sprint, there is a use-case (and indeed functionality) where administrators can post sets of linked shifts. This represents core booking functionality but was out of the scope of our project.