Course Versioning

Updating published courses without disrupting learners already in progress.

Course admins needed a safer way to update live learning content. What started as a Course Versioning request became a broader challenge: allowing courses to evolve while protecting learner progress and the experience already in use.

RoleSenior Product Designer
Duration3 weeks
TeamProduct Owner · Engineering
PlatformEnterprise LMS
Course Versioning product composition

The Problem

Updating a live course meant changing something learners were already using.

The project started with a Course Versioning request from the Product Owner. Tracing the existing workflow revealed a larger issue: admins were preparing future changes around a course learners were already using.

Admins couldn't save updates as a draft. They could only Cancel or Publish Course, which meant saving changes published them live.

The challenge wasn't creating V2.
It was protecting everyone still using V1.

What I Found

Understanding how course updates actually happened.

I interviewed four course administrators to understand how they handled updates after a course was already live.

I also explored learning platforms and version-control patterns to understand how other products represented work-in-progress, published states and change history.

What we learned

Four admin interviews surfaced three recurring needs.

  • Save without publishing
  • Continue work across shifts
  • Keep future changes apart

Admins needed a safe way to update live courses without disrupting learners already using them.

Real Challenge

Admins needed flexibility. Learners needed stability.

The research shifted the requirement from simply adding versions to defining how a published course should evolve.

Admin flexibility ↔ Learner stability

Lifecycle Design

Separate Draft from Published.

Admins could create Draft V2 while Published V1 continued serving learners. The Draft persisted, allowing another admin to continue the same work later.

Save preserves the work.
Publish changes the learning experience.

01

Save Draft

Prepare changes without affecting Published V1.

Learner Impact

Publishing introduced a learner problem.

A learner could already be halfway through V1 when V2 was ready. Automatically replacing their course could disrupt progress they had already made.

Publishing needed to surface learner impact before the new version became live.

Publish V2Course
V1Existing learnersContinue on V1
V2New learnersStart on V2

Existing learners keep their version. New learners get the latest.

Migration

Existing and new learners didn't need the same treatment.

Existing learners could remain on the appropriate version they were already taking, while new learners received the latest published version.

When migration was required, it became an explicit admin decision.

01

Course Version Info

Course detail page open on its Versioning Info tab, showing the current version of the course.
Admin screen for starting the bulk learner-migration flow for a course.
Scheduled Migration screen, where an admin picks a future date to move learners.
Empty state shown when no eligible learners remain to migrate — all learners are already on the current version.

Scope Decision

Scheduled Migration was valuable—but not essential for V1.

I explored Scheduled Migration, allowing admins to choose a future date to move learners.

Engineering surfaced additional states, timing logic and edge cases. With a three-week timeline, I worked with the Product Owner and Engineering to defer Scheduled Migration and protect the core lifecycle.

3-week delivery window

V1 — Core lifecycle
  1. Draft
  2. Publishing
  3. Learner continuity
  4. Version history
Scope cut
Later
  1. Scheduled migration

Learner Experience

Give admins control. Give learners clarity.

Once the lifecycle rules were defined, I didn't expose the same complexity to everyone.

Admins needed to manage versions and migration. Learners only needed to know what changed, whether their progress was safe, and if they needed to do anything.

Same lifecycle. Different information needs.

How It Works

One lifecycle connected the entire experience.

Admins could evolve a course while learners continued through a stable experience.

Final course lifecycle

One connected lifecycle.

01

Course List

Course list showing each course with its published and draft version state.
Course detail page distinguishing the live published version from the version being changed.
Version preview, Overview tab — a read-only look at a version before it goes live.
Version preview, Course modules tab — the module structure of the previewed version.
Version comparison view showing differences between two course versions side by side.

What Changed

From manual workaround to an in-product lifecycle.

The documented update workflow moved from a manual, duplication-heavy workaround to a shorter, clearer in-product workflow.

More importantly, admins gained an explicit way to prepare, publish and track course updates inside the LMS.

~11 → ~5 steps

Workflow comparison, not a measured efficiency improvement.

Before → After

What changed between the documented workaround and the designed lifecycle.

Before~11 steps

Manual duplication workaround

Course duplication(3 steps)
Prepare changes(2 steps)
Manual coordination(4 steps)
Live-course transition(2 steps)

Manual coordination and live-content risk.

After~5 steps

Product-supported lifecycle

Create Draft(1 step)
Prepare & Review(2 steps)
Publish(1 step)
Manage learners(1 step)

Live learning remains protected while changes are prepared.

Looking Back

Designing Course Versioning meant thinking beyond the course editor.

The project connected admin collaboration, publishing, learner progress and course history.

The three-week constraint also forced a deliberate choice: protect the core lifecycle and leave Scheduled Migration for later.

Let's talk.