Design an e-learning module

Most self-paced e-learning is "click next" reading with a quiz at the end: it informs, but it rarely changes what people do. Modules that work are built backwards from the behaviour on the job, use realistic decisions and scenarios rather than click-to-reveal, follow the evidence on multimedia learning (cut what is not needed, signal what matters, do not read on-screen text aloud word for word, break content into learner-paced segments), and are accessible from the start, not retrofitted.

Design a self-paced module of about 20 minutes on this topicOnly if [AUTHORING_TOOL] is given: , to be built in [AUTHORING_TOOL].

Only if [AUDIENCE] is given:

1. Design summary: the performance goal (what learners will do differently on the job), who the learners are, and whether e-learning is the right fix. If the problem is really a process, tool or motivation issue, say so briefly.
2. Objectives: 2 to 5 objectives with observable verbs, each tied to the performance goal.
3. Module structure: sections with estimated minutes that add up to about 20. Allow roughly one minute per content screen and more for scenarios. Open with relevance (a realistic situation or a problem), not a list of objectives.
4. Storyboard: every screen in order. For each: on-screen text (short), narration if any (complementing, not duplicating, the on-screen text), visuals, the interaction and its purpose, branching and feedback, and notes for the developer. Prefer interactions that make learners decide (scenarios with consequences, sorting, spotting the error) over click-to-reveal and drag-and-drop for its own sake.
5. Knowledge checks: at least one per objective, at application level, written as realistic situations. Give each option tailored feedback that explains why, and state the completion and passing criteria.
6. Accessibility: to WCAG 2.2 AA: captions and transcripts for audio and video, alt text for meaningful images, keyboard operability for every interaction (with an accessible alternative to drag-and-drop), colour contrast and no meaning carried by colour alone, no time limits, readable plain language and reading order. Note any interaction that needs an alternative.
7. Developer notes: tracking (completion and score as SCORM or xAPI, according to the LMS), assets to source or create, variables and branching logic, and points to check with a subject-matter expert.

• Base content on the source material given; mark anything you added from general knowledge so a subject-matter expert can verify it, and never invent policy details, figures or legal requirements.
• Keep interactions feasible for the stated tool; if you are not sure the tool supports something, say "check that your tool supports this" rather than asserting it.
• If the topic is too large for 20 minutes, propose a series of shorter modules and design the first.
• Write for the audience's reading level and language background.

Use the section headings from the output contract. Module structure as a table: Section | Objective | Minutes. Storyboard as a table: Screen | On-screen text | Narration | Visual | Interaction and feedback | Dev notes. Knowledge checks as numbered items with options and per-option feedback.