Applying UX triage on a medical MVP
Client project for General Assembly UX Immersive 2018
Duration | Team | Role | Project Type
2.5 weeks | Team of 3 | UX Designer | Client Project (General Assembly)
UX Methodologies
User interviews | Affinity mapping | Personas | Competitor analysis | User journeys | Experience mapping | Design studio | Sketching | Wireframing | Rapid prototyping | User testing | Visual design | Presenting
Tools Used
Sketch | InVision | Mural | Omnigraffle | Trello | Paper | Post-its | Sharpies
Brief
For the General Assembly UX client project our team received a brief from an NHS-focused start-up called Circular Wave. Over the past three years it has developed an MVP platform that several hospitals in the north of England have adopted.
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 have 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.
Circular Wave were aware that prior to specialising, junior doctors are eligible for a broad range of shifts and were concerned that these users might be overloaded with notifications — hence development of a more granular set of tools to manage them.
Process
Research
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 interviews).
Conducting user research
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 MVP) and then 30-minute user interviews (about their current experience booking ‘bank’ shifts).
Putting the app in front of junior doctors
Having an existing MVP 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.
From our MVP usability testing we found four key issues that went beyond the availability feature set:
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 (grounded firmly in our research) and an experience map that further guided the process. Key findings from the affinity mapping are included in the sections below.
Developing a UX/Design 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, and 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
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 ‘How might we’ (HMW) question to frame this new direction: How might we make shifts applied for clear and visible?
Collaborative ideation in design studio
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. These whiteboard sketches represent the combination of what we collectively felt were the ideas that came out of the ideation best addressing the user needs. They are deceptively simple but there’s a lot going on here and the clearest way to talk through this is on the paper prototype itself.
Solution
Paper prototype
Our paper prototype comprised of two screens — the home screen, and an application screen. In each case the existing MVP is shown on the left and the prototype on the right.
The main change in the shift booking screen was moving away from the calendar being a content gatekeeper with available shifts only visible by day, to a list of shifts that scrolled across days/weeks. The calendar became a secondary navigation and also the canvas on which shift (and shift status) was displayed.
The application screen was transitioned from a modal implementation in order to provide more space for shift details. Additional space would also allow give us more room to provide the user with feedback on the actions they were taking — exactly where they were in the shift-booking user journey.
User flow
Across these two screens we were looking at a very streamlined user flow with only 6 steps. There was an awareness that doctors are busy and that the process needed to be fast and easy to complete.
Low fidelity prototype
Moving to digital (working in Sketch) allowed us to start 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 testing. Notably we reimplemented the tabs at the bottom of the Home Screen and completely removed the calendar from the My Shifts screen.
Mid fidelity prototype
At mid fidelity we were making more nuanced changes and decided to introduce brand identity so we could test how/if colour impacted usability. An interesting change on the Home Screen was the urgent icons — we found that users interpreted the exclamation points as a warning (it’s the exact opposite!) and decided to add text and a more visually descriptive icon.
Interestingly, while we were coming to the end of our allocated testing time we found that it was copywriting issues (button and tab labelling) rather then UI issues that were still proving to be problematic for users. We ended up back on paper as it was the fastest way of testing out new messaging.
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.
And we received some great feedback from our clients at Circular Wave.
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.
You can view the InVision prototype here.
An awesome team
Finally a shout-out to Jessie and Andy who worked on this project with me — could not have asked for a better team!
Next Steps
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).
Explore the data: We didn’t have access to the back end but it appears that that app is part of a particularly data-rich environment. It would be interesting to explore whether we could leverage some of this data in a way that would provide value to the app users. An example might be to show how many users had applied for each shift and even who those users were.
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.
Develop notifications: Based on our research we touched on urgent shift notifications, however we believe there is a need to fully integrate it with the in-app notifications.
UX Learnings
You’ve read what I did on this project, now you might also be interested in what I actually learned during it.
Push for relevant interviewees as early as possible
Being able to conduct the initial research with 10 junior doctors allowed us to get a very detailed picture of our target users, the environment they worked in, their goals, their needs and their pain points. We ran all over town at all times of day and it was absolutely worth it — it provided guidance during our design process and enabled us to speak a common language with our client from early in the sprint.
There’s value in participating in the full UX process
We decided at the start of the project that wherever possible we wanted to each work across the full process (not always easy, time was short, and not all tools support collaboration well…I’m looking at you Sketch). Being involved particularly in the research was invaluable in giving us the confidence to refocus the brief and to develop the idea with a shared vision.
It’s ok to feel uncomfortable, embrace it
It’s simply odd that with so much process, and so many models and methodologies, that it is possible to feel discomfort and doubt about the direction the project is taking and the design solution being pursued. My experience is that it can be uncomfortable not knowing where you are going to end up, especially when you hold off trying to formulate solutions early on in the process (which you absolutely should not do). Embrace it.
Thanks for reading my article, I am a UX designer looking for a full time job, you can find my portfolio here.
If you ♥ what you read please be sure to give me a clap.
