Feature Design
Repeat this Event:
Making recurring schedules safe to edit
The hardest part of a recurring event isn't creating it — it's everything that happens after, when someone needs to change a single instance without breaking the rest of the series.
Visuals have been white-labeled to protect client confidentiality
Impact at a glance
Scheduling recurring events saved hours
Eliminated data loss when editing a single occurrence
One progressive editor replaced four divergent recurrence flows
Highlights
- Collapsed four divergent recurrence types into one progressive editor that reveals complexity only when needed
- Made detachment a visible, deliberate choice, eliminating silent data loss
- Defined predictable downstream behavior across edit, delete, and detach
- Partnered with engineering to cover every temporal edge case (leap days, DST, timezones)
Context
Repeating an event looks like a checkbox. Underneath, it's four features stacked together.
Daily, weekly, monthly, and yearly each carry their own rules, intervals, and end conditions, plus the whole afterlife of editing a series once it exists. That's the complexity the checkbox hides. On an enterprise scheduling platform used by [fill in — e.g. teams managing thousands of events], it multiplies fast.
I led the design end-to-end. My approach was to keep a simple two-tap interaction, save the complexity for the moments that need it, and make edits to a series predictable.
Problem & Opportunity
The product had no real concept of recurrence.
A scheduler who needed the same event every week built it the only way available: by hand, one occurrence at a time. A single recurring need became a dozen near-identical events, each entered manually, and every later change meant editing each one again. It was slow, error-prone, and the sort of repetition software exists to remove.
The trouble started once a series existed. The moment a user edits a single occurrence and applies the change to just that one, it detaches from the rule and becomes a standalone exception: an event that still looks like part of the series but no longer follows it. That detachment, and what happens next, was the hardest part of the entire feature.
The opportunity: let people describe the pattern once, and let the system handle the rest.
Solution / Process
"Just add a repeat button" was the whole request. Each of the four types has its own shape:
- Daily needs almost nothing beyond an interval.
- Weekly needs a set of weekdays.
- Monthly hides a genuine ambiguity: "the 15th" and "the third Wednesday" are both valid, and produce completely different calendars.
- Yearly carries its own edge case in the leap day.
Each is then multiplied by an interval and an end condition, and that's still only the creation path.
Making the editing model legible was the harder problem. When a user edits a single occurrence, the design signals the consequence at that exact moment, so detachment is a deliberate choice and never a surprise. A detached occurrence is made visually distinct from a linked one, and downstream behavior is defined predictably for every case (when the series is edited, when it's deleted, and when an occurrence first detaches) so the system never silently overwrites what the user meant.
I led the design and worked through every edge case with engineering: month-length differences, leap days, and timezone/daylight-saving boundaries.
Results / Metrics
- User impact. What used to take hours of manual entry per month now takes two taps, removing repetitive data entry from the year.
- Quality. Reduce user error by limiting to editing one event instead of multiple.
Reflection / What I Learned
A polished repeat button was the shippable version. The design problem was everything after it. The work that counted was the part users never see until something goes wrong: what happens to a series when one instance changes.
The failure states came first. Deciding how a series behaves when it's edited, deleted, or detached, before polishing anything, is what made the happy path safe.