The kind of feedback shapes the result.
Most courses are built and rebuilt to feedback. The difference between a course that lands well and one that doesn't is almost never the original draft — it's the quality of the iteration that followed. We've worked on projects where the first draft was 90% right and we still ended up with a worse final course, because the feedback round chased small inconsistencies while missing the structural issue. We've also worked on projects where the first draft was 40% right and we got to brilliant in one revision, because the feedback was clear about what wasn't working and why.
Good feedback isn't about catching every typo. It's about identifying what's getting in the way of the learner's experience and naming it specifically.
Six principles
How to give feedback that moves the project forward.
01 — Specific beats vague, every time.
"This section feels off" is unactionable. We don't know what to change. "The section on data classification feels too long — could we cut the worked example and just keep the principle?" is actionable. We know what to do, why, and roughly how much. The single most impactful change you can make to feedback is to replace "feels" with "is" plus a specific behavioural observation.
02 — Behavioural beats taste-based.
Taste-based feedback: "I don't like the colour of the buttons." Behavioural feedback: "The buttons look the same as the disabled cards — I keep clicking them by accident." The first asks for a change. The second describes a problem. Behavioural feedback is enormously easier to act on because it points at a learner's experience rather than a personal preference. Both have a place — but behavioural is where good iteration lives.
03 — Ask questions before stating preferences.
If something in the draft surprises you, ask why we did it before saying you don't like it. "Why did you put the scenario before the principle?" is a more useful question than "I'd flip the scenario and the principle". The first opens a conversation; we explain the design reasoning, and you decide whether you agree. The second skips that conversation and overrides a decision that may have been deliberate. Sometimes we're wrong and your instinct is right — but the conversation gets us both there faster.
04 — Prioritise. Not everything is equal.
A feedback document with 47 items, all written in the same neutral tone, is impossible to action well — we don't know which ones matter to you. Mark items as "must change" (we will, full stop), "would prefer to change" (we will, time permitting), or "noting for next time" (we'll consider but won't necessarily action). Three priorities, no more. If everything is priority one, nothing is.
05 — Batch your feedback, don't trickle it.
Reviewing the course in one focused sitting and sending a single consolidated document is faster, cheaper, and produces better results than sending three emails over a week. Trickled feedback creates revision churn — we make changes, you respond to the changes, the next change conflicts with the first. Batched feedback lets us see the whole shape of what you want and address it in one pass.
06 — Resolve internal disagreements before they reach us.
If three stakeholders reviewed the draft and they want different things, we can't action all three. "The legal team wants more disclaimers, the L&D team wants fewer disclaimers, the comms team wants different disclaimers" lands at us as an impossible request. Resolve which team's view wins before sending feedback. We're happy to advise — sometimes a quick call with everyone in the room is the right move — but we shouldn't be arbitrating internal disagreements via revision rounds.
What to look at
Where to focus your review.
Reviewing an eLearning draft is genuinely hard — there's a lot to look at. A useful framing is to make three passes, each with a different question in mind.
First pass: Is this teaching the right thing?
Read the course as a learner would. Does it cover what you need it to cover? Does it match the learning outcome you agreed? Are there topics included that shouldn't be? Topics missing that should be? This is the structural pass — the questions that, if you raise them at the end of the review period, cost the most to address.
Second pass: Is this clear?
Could a learner who knows nothing about this topic follow it? Are technical terms defined? Are examples concrete? Where would the learner get lost or skip ahead? This is the clarity pass — the line-by-line read for what's working as writing and what isn't.
Third pass: Is anything broken?
Click every button, complete every quiz, open every accordion. Anything not working? Anything that should be different on mobile? Anything that the LMS won't handle? This is the functional pass — and it's the one most reviewers skip. The visible content gets attention; the interactive plumbing doesn't.
Patterns to avoid
Feedback patterns that don't help.
Some feedback patterns we see often, and that consistently don't move the project forward. None of these are bad-faith — they're easy mistakes — but they're worth recognising.
"Can we just try…?"
Speculative requests for "just trying something" sound low-cost but rarely are. Every "let's just try a different colour scheme" or "can we just see what it looks like with the modules reversed" is a real change with real downstream effects. If you have a concrete preference, name it. If you're not sure, say so — we can talk it through. The middle ground of "just try it" usually produces work that nobody wanted in the first place.
"Make it more engaging."
This is the most common piece of unactionable feedback in eLearning. "More engaging" can mean shorter, longer, more visual, more interactive, more conversational, more authoritative — depending on the speaker. If you find yourself wanting to write "more engaging", pause and try to write what specifically isn't working. "The introduction lost me — I'd want a hook in the first 30 seconds" is actionable. "Make it more engaging" is not.
"It needs to pop."
Sister to "make it more engaging." We don't know what "pop" looks like to you. Replace with a behavioural observation: "I want the call-to-action to stand out more — could it use a brighter button?" Or with a reference: "It should feel more like [example course or website]." Either gives us something to work with.
"I'll know it when I see it."
Fair as a feeling. Useless as feedback. If you genuinely can't articulate what you want, ask us to bring you 2-3 options to react to. That's much faster than making us guess and revise.
Re-opening settled decisions.
If a structural decision was made at kickoff (tone, format, audience, scope), changing it in revision is expensive. It's not impossible — sometimes new information legitimately calls for a rethink — but be aware of the cost, and flag it explicitly. "We've changed our mind on the audience and want it to address managers as well" is a scope change; treating it as a tweak doesn't make it one.
Effective feedback is specific, behavioural, prioritised, batched, and arrives after internal alignment. Skip the speculative tweaks, name the actual issue, sort the must-changes from the nice-to-haves, send one consolidated document instead of five trickling emails. Get this right and we'll close the project in one revision. Get it wrong and unlimited revisions becomes a phrase that means slow.