JD Wetherspoon
Shift swapping & available shifts system
Designing a self-serve shift marketplace that reduced manager admin and made rota changes faster and fairer for 40,000+ employees.
Role
Sole UX/UI Designer
Platforms
Mobile employee app (myJDW) · Desktop manager tool (mySchedule)
Scope
Shift offers · Swaps · Available shifts · Notifications · Settings · Audit log · Open shift creation
Users
40,000+ employees · Managers across 850+ pubs
The challenge
Before this feature existed, covering or swapping a shift meant employees messaging managers directly, managers updating rotas manually, and a lot of back-and-forth that was slow, inefficient, and placed an unnecessary admin burden on pub management. Managers were acting as middlemen for something employees could reasonably coordinate themselves.
The goal was a self-serve system that let staff offer or swap shifts easily, automatically enforced eligibility rules, kept rotas accurate, and reduced the need for manager involvement — all while staying simple enough for quick, everyday use on a phone.
Complexity
Although the core interaction sounds simple, the underlying rules were anything but. The system had to handle eligibility based on training and tenure (managed in the backend, so ineligible shifts were never shown), guaranteed minimum hours with appropriate in-UI warnings ("Offering this shift could take you below your Guaranteed Minimum Hours"), minimum rest periods between shifts, cross-pub swaps within a configurable radius, and multiple shift states — available, pending, confirmed, expired.
Location was a particular design challenge. In cities like London, a set mileage radius could include a large number of pubs. To give employees meaningful control, we added a settings screen where they could select which pubs within that radius they wanted to receive offers from. This came directly out of a pilot rollout issue that was flagged after launch.
Shifts could also exist in one of two offering modes: a straight offer (anyone eligible can claim it) or a swap offer (the claimer must offer one of their own shifts in return, which the original employee then accepts or declines). Designing clear, unambiguous microcopy to explain these states — without overwhelming users — was one of the harder parts of the project.
Left: shift detail — Middle: offer/swap selection — Right: offer confirmation
Process
After receiving the brief from the Business Analyst, I ran a workshop with JDW stakeholders — most of whom were former pub managers — presenting a user story map to walk through and refine together. Direct user research with employees wasn't possible within our process, so I relied on the domain expertise in the room. The workshop helped surface the real operational constraints and edge cases that would have been easy to miss designing in isolation.
Sticky notes from the user story mapping session
Key design decisions
The biggest design priority was simplicity. Employees needed to be able to offer or swap a shift in a handful of taps, without needing to understand the full logic behind it. This meant investing heavily in clear terminology, unambiguous UI states, and microcopy that handled edge cases without being verbose. The notification system also needed to be robust — the right people needed to know when to act, without creating noise for those who didn't.
On the manager side, the desktop tool included an audit log and the ability to create open (unassigned) shifts and broadcast them to eligible employees — giving managers a clearer overview without needing to be the bottleneck in the process.
Left: available shifts — Middle: selecting a shift to swap — Right: updated shift status
Left: an offered shift with incoming offers — Middle: list of offers — Right: confirmation dialog
Outcome
The feature significantly reduced the manual admin involved in rota changes, with fewer missed shifts, less back-and-forth messaging between staff and managers, and faster shift coverage overall. Feedback following rollout was positive, and adoption was strong.
Takeaway
Operational complexity doesn't have to create a complex experience. The challenge here was absorbing the business rules into the system logic and the microcopy, so users never had to think about them. Getting the language right mattered as much as getting the flows right.