How do you convert PowerPoint training into eLearning?

Who this answer is for

This is for whoever was handed a slide deck and asked to “make it eLearning”: an L&D specialist inheriting a deck from a departing trainer, an agency project manager scoping a conversion, or an operations or compliance owner whose programme lives as a folder of decks on a shared drive. If the deck is sound and the goal is only an auditable completion record, straight packaging is rational. What follows is the design work underneath it — deciding what the deck should become.

Why the answer changes by context

A slide deck is not a course. It is a prompt sheet for someone standing in the room: most of the instruction lived in that person’s narration, the questions they fielded and the examples they chose. Convert the file and you convert the prompt sheet while leaving the instruction behind. That mechanism, rather than any deficiency in the authoring tool, is what makes a converted deck feel hollow. Recovering what went missing is interview work, starting with the questions worth asking subject-matter experts.

Four factors change the correct destination for a given piece of deck content.

• Moment of use. Content needed while doing the task belongs at the task, not in a module finished months earlier.
• Volatility. Inside a published package, every change costs a rebuild and a re-upload.
• Consequence of error. Costly or regulated mistakes need practice and evidence, not exposure.
• Whether judgment is involved. Rules can be looked up; judgment about exceptions is built through discussion and worked cases.

So the same 60-slide deck can produce a two-page job aid in one organisation and a scenario-based module in another. The deck did not change; the moment of use and the consequence of error did.

The Deck Triage Tree: five routing destinations and a cross-cutting evidence pass

The tree has one deliberate bias: its tests run from cheapest destination to most expensive, so a block reaches “self-paced module” only by failing to qualify for anything cheaper. That ordering is professional judgment about where conversion budgets are wasted, not a measured finding. The reasoning is not new — performance-support practice has long argued for routing by moment of use rather than defaulting to a course. What the tree adds is a fixed order, a stop rule and a named owner per destination.

Step 0 — segment before you route. Route content blocks, not slides: the smallest set of slides making one complete point — one rule, one procedure, one decision, one claim. As a heuristic, blocks run one to six slides. Slide-level routing is the path of least resistance, since slides come pre-numbered while block boundaries must be judged, and its cost is a module shaped exactly like the deck.

Pass 1 — route every block through the five tests in order, stopping at the first that fires. The stop rule is what makes the ordering mean anything: a block qualifying for a job aid is never also evaluated for a module.

1. The Consequence Test. Does anyone act differently because of this block, or must a rule record its delivery? If neither, the destination is delete — out of the build, source slides kept in an archive file rather than discarded. Agendas, org charts and the third restatement of a summary exit here, as does any block that fires no later test.
2. The Point-of-Need Test. Is it needed while doing the work, and lookupable rather than recallable? If yes, the destination is a job aid. This one is easy to skip past, because a job aid does not look like a deliverable to a stakeholder who asked for a course. Thresholds, codes, escalation contacts and step sequences belong here, and the patterns for building them well run through our writing on support delivered at the point of work.
3. The Volatility and Volume Test. Is the block long, exhaustive, or revised more than once or twice a year? If yes, the destination is a reference page in a maintained, searchable location: policy text, product matrices, field definitions. That threshold is a planning heuristic, not an evidence-based rule; adjust it to how painful republishing is for you.
4. The Judgment Test. Does the block need weighing trade-offs, handling exceptions or reading a situation? If yes, the destination is an instructor-led or live virtual segment. For small or infrequent audiences, grey areas are usually cheaper to teach through discussion of real cases than through branching built in an authoring tool; that reverses as audience size and frequency rise, because facilitation recurs and a build does not. Judge it on your delivery volume.
5. The Recall and Practice Test. Must the person hold this in their head and apply it consistently, with practice and feedback at a scale live delivery cannot serve? If yes, the destination is a self-paced module — the only one justifying full development cost, the only one needing a full eLearning storyboard, and the only one producing an LMS-tracked package.

Pass 2 — the Evidence Test. Once every block has a destination, run one further test across all of them, wherever they landed: must someone demonstrate competence, or must an audit hold a record? Where yes, the block also generates an assessment item — an overlay, not a sixth destination. A job aid can carry an observation checklist, a live segment a facilitator sign-off, a module a scored scenario. The separate pass is deliberate: under the Pass 1 stop rule a block routed at test 2 would never reach a sequential evidence test, and cheap destinations are often the ones under audit.

After routing, re-sequence by destination rather than slide order, write objectives and assessment from the routed blocks, and list what the deck never said: failure modes, common errors, what good looks like, what to do when the system is down. Those gaps are expected in learning content rescue work and usually hold the value. Give every artifact an owner and a review date, or the set rots back into a deck. Timelines for the module work are in how long it takes to build a course.

Accessibility and packaging targets

Deck source is a common origin of accessibility defects, because tables, charts and status colours arrive as flat images with no text alternative and no reading order. Set the target from your obligation, not the newest specification. WCAG 2.2 is the current W3C Recommendation defining testable success criteria, but regulatory regimes incorporate specific versions: the Revised Section 508 Standards incorporate WCAG 2.0 Level A and AA by reference, and EN 301 549 references WCAG 2.1 Level AA. Confirm which your contract or regulator names before setting a conformance target, then apply the criteria described in what makes eLearning accessible. Packaging concerns only the module destination: SCORM 2004 4th Edition (Advanced Distributed Learning) defines how content is packaged, launched and tracked by an LMS, while xAPI records experience data to a learning record store and does not specify packaging or launch.

A worked example (hypothetical)

This scenario is constructed to show the method; it describes no real client. A manufacturing operations team holds a 74-slide deck, “Supplier Onboarding and Approval”, delivered twice a year by a manager who is retiring. The request is “turn it into eLearning before she leaves”. Segmentation produces 30 content blocks; Pass 1 routes all 30.

• 12 deleted at the Consequence Test: agenda, department history, org chart, photo montage and three shortening restatements of the approval summary. Those slides stay in the archived source file.
• 6 to job aids: approval thresholds, required-documents checklist, escalation contacts — two cards and one page linked from the procurement system.
• 4 to reference pages: supplier policy text and category definitions, revised whenever procurement rules change.
• 3 to an instructor-led segment: handling an important supplier that fails one approval criterion — judgment, and exactly what leaves with the retiring manager.
• 5 to a self-paced module: the approval sequence and its four decision points, as a scenario with feedback.

The counts reconcile — 12 + 6 + 4 + 3 + 5 = 30 — and no block failed all five tests, so none reached the archive by default. Pass 2 then attaches assessment items to 2 already-routed blocks, one job aid and one module block, because approval authority is auditable: an observation checklist held by the line manager, and a scored scenario in the module. Neither leaves the destination Pass 1 gave it.

The honest reading: the module is the smallest deliverable in the set, the job aids are what people touch weekly, and the highest-risk content was never in the deck. It was in the manager’s head, and it needed a recorded conversation and a case pack, not a conversion.

Closing decision table

Sources and review note

Editorial owner: IETERNUS Learning Systems. Last updated: 8 August 2026. Reviewed whenever the referenced standards are revised, and otherwise annually.

Established fact. The standards positions above are as published: WCAG 2.2 (W3C Recommendation), the Revised Section 508 Standards incorporating WCAG 2.0 Level A and AA by reference, EN 301 549 referencing WCAG 2.1 Level AA, SCORM 2004 4th Edition on packaging, launch and LMS tracking, and xAPI on recording experience data.

Professional judgment. The Deck Triage Tree is an IETERNUS planning heuristic: its five destinations, the cheapest-to-most-expensive ordering, the stop rule, the second-pass Evidence Test, the one-to-six-slide block definition, the volatility threshold, the maintenance owners and the closing table mappings. So are the claims that the job-aid destination is easy to skip past, that slide-level routing is the path of least resistance, that deck source commonly carries accessibility defects into the build, and that a converted deck feels hollow because the narration was left behind. Those are arguments about mechanism, not measurements of how often such things happen.

Assumption. The worked example is hypothetical. Its counts and routing are illustrative, and no real organisation, project or outcome is described in this article.

Learning topic: Performance Support and Job Aids