Shift Actions: Offer & Swap

Designing the employee side of shift trading inside an enterprise scheduling platform — from a lightweight product brief through to finalized hi-fi flows for Shift Offer and Swap, ready for an upcoming release.

Shift Swap was in the final stages of design. Bid and Acceptance had been fully defined and documented, but were intentionally held back for a future release to keep the upcoming build focused. I'm including this project because it's a good illustration of how I work when the scope is large, the direction is ambiguous, and the path forward isn't handed to you

The Challenge

Shift trading in workforce management is one of those things that seems obviously necessary — and is surprisingly underbuilt in most enterprise systems. Employees need to find coverage, offer shifts they can't work, swap with a willing colleague, pick up open shifts, and acknowledge published schedules. In most environments, this still happens over text, group chats, and hallway conversations — because the in-system experience either doesn't exist or requires too much manager involvement to be worth using.

Dayforce had the infrastructure to support employee-driven shift actions, but not the employee-facing experience to make them usable. The opportunity was to design four flows:

• Shift Offer — an employee makes one of their shifts available to a colleague

• Shift Swap / Trade — two employees exchange shifts

• Shift Bidding — employees compete for open, unassigned shifts

• Schedule Acceptance — an employee formally acknowledges a published schedule

Each one looks simple in a feature list. Each one is actually a multi-party interaction with business rules, eligibility logic, approval conditions, and a set of states that have to be communicated clearly to three different audiences: the employee initiating the action, the employee on the receiving end, and the manager overseeing both.

Starting From Scratch on the Brief

The product brief I received was thin. It identified the four action types and not much else — no clear direction on scope, no defined requirements, and no clear path to the subject matter expert who could answer the questions I needed to start designing.

I could have waited. I didn't. I took what was there and treated it as a starting point rather than a blocker. I tracked down the right person — someone inside the organization who actually understood the business logic, the approval workflows, and the eligibility rules behind each action type — and got the information I needed directly. That conversation was the real brief. What came after was me rebuilding the product documentation from the ground up: goals, user stories, success criteria, edge cases, and risks, all written out and formally recorded.

The whole process took longer than it should have, and it had real timeline implications. But by the time I was designing, I was building on solid ground — not guessing at requirements mid-flow.

One other thing worth mentioning: with a product partner who was stretched thin and unable to engage consistently, I leaned on AI tooling as a sounding board for working through requirements, stress-testing assumptions, and moving forward when I didn't have a human to sanity-check against. It wasn't a replacement for a proper product partnership, but it kept things moving — and it worked well enough that I'd do it again.

Scoping and Prioritization

All four flows were scoped for the full project, but not everything was slated for the same release. The decision to focus first on Shift Offer and Swap came down to a few factors: they're closely related from a system and UI perspective, they cover the highest-frequency use case (employees trading shifts with each other), and together they made a coherent, releasable feature.

Bid and Acceptance were defined in full — user stories, states, edge cases, all documented and tracked in Jira — but were deliberately held back to keep the upcoming release tight. That was the right call. Shipping two well-designed flows beats shipping four half-finished ones.

The user flows for all four actions were mapped before any design work started. Even though bidding and acceptance were deprioritized from a delivery standpoint, understanding their logic upfront was essential — the flows share system-level concepts (eligibility, approval, state) that had to be consistent across all four.

Defining Shift States

One of the most consequential pieces of foundational work on this project was defining the shift states — and making sure those states were expressed consistently from every angle.

A single shift offer, for example, doesn't just have one state. It has a state for the employee who sent it (Pending, Viewed, Accepted, Declined, Withdrawn, Expired). It has a state for the employee who received it (New, Accepted, Declined). And it has a state for the manager (Pending approval, Approved, Denied, or no action required, depending on client configuration). All three of these need to be in sync, communicated clearly, and designed so that each party sees the right thing at the right moment.

Getting this wrong is how you end up with an employee who thinks a swap is confirmed while their manager hasn't approved it, or a colleague who declined an offer that the system is still showing as open. I mapped out all the states across all three actors before opening Figma, and that documentation became the design system for the entire project. It also meant that when Swap was designed after Offer, the state logic was already established and just needed to be applied.

Design

Shift Offer went through the full process — user flow mapping, lo-fi exploration, mid-fi iteration, and hi-fi finalization. The flow covers: initiating the offer from a shift card, selecting a recipient (with eligibility filtering so employees only see colleagues who can actually take the shift), reviewing the shift details, confirming the offer, and tracking the status from the initiating employee's side. States are communicated clearly throughout — the employee always knows where their offer stands.

The shift detail screen — showing start time, job assignment, location, and a segment-by-segment timeline of the shift — was a deliberate design decision. Before committing to a trade, both parties need to understand exactly what they're agreeing to. That detail view threads through both Offer and Swap.

Shift Swap / Trade extends the Offer logic into a bilateral exchange. It introduces the added complexity of both parties' schedules needing to work — eligibility checking has to run in both directions — and the confirmation flow has to be clear about what each employee is giving up and gaining. The design had reached near-final hi-fi at the time I was laid off, with the core flows complete and the edge cases documented.

Both flows were designed with three distinct views: the initiating employee's experience, the receiving employee's experience, and the manager's view. The flows are not isolated — actions taken in one view ripple into the others, and the design accounts for that.

Figma Make prototypes were built for both flows as part of the design and iteration process. They were useful in a way that static screens aren't — being able to click through the actual flow, including conditional branching for different states, made it much easier to spot friction points and validate decisions without needing formal testing cycles set up. Unfortunately, my access to those prototypes was revoked when I was laid off, so I'm not able to include them here. But they were a meaningful part of how this work got done.

Where Things Landed

Shift Offer: Finalized, annotated, responsive specs complete — ready for development.

Shift Swap / Trade: Near-final — core flows complete, edge cases documented, final polish in progress at time of layoff.

Shift Bidding and Schedule Acceptance: Fully defined and documented in Jira. Designs not started — correctly deferred to a future release.

Offer and Swap were on track for the upcoming release.

Reflection

This project asked a lot more of me than the original brief suggested it would. I had to reconstruct the requirements, find the right people to talk to, define the state logic from scratch, and keep the design moving under real time pressure and without consistent product support.

What I'd point to is the state definition work. It's not glamorous. It doesn't make for a visually striking portfolio slide. But it's the kind of thinking that makes a complex multi-party feature actually work — and it's the kind of thing that goes wrong when no one does it. I did it, I documented it, and it held up across both flows.

The timeline pressure also sharpened something I already believed: doing the definition work thoroughly upfront — even when it feels like it's slowing you down — is what makes the design phase go faster. By the time I was in Figma building the hi-fi for Shift Offer, the hard decisions were already made. The screens were expressing logic I understood, not logic I was still figuring out.