A lot of courses fail in the same way: they're accurate, well organised, and still don't stick. The learner finishes a lesson able to recite what they read, but not able to do anything with it.
This guide walks through how to design a course on Merve so that it teaches — not just informs. It's built on established instructional design research, translated into steps you can actually apply while building your course.
After reading this guide, you should be able to design an effective course in Merve — one that builds towards a clear outcome, teaches with worked examples instead of definitions, and ends in a certification submission learners are actually prepared for.
This is also how Merve's AI course-building agent is trained. If you use the AI agent to help build your course, it's already applying the steps below — starting from your outcome, sequencing modules, leading with examples, and building in checkpoints. Reading through this guide will help you get better results from the agent, since you'll know what it's aiming for and can steer it accordingly.
Compare two ways of framing the same course: "understand negotiation" against "structure a counter-offer that addresses the other side's stated priorities." Or "know Python basics" against "write a script that reads a CSV and produces a summary report." The second version in each pair is specific enough to check against — you can look at a lesson and ask whether it moves the learner towards that outcome. The first version can't do that job at all.
That's the one question to answer before you write a single lesson:
"After this course, the learner should be able to ___."
(You just saw this same move above, in this guide's own objective — "after reading this guide, you should be able to design an effective course in Merve." That's Step 1, applied to the document you're reading.)
This single sentence becomes your filter. As you plan modules, ask: does this lesson move the learner towards that outcome? If not, cut it — even if it's true and interesting. Courses that try to cover everything a topic contains, rather than everything the outcome requires, end up reading like a textbook instead of a course.
For Merve specifically: cutting something doesn't mean losing it. There's no limit on how many courses or resources you can create, so anything true and interesting that doesn't serve this course's objective can go into a library of additional reading, or become its own course entirely — rather than getting folded in here and diluting the outcome you're building towards.
If your course ends in a certification submission, work backwards from that submission. What will the learner need to be able to do to complete it successfully? Design every module as a step towards that, not as a separate topic to "cover."
Once you know the outcome you're designing towards, the next decision is how much you ask learners to take in at once.
Picture a lesson that introduces negotiation anchoring, walks through a worked example, and then adds "but note this doesn't apply if the other side has no walk-away option" — all in the same paragraph. Most learners will remember the exception and lose the concept it was attached to. That's because working memory can only hold a few new things at once: a lesson that introduces a new concept, a new example, and a caveat together asks for more than most learners can process in one pass.
Structure each lesson or module around one core idea. Practically:
If you find yourself writing "but note that..." or "however, in some cases..." partway through introducing something new, that's usually a sign the exception belongs in its own lesson, not folded into the first exposure.
Sequence modules simple → complex. Don't organise by category or alphabetically if it means a hard concept lands before the easy one it depends on.
Shorter, single-idea lessons that build on each other outperform long lessons that try to be complete in one pass.
Chunking solves the problem of a single lesson trying to do too much. It doesn't solve a different problem: a concept taught once, in one module, and never touched again, tends to fade.
Say your course teaches anchoring to objective criteria in module 2, using a vendor-negotiation scenario. Don't let that be the only time it appears. In module 6, put the learner in a salary negotiation and require them to anchor to objective criteria again — a new situation, not a reminder that the old one exists. That second exposure asks the learner to retrieve and apply the idea, rather than just recognise it.
This kind of spaced, varied repetition — sometimes called distributed or spaced practice — is one of the more strongly evidenced techniques in the learning research: bringing a concept back later, in a new context, produces more durable learning than teaching it once and moving on.
With lessons chunked to one idea, and revisited later in new contexts, the next question is how you introduce each one the first time.
Instead of:
"A counter-offer should anchor to objective criteria."
Try:
"Here's a real negotiation: the vendor asked for £50k, you asked for £38k, citing three comparable quotes. Notice what happened — the conversation moved off gut-feel numbers and onto criteria both sides could evaluate. That's what 'anchoring to objective criteria' means."
This is the worked example → general principle structure, and it's one of the most well-supported findings in learning research: people build durable understanding faster from seeing something worked through than from being told the rule first. For skills or procedures, take it a step further — show a fully worked example first, then a partially worked one where the learner fills in a step, then have them do the whole thing unassisted. That gradual handover (sometimes called "fading") is what a good course does across its modules, not just within one lesson.
Once a lesson opens with a concrete case, the next thing to check is whether it explains why that case works the way it does. Compare:
"Always confirm requirements before starting a project." (what)
"Always confirm requirements before starting a project — because the further into a project a misunderstanding surfaces, the more it costs to fix. An afternoon spent gathering requirements upfront is cheaper than a rebuild later." (what + why)
The second version is the one that sticks — a fact stated without a reason is forgettable. Every claim in your course should be followed by its mechanism: because, which is why, the reason this works is. If you can't complete that sentence, it's worth asking whether the claim belongs in the course at all, or whether you actually understand it well enough to teach it yet.
This is also one of the better-supported learning techniques in the research: prompting learners (or prompting yourself, as the course designer) to answer "why does this make sense" produces more durable learning than simply stating and restating facts.
With individual lessons each explaining their own reasoning, the next question is whether they connect to each other.
"In the last module you learned to identify the other side's priorities. Now we'll use that same information to build your counter-offer."
That one sentence does two things: it reinforces the earlier lesson through retrieval, and it signals that this module builds on the last one rather than starting cold. New information sticks when it attaches to something the learner already has in their head — which is why every lesson after the first should explicitly reference what preceded it. Skip this, and a course reads as a series of disconnected topics answering separate questions, rather than building towards something.
This is a different move from the spaced repetition in Step 3. That one is about resurfacing a concept several modules on, in a new context. This one is simpler: make sure each lesson explicitly acknowledges the lesson directly before it, so the course reads as one continuous line rather than a stack of separate topics.
Connecting lessons to each other isn't quite the same as telling the learner, upfront, why a module exists at all.
"Before you can write the counter-offer, you need to understand the other side's priorities — because a counter-offer that ignores them just restarts the standoff. That's what this module covers."
That one sentence of framing is what makes a course feel guided rather than like a stack of reference material the learner has to assemble themselves. Don't rely on headers alone to carry your course's logic — say the framing out loud, every time a new module starts.
Once the learner knows why a module matters, the module needs to ask something of them before it ends.
Take a module that's just taught counter-offer structure. Instead of closing with "to recap, a good counter-offer anchors to objective criteria and addresses stated priorities," close with: "Here's a new negotiation — write the counter-offer." The learner has to produce the skill, not recognise a restatement of it.
That's the pattern to repeat throughout the course. A closing summary that restates the lesson in fewer words adds little learning value — it's one of the least effective ways to reinforce material, according to a well-known review of learning techniques. What works better is requiring the learner to produce something, for example:
A short scenario, like the one above.
A self-check question that can't be answered by pattern-matching the previous paragraph.
A small piece of proof-of-work that maps towards your course's final certification submission.
If your course builds towards a certification deliverable on Merve, treat every module's checkpoint as a smaller rehearsal of that final submission — not a separate quiz bolted on afterwards.
How to build this on Merve:
Use an assessment activity to capture the learner's response directly in the module. Turn on AI grading so learners get feedback on their reasoning right away, rather than waiting until the end of the course to find out whether they've understood the idea.
For more hands-on or applied checkpoints, have learners download an example or template, complete it in their own time, and then use an upload activity to submit the finished work. You can review these submissions in the learner report, which is also the better fit when the checkpoint needs a human eye rather than automated grading.
With checkpoints built into every module, the last piece is making sure you're not delivering every explanation and every checkpoint in the same register.
Take the counter-offer module used throughout this guide. Explaining it means walking through why anchoring to objective criteria works. Modelling it means narrating a similar-but-different negotiation as you work through it, without handing over the answer. Practising it means handing the learner a new negotiation with progressively less guidance each time. Checking it means the closing task from Step 8, where the learner produces a counter-offer with no walkthrough at all.
Those are four distinct modes, and naming which one you're in — even just to yourself, while building the module — tends to produce clearer lessons:
Explaining — clarifying a concept, usually paired with an example.
Modelling — walking through a similar (but not identical) case so the learner sees the process, without handing them the final answer.
Practising — the learner does the thing, with decreasing levels of support as the course progresses.
Checking — a question or task that requires the learner to reconstruct the idea themselves, not recognise it.
A course that's all "explaining" reads like a textbook. Mixing in modelling, practice, and checkpoints at deliberate points is what makes a course feel like it's actually teaching a skill.
Definition-first lessons. If a lesson opens with "X is defined as..." before any concrete case, flip it — a definition with no example attached is exactly the pattern Step 4 warns against.
Everything-at-once modules. If a module covers the core idea and all its exceptions and edge cases, split it — cramming them together is the working-memory overload Step 2 describes.
Restated summaries. If your closing section just says the lesson again in different words, replace it with something the learner has to do — a recap doesn't ask for retrieval, and retrieval is what makes it stick (Step 8).
Disconnected modules. If a learner could complete module 4 without having done module 3, your sequencing needs work, or the course objective from Step 1 needs to be tighter — modules that don't reference each other read as separate topics rather than one course (Step 6).
Facts without reasons. Scan for sentences that state something true and then move on. Add the "because" — an unexplained fact is forgettable, which is the whole premise of Step 5.
I can state the course's outcome in one sentence: "After this, the learner can ___."
Every module traces back to that outcome.
Each lesson introduces one new idea, not several at once.
Key concepts resurface in a new context later in the course, not just once.
At least one worked example appears before any general rule or definition.
Every key claim has a stated reason ("because...").
Each module explicitly references the one before it.
The course tells learners why each module matters before diving in.
Modules end with something to do, not something to reread.
The final certification submission is rehearsed in smaller form throughout the course, not introduced cold at the end.
