Every eLearning project has the same quiet danger point: the review rounds. The content is approved, the build is done, and then “just a few tweaks” turns into a third round, then a fourth, and suddenly the schedule is gone, the budget is gone, and the course looks nothing like what was approved. Nobody acted in bad faith. There was just no limit, so the edits had no reason to stop.
The fix isn’t more discipline from the client or more patience from the developer. It’s a simple structure: two named review rounds, a cap on each, and a clear definition of what counts as an edit.
The two rounds: Alpha and Beta
Alpha is the first full build. Every screen, interaction, quiz and piece of narration exists, but it isn’t polished. This is where reviewers check content accuracy, flow and whether the course does what the approved storyboard promised. It’s the round where real changes happen.
Beta is the near-final version, with the Alpha feedback applied. This round is for catching what’s still broken: typos, wrong answers, navigation problems, audio glitches, anything that doesn’t work in the LMS. It is not the round for new ideas.
After Beta comes the final version. If the structure holds, there’s no third round.
Why rounds spiral without caps
Three things make an open-ended review round grow:
- Seeing it for the first time. A reviewer who finally sees the real course has new ideas. That’s natural, and it’s why Alpha has room for them. By Beta, new ideas are expensive.
- Too many reviewers. Five people send five separate lists, some of them contradicting each other, and the developer gets to referee.
- No definition of “an edit.” “Make the intro punchier” can mean a one-word change or a full rewrite. Without a shared definition, everything feels like a small ask.
Put a number on each round
For a typical 20 to 30 minute course, a reasonable starting point is up to 40 change requests in Alpha and up to 15 in Beta. Scale those up or down with the length and complexity of the course. The exact numbers matter less than having them, and agreeing to them before the build starts, not in the middle of an argument.
The Beta cap is deliberately smaller. By then the course should be nearly right, so a large Beta list is a signal that something was missed earlier, not a reason to keep going.
Define what counts as an edit
A cap only works if everyone counts the same way. These rules keep it fair:
- One consolidated list per round. One person collects everyone’s feedback, resolves the conflicts, and sends a single list. Keeping the developer out of the referee role is worth more than any other rule here.
- One request is one edit. “Change the button label on screen 12” is one. “Change that same label everywhere it appears” is also one, because it’s a single decision.
- Bugs and errors don’t count against the cap. If I built something wrong, a typo, a broken link, a quiz that marks the right answer incorrect, I fix it free and it doesn’t use up an edit. The cap covers changes of mind, not mistakes.
- Preferences count. Errors don’t. Rewording something that was correct is a preference. Fixing something that was incorrect is an error. That distinction settles most arguments.
- Beta is for fixes, not additions. New screens, new content or a new interaction at Beta is new scope, however small it sounds.
What happens when you hit the cap
This is the part people avoid, and it’s the part that matters. If a round goes over the cap, there are two honest options: prioritize the list down to the cap, or agree to extra edits as a small, clearly priced change order. Either is fine. What isn’t fine is quietly absorbing the overflow and resenting it later, or quietly letting the schedule slip while no one says why.
It also helps to set a feedback deadline for each round. A review that drags on for three weeks is its own form of scope creep, because the project sits idle while the rest of the schedule keeps moving.
It protects the client too
It’s easy to read caps as something that protects the developer. They protect the client just as much. A fixed number of edits forces the team to decide what actually matters, so the important changes get made well instead of buried in a list of forty small ones. And a project that ends on schedule and on budget is the version that gets approved again next year.
How do you handle review rounds on your projects? I’d like to hear what’s worked, and what hasn’t.
Related items
Every few months a client asks for “gamification” and means one thing: badges. Maybe a lea
Every instructional designer has lived this: a subject matter expert hands over a stack of
Every instructional designer says they build “branching scenarios.” Sit through half of wh