Sending an e-learning course out for review when the reviewer has no LMS (2026)

Every instructional designer knows this stretch of the project. The course is built. It's good. And now it has to get in front of someone who has to approve it — a client's marketing lead, a subject-matter expert in a lab somewhere, a compliance officer who has thirty minutes on Thursday.

None of them have an LMS. None of them are getting a seat in Storyline. And the delivery method you have to hand is the one everyone defaults to: publish, zip, attach, and write an email explaining which file to double-click.

That email is where review cycles go to die.

Why the attachment path fails so reliably

It's worth naming the two separate failures, because they get blamed on each other.

The size failure is loud. A published course carrying audio and video routinely runs into the tens of megabytes. Mailbox attachment limits sit below that more often than not, so the message bounces, or worse, the attachment is quietly stripped and the reviewer replies asking where the file is. This one at least announces itself.

The local-filesystem failure is quiet, and it's the one that actually costs you the week. The reviewer gets the ZIP, unpacks it, and double-clicks. Sometimes they pick the wrong file. Often they pick the right one and still get a blank page or a course with missing assets, because a browser opening a page from a local folder enforces restrictions that don't apply to a page served over the web. From the reviewer's side, this reads as "the course is broken." From your side, it reads as "it works fine on my machine." Both are true, and the next three emails are spent establishing that.

This is the same shape as emailing a ZIP versus sending a hosted link in any discipline — e-learning just hits it harder, because published courses are bigger and more path-dependent than most things people zip.

Publish for Web, not for LMS

The fork happens at publish time, and it's worth being precise about what each output is for.

Publish for LMS produces a SCORM or xAPI package. That package is built to be imported into a learning platform, and it expects to talk to one while the learner is inside it — reporting progress, scores, completion. Handed to someone without an LMS, it does nothing useful. It isn't a course you can open; it's a course wrapped for a machine that isn't there.

Publish for Web produces a folder: an entry page — story.html in Storyline, index.html in most others — plus the assets, scripts, and media it references. That folder is a real static site. Served over the web, it runs on its own: interactions, branching, audio, quiz logic, all of it, client-side, no platform required.

For a review hand-off, the web output is the one you want. It's also the one that survives the reviewer having no software, no login, and no patience.

Zip the folder — the whole folder

The most common self-inflicted wound here is sending the entry file alone. story.html is not the course; it's the door. Everything behind it is referenced by relative path, and those references break the moment the file is separated from its siblings.

So zip the output folder as a unit. Then don't unpack and rearrange it before uploading — the internal structure is what makes the paths resolve.

A decent host will handle two things automatically, and both matter for e-learning output specifically: it should strip a redundant wrapper folder if the ZIP has one, and it should find the entry page even when it isn't named index.html. Storyline's story.html is the obvious case. If a host insists on index.html at the root, you'll be renaming files and hoping nothing internal referenced the old name.

What this deliberately gives up

Here's the honest boundary, and it's better to say it out loud than to let someone discover it in front of a compliance auditor.

A link does not give you completion tracking. No scores, no SCORM reporting, no xAPI statements, no "did Marcus finish module 3." All of that is a live conversation between the course and an LMS. Remove the LMS and the conversation doesn't happen — not because the host is missing a feature, but because there's nobody on the other end of the line.

So the split is clean:

• Graded, tracked, certified, compliance-bound? That belongs in an LMS, or in your authoring vendor's own hosted delivery, which is purpose-built for it. Don't try to route around this.
• Review, sign-off, walkthrough, portfolio? Nobody is being graded. There is nothing to track. The tracking layer is overhead you're paying for in reviewer friction — an LMS seat, a login, an import step — to record a completion nobody will ever read.

What you do get on the review side is an access log: the link was opened, and when. For chasing an SME who has gone quiet, that's the actually useful signal — it tells you whether you're waiting on a review or waiting on someone who hasn't opened it yet. It's the same instinct behind treating a link open as a follow-up signal in any client workflow.

Scoping the link to the engagement

Two controls do most of the work on client courses.

A password, when the content is under NDA. The link is already unguessable and off search, which handles discovery. A password handles the case where the URL itself gets forwarded — the course is held back until the passphrase checks out, rather than after the contents have already been delivered. (The difference between those two models is worth understanding if you're protecting anything real: see how password protection on a link actually works.)

An expiry, so the review copy doesn't outlive the project. A course you handed a client in March shouldn't still be sitting at a live URL in November — not because anything bad happens, but because you no longer know what's on the other end of a link you've forgotten about.

And re-publish over the same link as you revise. This is the underrated one. The SME who bookmarked the URL in week one lands on the current cut in week four, and the entire genre of "I reviewed v3, is that the latest?" simply stops happening.

The shape, end to end

1. Publish for Web.
2. Zip the output folder.
3. Drop the ZIP on a host that unpacks it and serves it at a link.
4. Password it if it's under NDA; expire it with the engagement.
5. Send one URL.
6. Re-publish over it as you revise.

The reviewer's experience is a link and a running course. No LMS, no seat, no download, no unzip, no "which file do I open."

That's the whole job — and everything the LMS was doing in this workflow was overhead you were paying for a report nobody was going to read.

The other half of this — what a SCORM package actually is, and why it's the wrong artefact to hand a human — is worth its own read if you've ever been asked to "just send me the SCORM file": a SCORM package vs a plain web link.