Background
Scheduling sat at the center of the product, but the flows for building and adjusting schedules had grown complex as new scheduling rules and edge cases were added over time.
Staff regularly ran into confusing states when editing schedules, and support fielded repeated questions about how specific scheduling rules actually worked.
My goal was to simplify the core scheduling flows so they were easier to understand, faster to use, and more resilient to edge cases.
The problem
As scheduling rules grew more sophisticated, the interface hadn't kept pace, forcing users to piece together how the system actually behaved.
- Creating and editing schedules required too many steps for common tasks
- Conflicts and edge cases surfaced late, often after a schedule was already published
- Scheduling rules weren't visible or explained within the flow itself
- Small teams and large teams were forced through the same rigid flow
Understanding the problem
I partnered with operations and Customer Success teams, shadowed scheduling sessions, and reviewed support tickets and product usage data to understand where scheduling broke down.
Three themes emerged:
01 — Common tasks took too many steps
Frequent scheduling actions were buried behind flows built for more complex, less common cases.
02 — Conflicts surfaced too late
Scheduling conflicts were often only visible after a schedule was already committed.
03 — The system's rules weren't visible
Users couldn't easily tell why the system behaved the way it did, which eroded trust in the schedule.
Streamlining common scheduling tasks
I redesigned the core flow around the most frequent scheduling actions, cutting steps for common tasks while keeping advanced options available.
Surfacing conflicts earlier
I introduced real-time conflict detection within the scheduling flow itself, so issues could be caught and resolved before a schedule was published.
Explaining the system's rules
I added contextual explanations for scheduling logic directly in the interface, so users could understand why the system behaved the way it did.
Testing & iteration
I prototyped the new scheduling flow and tested it with teams of varying size and complexity to validate that it scaled from small teams to large ones.
Feedback helped refine how conflicts were surfaced and how much scheduling logic to expose without overwhelming users.
Outcome
The redesigned scheduling flow made day-to-day scheduling faster and more predictable.
- Cut steps for common scheduling tasks in half
- Reduced scheduling-related support tickets by surfacing conflicts earlier
- Made scheduling logic transparent instead of hidden
- Scaled cleanly across teams of different sizes
