eLearning

Summary

Tool selection in eLearning is not a quality decision — it is a constraints decision. Rise 360 is the right default for most content because it is fast, platform-agnostic, and maintainable; Storyline is the right tool for interactive simulations when a Windows-capable developer is available and the underlying software is stable enough to justify the build cost. The dominant failure mode across both clients is treating these tools as interchangeable, which produces either over-engineered content that breaks on laptops or under-engineered content that fails to build procedural competency. The second most costly failure is fragmented feedback workflows: when review comments scatter across email, Word documents, and Review 360 simultaneously, version confusion and rework follow predictably. For organizations building a training function from scratch — as Agility Recovery did — the structural decisions (delivery format, module length, facilitation model) matter more than content quality in the first iteration.

Current Understanding

The central tension in eLearning delivery is between production speed and learning depth. Rise 360 optimizes for speed; Storyline optimizes for depth. Neither is universally correct, and the evidence from Agility Recovery's SOAR program shows what happens when that choice is made without accounting for team capability, device constraints, and content volatility.

Tool Selection: Rise 360 vs. Storyline

Rise 360 is faster to build and runs in-browser on any operating system. Storyline produces more interactive, simulation-capable content but is a Windows-only desktop application — macOS users cannot edit Storyline files ^[1]. This is not a minor inconvenience: at Agility Recovery, the PC-only requirement blocked 4 of 11 modules from development when the assigned designer (Isalia) was working from a Mac ^[2]. As of December 11, 2025, 7 of 11 modules were near-final while those 4 remained blocked.

Storyline courses are also costly to maintain when tool interfaces change, making them a poor fit for training on software that receives frequent UI updates ^[3]. The original SOAR scope included four Storyline tool-training courses (ZoomInfo, Salesforce 101, Salesforce 102, Sales Loft); all four were eventually pivoted to Rise + video due to skill gaps, hardware constraints, and maintenance concerns ^[4]. Video recordings occupy a practical middle ground — faster to produce than Storyline simulations, more demonstrative than Rise text blocks — and became the de facto format for tech stack training at Agility Recovery ^[5].

The decision rule that emerges: use Storyline when a Windows-capable developer is available, the underlying software is stable, and the interaction complexity justifies the build time. Use Rise + video otherwise.

Content Architecture: Module Length, Block Distribution, and Structure

The target module length for Rise 360 courses is 15 minutes or less ^[6]. Most SOAR courses were designed to this target, with explicit exceptions for skills-heavy content: Course 8 (Copilot) was approved at 30–35 minutes because it precedes a live virtual session and requires genuine skill-building, not just awareness ^[7].

The recommended content block distribution for Rise 360 is approximately 65% text blocks, 20% interactive elements, 10% knowledge checks, and 5% media ^[8]. In practice, Agility Recovery's modules 1–3 landed at 42 text blocks, 22 knowledge checks, 15 interactive tabs, 12 accordions, 12 statement blocks, 8 quotes, 12 lists, 1 image, and 1 gallery — a higher proportion of interactive elements than the guideline, validated intentionally for that content type ^[8]. The principle behind the guideline is not a hard ratio but a warning against over-gamification: overuse of flip cards and drag-and-drop interactions makes courses feel toy-like and dilutes the learning signal ^[8].

Fragmented module structures create redundancy and break learner flow. At Agility Recovery, multiple modules were consolidated mid-project based on feedback, and the audience scope was broadened from sales-only to all roles ^[9]. Three courses (4, 6, and 10) required substantial restructuring; courses 11–13 exceeded the time target and required content consolidation ^[10].

Tool Training: Why Passive Video Fails

Passive video training does not build procedural competency for software tools. Learners who watch a Salesforce walkthrough video cannot reliably replicate the workflow under pressure ^[11]. At Agility Recovery, Salesforce training errors consumed a full week of Gus Donelson's management time addressing critical user mistakes — the direct consequence of insufficient hands-on practice ^[12]. This elevated interactive Salesforce training to the top development priority.

When learners cannot access live production systems, interactive click-through simulations in Storyline provide a safe alternative for teaching tool fundamentals ^[13]. The constraint is that Storyline simulations embedded within Rise 360 render at a fixed, unreadable size on laptops — Gus Donelson could not evaluate the Salesforce simulation because it was too small to read on his device ^[14]. The resolution was to deliver Storyline simulations as standalone modules rather than embedded blocks.

Facilitation Architecture: 1-on-1 vs. Cohort Models

The SOAR program was originally designed as a 4-week intensive with cohorts of 10–15 learners. It was redesigned to a 2-week part-time format with 1-on-1 or 2-on-1 delivery after the team discovered that Agility Recovery's actual onboarding practice was individual, not cohort-based ^[15]. This is the most consequential structural decision in the project: the original design would have produced content that didn't match how training was actually delivered.

In 1-on-1 or small-group virtual formats, the facilitator-led debrief is the primary learning mechanism — not the e-learning module itself ^[16]. This shifts the design priority toward facilitator guide quality. Facilitator guides must be lightweight and actionable for ad-hoc use, not comprehensive reference manuals ^[17]. The initial participant guide draft at Agility Recovery was 37 pages — deemed too long and redesigned as a streamlined digital-first document ^[18].

Review and Collaboration Workflow

Rise 360's review workflow has two distinct failure modes. First, edits made in Rise 360 are not automatically visible to external reviewers — a new version must be explicitly published, and a separate "Re-request Review" action must be sent ^[19]. Second, sharing a course via Review 360 does not make it appear in the client's Rise 360 dashboard; for licensed clients, adding them as a Collaborator/Editor via the Share menu is the correct approach ^[20].

Both failure modes were encountered at Agility Recovery. The resolution was to consolidate all feedback into Rise 360 comments as the single source of truth, abandoning the parallel email/Word/Review 360 channels that had accumulated during early project phases ^[21]. A two-track workflow reduces rework: document feedback for modules still in content planning, Review 360 for modules already built ^[8].

What Works

Standalone Storyline modules for software simulation training. When learners need to practice tool workflows without access to live systems, Storyline click-through simulations build procedural competency that passive video cannot. The critical constraint is delivery format: Storyline must be published as a standalone module, not embedded in Rise 360, where it renders at an unreadable fixed size on laptops ^[22].

Rise 360 as the default authoring tool for conceptual and process content. Rise 360's browser-based, platform-agnostic architecture eliminates the Mac/PC blocker that stalled 4 of 11 Agility Recovery modules. For content that doesn't require branching simulations, Rise produces acceptable learning outcomes faster and at lower maintenance cost than Storyline ^[23].

Redesigning onboarding programs around actual delivery format before building content. The SOAR program's most expensive rework came from designing for cohort delivery when the actual model was 1-on-1. Confirming delivery format — group size, synchronous vs. asynchronous, facilitator expertise level — before authoring saves structural revision cycles ^[15].

Facilitator guides with embedded answers for non-expert facilitators. Hybrid participant/facilitator guides that include suggested answers and debrief questions are more effective than separate documents when facilitation may be handed off on short notice ^[24]. Applied discussion questions ("How would you explain this on a call?") outperform open-ended prompts ("What stuck out to you?") ^[18].

Single-platform feedback consolidation in Rise 360 comments. Consolidating all review feedback into Rise 360 comments eliminates version confusion from parallel channels. The workflow requires discipline to enforce — at Agility Recovery, early feedback was fragmented across email, Word, and Review 360 before the team aligned on a single channel ^[25].

Repurposing in-person events for authentic content production. The January 2026 SKO was used to capture authentic video segments, B-roll, and leadership content rather than relying on remote submissions or AI-generated imagery ^[26]. This produces higher-quality video assets and avoids the audio/visual quality issues that plagued remote recordings (Isalia's video segments required re-recording due to crackling audio from a poor internet connection ^[27]).

Matching content block type to content type. Conceptual content belongs in text blocks; lists belong in accordions; comparisons belong in tabs. Using interactive elements for variety rather than for structural fit produces courses that feel inconsistent and dilutes the signal of genuinely interactive moments ^[8].

Inclusive first-person language for internal employee training. "We/us" framing reinforces belonging and shared ownership for internal audiences. Role-specific language should use third-person framing in all-audience courses to avoid excluding learners who don't hold that role ^[28].

Scenario accuracy validation against actual product/service offerings. Scenarios must reflect services the company actually offers. At Agility Recovery, a UPS systems scenario was removed from the Storytelling module because Agility Recovery does not offer UPS systems; it was replaced with accurate response time and on-site generator references ^[29]. It is also acceptable — and realistic — to model "we're not the right fit" responses in sales training scenarios.

Acronym definitions scoped to each module. Defining acronyms fully on first use within each course, rather than assuming carry-over from prior modules, improves comprehension for learners who complete modules out of sequence ^[30].

What Doesn't Work

Embedding Storyline blocks inside Rise 360 for laptop-primary audiences. Storyline blocks render at a fixed size within Rise 360 that is unreadable on standard laptop screens. Agility Recovery's sales team uses laptops as their primary device, which made the embedded Salesforce simulation unusable for the primary audience ^[22]. Standalone Storyline modules or video are the correct alternatives.

Passive video for procedural software training. Video walkthroughs of tool interfaces do not produce the muscle memory required for correct workflow execution. The Salesforce training failure at Agility Recovery — where user errors consumed a full week of management time — is the direct evidence ^[11].

Designing for cohort delivery without confirming actual delivery format. The SOAR program's original 4-week cohort design required a full structural redesign when the team discovered Agility Recovery delivers onboarding 1-on-1. This is recoverable but expensive ^[15].

Managing review feedback across multiple channels simultaneously. When feedback arrives via email, Word documents, Slack, and Review 360 in parallel, version state becomes ambiguous and unresolved comments accumulate. At Agility Recovery, this was the default state early in the project before the team enforced single-channel consolidation ^[25].

Assuming Rise 360 review links auto-update. Publishing a new version in Rise 360 does not notify reviewers, and re-sharing an old review link does not show updated content. Both failures create situations where reviewers are commenting on outdated material ^[31].

Over-gamifying Rise 360 courses with interactive elements. Flip cards, drag-and-drop interactions, and other gamification elements used for variety rather than learning reinforcement make courses feel toy-like and reduce professional credibility ^[8].

Building Storyline courses without a Windows-capable developer confirmed. Storyline development blocked 4 of 11 Agility Recovery modules when the assigned designer was Mac-only. This is a project planning failure, not a tool failure — but it is predictable and preventable ^[2].

Comprehensive participant guides as printed workbooks. A 37-page participant guide is not actionable in a 1-on-1 onboarding session. Digital-first, streamlined guides that direct learners to information rather than reproducing it inline are more effective for the actual use context ^[18].

Patterns Across Clients

IT and access blockers are the primary cause of schedule slippage in eLearning projects. At Agility Recovery, SharePoint/M365 access delays blocked the Tech Stack module; the Storyline PC-only requirement blocked 4 modules; the SOAR program was originally scoped as a 14-week engagement and was still nearing completion as of April 2026 ^[32]. These blockers are described as a "recurring theme throughout the project." Access requirements — platform licenses, OS compatibility, system credentials — should be confirmed and resolved in week one, not discovered mid-development.

Tool selection decisions made at project start become structural constraints that are expensive to reverse. At Agility Recovery, the original plan to build four Storyline tool-training courses was reversed mid-project, requiring redesign of the affected modules ^[33]. The Co-pilot module was built in Storyline, then scrapped and redistributed to Rise blocks and live facilitated sessions ^[34]. Tool selection should be locked after confirming developer OS, content volatility, and target device — not assumed from the initial scope.

Content quality is bounded by the client's internal organizational clarity. When product or service definitions are ambiguous or undocumented, course content inherits that ambiguity ^[35]. At Agility Recovery, outdated or missing product documentation created high-risk deliverables ^[13]. The UPS systems scenario error is a direct example: the content team built a scenario around a service the client doesn't offer because the source material was unclear ^[29]. A content accuracy review against actual product/service documentation is not optional.

Aspirational launch dates function as alignment tools, not commitments. At Agility Recovery, the January 11 SKO launch target was explicitly reframed as a "shoot for the stars" goal; February was identified as the realistic first-use window; the client confirmed no pressure before new hires arrived in February–March ^[36]. This pattern — setting an aspirational date to create momentum while maintaining flexibility — appears to be a deliberate project management approach rather than a failure.

Specialized Storyline development requires a separate resource allocation, not a general course developer. At Agility Recovery, Raphael was brought in separately for Storyline work; the Tech Stack module pivoted from Storyline to video when that specialized resource wasn't available on schedule ^[37]. Scoping a project that includes Storyline simulations without confirming a dedicated Storyline developer is a resourcing gap.

Client feedback style shapes the interpretation workflow more than the feedback tool. At Agility Recovery, Gus Donelson's feedback style is stream-of-consciousness inline comments. The team developed a working rhythm of interpreting and integrating that feedback rather than treating it as literal instructions ^[9]. Iterative touch-base calls that translate unstructured input into consolidated action items reduced rework more than any platform change.

Two-phase learning architecture (onboarding + continuous education) is the intended end state for organizations building a training function from scratch. Agility Recovery's SOAR program covers foundational onboarding; the planned Elevate program adds a monthly continuous education cadence post-SOAR ^[38]. This architecture is not yet contracted, but it reflects the client's stated direction and Gus Donelson's acknowledgment that Rise is "fast to produce but not deeply engaging" — the primary motivation for SOAR 2.0 and Elevate ^[39].

Sales playbooks and job aids should be referenced in course content, not duplicated. Duplicating job aid content inside course modules creates a maintenance problem: when the playbook updates, the course content becomes stale. At Agility Recovery, Sales Playbooks are referenced as external job aids rather than reproduced inline ^[40].

Exceptions and Edge Cases

The 15-minute module length guideline has a legitimate exception for pre-session skill-building content. Course 8 (Copilot) was approved at 30–35 minutes because learners complete it immediately before a live virtual session, and the content requires genuine skill-building rather than awareness transfer ^[7]. The exception is justified by the delivery context, not by content volume alone.

Interactive element ratios can exceed the 20% guideline when content type warrants it. Agility Recovery modules 1–3 landed at a higher proportion of interactive elements (15 tabs, 12 accordions) than the guideline recommends, and this was validated intentionally ^[8]. The guideline is a warning against over-gamification, not a hard cap. Content with many discrete comparable items (product features, process steps, role comparisons) legitimately benefits from higher interactive element density.

Hands-on practice with variable outputs belongs in instructor-led sessions, not e-learning modules. Co-pilot prompt exercises — where outputs vary by input and there is no single correct answer — are better suited to live facilitated sessions than to Rise 360 modules ^[41]. This is the reason the Co-pilot Storyline module was scrapped: the interaction type didn't fit the medium.

For modules still in document/planning stage, feedback in the source document is preferred over Rise 360 comments. The two-track feedback workflow applies a different channel depending on build status: document feedback before build, Rise 360 comments after build ^[8]. Applying Rise 360 comments to pre-build content creates rework when the structure changes.

Regulatory compliance for online training certificates requires state-level verification before marketing. For AHS's professional training content (mold/asbestos awareness, environmental hazard training), certificate validity varies by state — particularly California, which has stricter requirements ^[42]. This is a pre-launch verification step, not a post-launch correction.

Course 7 (Prospect Researching) is the only SOAR module with no active development timeline. All other 12 courses are in active development, review, or complete. Course 7's pause has no documented resumption date ^[10].

Evolution and Change

The Agility Recovery SOAR program began in mid-2025 as a 14-week engagement with a relatively conventional scope: Rise 360 modules for conceptual content, Storyline simulations for tool training, cohort-based delivery. By late 2025, all three of those assumptions had been revised. The cohort model was replaced by 1-on-1 delivery; the Storyline tool-training scope was reduced from four courses to one (Course 8); and the Tech Stack module pivoted from Storyline simulations to screen-capture video. These are not failures — they are the expected output of a project that started with incomplete information about delivery context and team capability.

The most significant mid-project change was the recognition that Rise 360 is the correct default tool for this client's context, not a fallback. Gus Donelson's own assessment — that Rise is "fast to produce but not deeply engaging (really just reading)" — reflects an accurate understanding of the tool's limitations ^[39]. The planned SOAR 2.0 and Elevate program represent the client's intent to move beyond Rise-only delivery toward a blended model with higher engagement depth. That evolution is not yet contracted as of April 2026.

The Arctic Wolf IR Jumpstart Retainer, launched February 2026, introduced a split-LMS model (Arctic Wolf LMS for content delivery, Agility LMS for assessment) ^[43]. This is the first evidence of a multi-LMS architecture in the portfolio and may signal a pattern for clients who deliver training through partner channels.

The broader signal from this engagement period is that organizations building a training function from scratch (Agility Recovery had no prior dedicated training function and Gus Donelson is its first Learning Leader ^[39]) require more structural design work — delivery format, facilitation model, feedback workflow — than organizations with existing L&D infrastructure. The content itself is secondary to getting the architecture right.

Gaps in Our Understanding

No evidence from organizations with existing L&D infrastructure. All eLearning observations come from Agility Recovery (first-time training function) and AHS (LearnDash setup). Patterns around tool selection, facilitation architecture, and feedback workflow may not transfer to clients with established instructional design teams and existing LMS configurations.

No data on learner completion rates or knowledge retention outcomes. The SOAR program has produced 13 courses, but there is no evidence in the portfolio on whether learners complete modules, pass knowledge checks, or retain content at 30/60/90 days. Without this, the content quality assessments are based on design principles, not outcome measurement.

The Elevate continuous education program is planned but not contracted. The two-phase architecture (SOAR + Elevate) is the stated direction, but Elevate has no confirmed scope, timeline, or content structure ^[44]. If Elevate is contracted, the patterns from SOAR may or may not transfer to a monthly cadence model.

No evidence on LearnDash at scale beyond AHS's initial setup. The LearnDash observations cover course structure, sequential unlocking, and certificate compliance considerations ^[42]. There is no evidence on LMS administration, learner management, or reporting at any meaningful scale.

The split-LMS model (Arctic Wolf + Agility) has no follow-on evidence. The IR Jumpstart Retainer launched in February 2026 but there are no fragments documenting how the split-LMS architecture performed in practice — whether the handoff between platforms created friction, whether assessment data was usable, or whether the model is replicable ^[43].

No evidence on SOAR 2.0 design. The client's intent to move beyond Rise-only delivery is documented, but there is no evidence on what SOAR 2.0 would look like structurally, what tools it would use, or what the engagement model would be.

Open Questions

Does the 15-minute Rise 360 module length guideline hold for all content types, or is it specifically a fatigue threshold for text-heavy modules? The exception for Course 8 (Copilot, 30–35 minutes) was justified by delivery context. It's unclear whether the 15-minute guideline is a cognitive load limit or a design convention.

What is the correct threshold for choosing Storyline over video for tool training? The evidence shows Storyline is better for procedural competency and video is better for awareness, but the decision criteria for the middle ground — tools with moderate complexity and moderate update frequency — are not well-defined.

How does Rise 360's engagement depth compare to Storyline for conceptual (non-procedural) content? Gus Donelson's characterization of Rise as "really just reading" may be accurate for the SOAR content as built, but it's unclear whether that's a tool limitation or a content design limitation.

What LMS configuration is appropriate for organizations scaling from a single-team training function to company-wide deployment? SOAR was designed for sales onboarding but is intended to scale across all departments ^[39]. The LMS architecture, permissions model, and reporting structure for that scale-up are undocumented.

Does the split-LMS model (partner LMS + client LMS) create meaningful friction for learners? The Arctic Wolf IR Jumpstart Retainer uses this model, but there is no learner experience data ^[43].

How should facilitator guide design change when facilitation is handed off to subject matter experts rather than trained facilitators? The current guides are designed for Gus Donelson or similarly informed facilitators. The pattern for non-expert facilitators is documented as a preference for hybrid guides with embedded answers ^[24], but the full design implications are not explored.

What is the minimum viable Storyline developer skill level for producing usable simulations? The evidence shows that Storyline requires specialized expertise separate from general course development ^[13], but the skill threshold is not defined.

Related Topics

• Instructional Design
• Project Management
• Articulate 360
• Learndash
• Feedback Workflows

Sources

Synthesized from 48 Layer 2 articles, spanning 2025-09-26 to 2026-04-05.