Shift Version History.
Redesigning shift editing so admins can change the future without touching the past.
One shift. Many versions.
Admins needed to change a shift’s hours without breaking attendance history or rebuilding the shift and reassigning every employee. I reframed the problem: a shift keeps its identity while its configuration changes over time. A new version takes effect on a chosen date, while past attendance stays linked to the version active at the time.
A timing change should not rewrite history.
Support tickets and internal feedback showed the same pattern: admins changed shift timings and then could not confidently read earlier attendance, or spent time moving people to a replacement shift.
Attendance consistency
Changed timings made earlier attendance hard to interpret.
Administrative overhead
Reassigning employees one by one was slow and error-prone.
Version visibility
Admins could not tell which version was assigned, or when its settings last changed.
Same shift, different period.
“Product Team” can stay the same shift for years while its hours and rules change. The design question: how might we change a shift going forward without changing how the past is read?
Edit in place
Fast, but leaves past attendance without a clear link to the old hours.
Duplicate and reassign
Keeps history separate, but creates manual work and near-identical shifts.
Versions of the same shift
One identity, readable history, users carried over automatically. Chosen — with naming, status, and timing made explicit.
Separate what changes from when.
The hard part was keeping employees, settings, and records predictable. So preparing a version and scheduling it are two decisions, and every step says the same thing: the past stays untouched.
Name the version everywhere
References such as Product Team (Version 2) make the configuration unmistakable.
Create first, schedule second
A short dialog names the new version and explains the transfer; a separate dialog sets the effective date.
Signal the pending change
A small dot on the actions menu and Version History tells other site admins that a version has been created and scheduled for change.
Color carries meaning
Blue marks current and scheduled states; red is reserved for destructive actions such as Cancel Schedule.
From pending change to safe cancellation.
The same reassurance repeats at every step. Counts and names in these screens are demo interface content, not measured results.
Summary counts and a dot on the actions menu point to the pending change.
A side panel confirms history stays intact before anything is saved.
The dialog names Version 2 and explains who moves, and when.
The effective date is chosen separately from creating the version.
The scheduled version can be reviewed, rescheduled, or cancelled.
The confirmation states exactly what is removed and what remains.
A predictable path through change.
The flow is edit, create a version, choose its date — no replacement shift, no reassigning employees by hand. Version History separates current from scheduled settings, and a pending change can be reviewed, rescheduled, or cancelled. These are design outcomes; the case study reports no measured performance improvements.
State and timing need separate controls
Naming each step removes ambiguity about what changes and when.
Trust comes from predictability
The system should say what it is about to do before it happens.
Small cues carry context
A dot can replace extra navigation when it points to the right place.
Make the differences even clearer.
The next explorations would strengthen review before a scheduled change takes effect.