Goal
To get more medical facilities who were short staffed to post their shifts on the app marketplace.
My Role
Research & Lead Design
UX Strategist
Spoiler:
This is where it landed, but before this, this app had a pretty unfortunate problem.
THIS ^ was a big part of the problem.
Medical facilities experiencing staffing shortages often need to call in a contract nurse or nursing assistant to cover one or two shifts where in-house staffing just isn't available.
This app is a mobile (mostly) application that offers a way for medical facilities to post their single-shift needs on a market place, where qualified nurses and nursing assistants can opt-in to single days of work at premium pay.
The app launched with a flow that allowed the medical facility to create a shift posting and include the date, time, and describe the type of license and qualifications they would like applicants to that shift to have.
As simple as that flow was, customers were used to agencies who managed this part for them. They would previously just send the agency a list of times and dates and let the agency do the rest. Often, many shifts needed to be advertised and once, so this posting process was just too time consuming as it was.
Medical facilities either wouldn’t do it and use the marketplace at all, or they would called in to Nursa's help center to get an agent to do the time consuming work on their behalf. This, of course, defeated the idea of a self-service marketplace and cost Nursa staff time doing work more like that of a staffing agency instead of as application support.
Bulk Upload
There was, when I took this problem on, also already an alternate solution that had also been created to help medical scheduling users get more than one shift at a time to the marketplace.
Unfortunately, it required precise and fairly technical data entry to use, and most of Nursa's schedulers didn't understand how it worked and struggled to learn it proficiently. Those who did learn to use it, still found transposing their calendar openings into this formatting to be time consuming.
At the start of this project, the Product team sated the UX goal was to figure out how to make this bulk upload easier for users to enter data into.
The suggested test criteria was that the updates to the bulk upload tool would make it easy and fast for users to upload hundreds of shifts at a time from a text file.
I had my suspicions about this goal.
I wasn't seeing any real businesses using the app enter hundreds of shifts at once. (There was one guy doing this.. but he was one. guy. And he was pretty good at the bulk uploader anyway.)
And even if I could make it easy to upload shifts from a text file, someone at the medical facility would have to be transporting their calendar data to a text file.
Another idea was to have a tool that would read a photo of a calendar and use AI to determine where the empty shifts were, all the criteria, and import it to the marketplace. That's a great idea. But, I am not a magician.
What Did Users Even Need?
I concluded fairly quickly we should skip the middle man – no need to create a document to enter data in the UI.
So I wanted to get a clear understanding of what users we actually needing to enter into the UI.
My approach to this was to try to identify job-opening patterns at the medical facilities on the Nursa marketplace. To figure this out, I looked at four months of posting data in the marketplace. I reviewed data entered by someone at the medical facility, and data entered by Nursa's customer teams as well. I was especially interested in shift openings posted during a single session, and the total number of shifts at a given facility open at the same time that shared very similar attributes (time, date, type of worker, etc.)
Overwhelmingly, shifts were posted in batches of five or six at a time, though there were sporadic examples of twenty to thirty posted during a session too. In the four month window I looked at, there were no instances of 100 shifts being posted to the marketplace in a session, over a short period of time, or open at one time.
To design the tool effectively, I believed it was also critical l to understand the commonalities and variations among the jobs. I noted that within the bundles of shifts posted in a session, there were subsets of identical shift needs, or nearly identical needs with variation in the dates over a few days, or the time over a single day, or sometimes the type of clinical help requested.
General Ideation & Testing…
I knew that the solutions was just a GUI that let them easily create a shift, and bundles of shifts, without constant data re-entry on the same data points.
…and it began to come into view
They needed to flexibly start from any point of data and duplicate any portion. And lucky me, I was partnered with a great graphic designer who really understood me!
Play the Solution:
RESULT
This "broke" some metrics. Really. The folks watching customer growth panicked as, when this released, so many end-users posted their own shifts, and so many more of them, it tanked a number they watched (calculated shifts posted to shift filled). Such a significant number of user were able to post their own shifts (5, 10, 20 at a time) that our post rate shot up. Since we hadn't, in tandem, released something to stimulate a parallel sudden influx of nurses to fill the shifts, it ruined the percentage. However, long term, the addition of new open shift content supported the growth of the application.