Six years of rethinking scheduling.
Six years ago, I started working on making a complex scheduling tool easier to use. Since then, the product has come a long way. We've added new features, improved how managers handle everyday challenges, and adapted as their needs changed. Along the way, my role evolved too, from designing individual workflows to thinking about how everything works together. And now, with AI opening up new possibilities, I'm exploring what the next evolution of scheduling could look like.
It started with a scheduling grid.
When I first started working on Manage Schedule, the biggest challenge was simply seeing the schedule properly. The grid wasn't responsive, making it difficult for managers using tablets to view shifts or make changes. Before we could improve how managers worked with their schedules, we needed to make sure they could actually use them. I worked with our design systems lead and engineers to redesign the grid for different screen sizes, while keeping the scheduling features managers relied on. Along the way, the data revealed something interesting.
Give desktop and tablet broader scheduling capabilities. Focus mobile on day view and quick, useful actions.
We deliberately gave up full feature parity on phones to make the most relevant tasks easier on the go.
With the scheduling grid working across devices, the next step was improving what managers could actually do with it.
Next up was rethinking how managers create and make changes to shifts.
I thought we were helping managers build schedules.
And it wasn't an unreasonable assumption. Create Shift was designed to support that work: roles, breaks, pay rates, and options to assign, offer, or open shifts.
I created prototypes to simplify the experience and took them into user testing.
That's when I learned something I hadn't expected.
of customers used external scheduling engines to create their schedules.
In prototype testing, I learned that managers were coming to WorkJam mainly to handle what happened after the schedule was created: call-outs, late changes, unfilled shifts, and coverage gaps.
I'd been trying to simplify schedule creation. But the bigger problem was helping managers respond when plans changed.
I advocated for a more contextual, streamlined way to make those changes. But a small number of customers still depended on WorkJam for full schedule building, so we couldn't simply remove that workflow.
We simplified the broader Create Shift experience while retaining its scheduling capabilities.
The more focused, contextual approach I wanted wasn't fully adopted. The product had to serve both kinds of customers.
It was a useful reminder: the way a product was built doesn't tell you how people actually use it.
If managers came here to handle changes, why did they have to go looking for the work?
That question shifted my focus beyond the scheduling screen and toward the experience surrounding it.
Bring the work to the manager.
Through Dashboard and improved notifications, we began surfacing information and entry points closer to where managers started their day.
Instead of navigating through different features just to discover what needed attention, managers could see relevant information and follow a more direct path into the work.
It was an important evolution. But surfacing the problem didn't remove the work of figuring out what to do about it.
The product was getting better at showing managers what needed attention. But managers still had to investigate, compare options, and decide how to resolve it.
And those decisions weren't simple. Assign, Offer, and Open Shift each had different rules and consequences. Offers could reach several eligible employees, who could then accept and await manager selection. Open Shifts could follow configured seniority groups and response windows. Critical violations blocked actions; non-critical ones could still allow them.
All of that complexity was necessary. But what if the product could help managers work through it?
Meanwhile, the product was learning to handle more of the complexity.
Over those six years, my work wasn't limited to what managers saw in Manage Schedule. I also designed the administrative experiences that define how scheduling should work: the policies, conditions, and exceptions that influence what managers and employees can do.
As the product supported more real-world scenarios, these rules became an important part of helping managers make informed decisions. But they also meant that a seemingly simple action, like filling a shift, could involve several checks, approvals, and people.
Rules are configured in one place. Their consequences show up somewhere else.
These examples illustrate the connection between admin configuration, employee actions, and manager decisions. They are simplified diagrams, not product screenshots.
Schedule attestation
When certain schedule changes require employee consent, the experience needs to make that requirement clear.
Rule violations
Scheduling policies can warn managers about exceptions or prevent an action altogether.
Call-out requests Recent design work
Employees need a clear way to report an absence, while administrators need to define the conditions and information required.
My role stretched across these connected experiences, from the admin controls that define policy to the employee and manager workflows where that policy takes effect. Each side had to make sense on its own, but they also had to work together.
More context, stronger policy enforcement, and clearer ways to handle exceptions and unexpected changes.
As the system became more capable, managers still had to interpret rules and coordinate several steps to resolve one staffing problem.
That raised the next question: if the product already knew the rules and supported the actions, could it help connect the steps?
What if the system could investigate first?
Imagine a cashier calls out 45 minutes before their shift. Rather than leaving the manager to investigate every possible solution, an agent could use existing scheduling data and rules to prepare a compliant recommendation.
It might recommend offering the shift to multiple eligible employees, explaining why that approach could be faster than an Open Shift sequence, while making clear that coverage isn't confirmed until the required acceptance and approval steps are complete.
The manager still decides whether to send the offer.
A shift may be understaffed in 45 minutes.
Suggested next step: Offer this shift to eligible employees.
Multiple employees can respond in parallel. An Open Shift may take longer because of configured priority windows. All options must pass current scheduling rules.
Illustrative concept. No real employee or staffing data.
But the agent shouldn't make every decision.
WorkJam already distinguishes critical violations, which block an action, from non-critical violations that managers may be authorized to accept. Those rules belong to the scheduling engine, not to an AI model.
And when several employees accept an offer, the manager may need to choose among them. An agent could summarize the differences and highlight relevant exceptions without deciding who deserves the hours.
Validate eligibility, enforce admin-configured rules, and execute authorized scheduling actions.
Approve meaningful changes, consider exceptions, and choose among interested employees.
This is a proposed experience. Coverage calculations, data reliability, policy handling, and manager trust would require technical and customer validation.
The problem kept changing. So did the product. And so did the questions I asked.
I began by asking how to make scheduling easier to use. Then how to make changes easier to manage. Then how to bring the right work to managers.
Today, I'm asking how much of that work managers should need to do at all.
That's what six years on the same product taught me: a design doesn't stay useful just because it once solved the right problem. As customer behavior, product capabilities, and technology change, we have to keep questioning what the experience should become.
Portfolio prototype. Interface illustrations are conceptual reconstructions and should not be represented as shipped WorkJam screenshots. The AI agent section is speculative.