Redesigning Shift Scheduling

Helped Spotwork unlock higher customer retention and fill rates

Shifts were a critical lever of Spotwork's business. A large backlog of scheduled shifts guaranteed continuity and a healthy cash flow. Companies posting regularly signalled high trust and retention, and saw higher worker attendances.

Yet, despite the clear upside, our staffing tools did not pay sufficient attention to repetition. You could post shifts, but could not extend them once posted.

Core Problem

Without proper extension mechanisms, staffing managers had to perform the duplicate work of redrafting shifts and sending fresh offers out every time.

While to its credit the scheduling calendar did allow you to select multiple dates when scheduling shifts, having to pick dates one-at-a-time was slow and tedious, especially for longer schedules.

Try selecting the dates in the scheduling calendar shown above. Notice how the number of clicks required to schedule shifts grows in lockstep with the number of shift dates you choose.

This gap signalled the need for a change in the scheduling workflow. Support requests and back-channel feedback echoed the same sentiment. Our objective was clear.

Design Brief

Redesign the shifts workflow in a way that makes scheduling and extending 10x faster and easier than it is today.

I planned to ship the redesign in two releases: the first pass addressed the shift form's structural issues; the second delivered scheduling robustness.

Release 1

Simplifying the Shift Form

My first goal was to make the shift form easier to infer. The form combined shift, job role, and scheduling data into a single view causing 40% of the form fields to overflow past the average fold height. I reorganized shift metadata and schedule planning into dedicated steps to afford progressive disclosure of information.

In the old UI, the shift metadata and scheduling were clubbed together into a single view. I restructured this data into their respective steps when redesigning the UI.

The form's information architecture also needed refactoring as users never touched any position fields in the form other than the shift start and end time that needed to be different between say, day vs. night shifts. Rolling them into position fields also required an extra click when modifying them. I moved these fields to the shift planning step, relieving positions of their scheduling responsibilities.

The remaining position data was for reference only. Presenting this read-only data in disabled input fields flattened the information hierarchy, making the form seem more information dense than it actually was. I consolidated the data from these fields into a card and introduced a map to depict the site location. This position gestalt allowed users to glance at relevant position information with minimal distraction.

Using disabled fields to present reference-only data in the legacy form resulted in poor information hierarchy. I replaced these fields with a position card in the redesign, making information glanceable.

Release 2

Making Scheduling Flexible

Now that I had a structurally sound form to work with, I shifted my attention to the extension mechanism. To ground the solution in familiar mental models, I studied our competitors' approaches and looked beyond staffing into analogous scheduling experiences, such as calendar and meeting apps as useful points of reference.

I noticed that weekly recurrence was a common theme across the experiences I studied. It was efficient as it allowed you to extend your schedule to any length by simply changing the recurrence end date. But it was orthogonal to the current scheduling workflow. So I prototyped the idea to put it to the test.

Hypothesis

Staffing managers would adapt quickly to a weekly recurrence-based UI as it is common among the tools they use everyday.

Scheduling Concept 1 (Rejected): A weekly recurrence-based UI concept where changing the until date allowed you to efficiently extend schedules by any number of days.

Recurrence was efficient, but rigid. My initial tests with staffing support managers revealed cracks in the draft prototype that caused certain relevant boundary scenarios to fall through.

Forced Weekly Symmetry: Schedules don't always follow a neat weekly cadence. Weekly symmetry forced staffing managers to create separate shifts in such situations, undermining the efficacy of the solution.

The pallet feeder [position's] schedule runs bi-weekly. I can't fit that in a weekly cycle.

—Matthew, a supervisor evaluating the prototype

Further, there was no option to skip a date falling within the recurrence pattern. This incorrectly assumed that supervisors would remember to manually cancel the unwanted shifts after posting to handle exceptions such as business holidays.

Unresolved Ordinal References: The recurrence UI obscured the calendar behind a click, violating the recognition heuristic. One manager opened the calendar app on their phone for reference while completing a scheduling task.

This made one thing evidently clear: a recurrence pattern based design was incapable of adequately capturing the ebbs and flows of everyday business staffing.

I reintroduced the calendar into the design and gave it center stage. To overcome the friction of selecting shift date one-at-a-time, I gave it a drag-to-select affordance.

Revised Design

A drag-to-select scheduling experience that married the versatility of the calendar view with the efficiency of the weekly recurrences.

Scheduling Concept 2 (Approved): An enhanced calendar UI concept that combined the efficiency of recurrence patterns with the simplicity of the original scheduling calendar UI.

The added ability of dragging to toggle multiple dates simultaneously gave seasoned staffing managers a faster alternative for bulk selecting dates, while keeping the simplicity and familiarity of the interface intact.

While not as minimal as the recurrence UI, the revised design gave supervisors complete control over date exclusions, offering a closer facsimile to their real scheduling needs.