The challenge
The model looked simple on paper. US instructional designers would build the storyboards in Confluence, attach the visuals, and define the learning flow. The India eLearning development team would build the modules in Storyline 360.
The hard part was the handoff. A storyboard that felt clear to the ID could still leave room for a developer to interpret interaction behavior, screen layout, or feedback logic differently.
The process took several weeks and a few iterations to get right. It was painful at times. Tensions got high when people felt their part of the work was being judged without enough context.
The approach
I helped turn the work into a shared quality system. Storyboards had a second set of eyes before development. Completed Storyline modules were reviewed by a senior developer or lead. Then the original US ID checked whether the build matched the storyboard and preserved the learning intent.
After sign-off, an LMS admin staged and tested the module in Skilljar before public release. Skilljar is the customer learning platform where the learner launches the module, receives access, and creates completion data.
The important shift was shared language. Once standards were public, the conversation could move from personal critique to evidence against the same standard.
Downloadable takeaway
A one-page version of the model with the decision questions, sequence, metrics, and red flags someone can use after reading the case.
What I built
Created shared handoff expectations
The storyboard had to include screen flow, visuals, copy, interaction notes, feedback rules, and open questions.
Regular handoff meetings made unclear build assumptions visible before the developer had to guess.
Built QA into each stage
Storyboard QA happened before development. Senior developer QA happened after build. ID acceptance confirmed interpretation. LMS staging confirmed the module worked in Skilljar.
Testing included triggers, variables, selected states, layers, quiz logic, accessibility basics, launch, resume, completion, and reporting.
Used sprint calibration
The team started with three-week sprints and later moved to two-week sprints after standards and handoffs stabilized.
Group calibration meetings each sprint gave the team a place to discuss repeat issues and update standards.
Operating artifacts
These are sanitized work-product examples. They show the kind of artifact I would expect the team to use. They are sanitized and exclude confidential company material.
Storyboard to Skilljar Workflow
Storyboard to Skilljar Workflow
The full path from Confluence storyboard to public customer release.
Quality Standard Definitions
Quality Standard Definitions
Definitions that kept review conversations grounded in the same expectations.
Public Feedback Rule
Public Feedback Rule
Feedback had to be visible, specific, tied to a standard, and resolved in the task.
Work sample gallery
Asana quality board
Board-level view of modules, quality gates, blockers, and repeat feedback patterns.
Open task feedback thread
A realistic feedback thread around a missed Storyline retry-path issue.
Confluence process page
Process page defining stage expectations, evidence, and quality board rollups.
Confluence quality standards
Storyline 360 criteria for triggers, states, layers, variables, accessibility, and LMS tracking.
Confluence feedback expectations
Feedback expectations for public comments, tracked decisions, and calibration patterns.
Storyline interaction test matrix
Slide, layer, trigger, state, variable, learner path, and LMS evidence checks.
Trigger and variable logic map
Shows why the retry path failed and what had to be reset.
Skilljar staging evidence
Validates course management, learner preview, completion, score, access, and reporting.
Quality dashboard
Rolls feedback into repeat defects, open blockers, accepted risks, and release readiness.
Release package manifest
Controls source, SCORM package, staging evidence, approval, known issues, and support owner.
Quality gates
| Gate | Decision | Evidence |
|---|---|---|
| Scope ready | The module is worth building. | Audience, customer task, success behavior, source material, and owner. |
| Storyboard ready | The design is complete enough to build. | Confluence page, screen IDs, script, attached visuals, interactions, feedback, and open SME questions. |
| Handoff ready | The storyboard can move from the US ID to the India developer. | Handoff notes, open questions, design assumptions, and build owner. |
| Storyline build ready | The India development team has a build ready for senior review. | Slides, layers, states, triggers, variables, quiz logic, and player settings. |
| QA ready | The senior developer or lead confirms the build works. | Path testing, accessibility checks, media review, and defect log. |
| ID acceptance ready | The original ID confirms the build matches the storyboard intent. | Storyboard comparison, interpretation notes, unresolved questions, and accepted changes. |
| LMS staging ready | The LMS proves launch and reporting. | Launch, resume, completion, score, metadata, report, and audience access tests. |
| Publish ready | The release is controlled and supportable. | Approval, source archive, package archive, version notes, and known issues. |
The results
The operating insight
Quality at scale is a social system as much as a checklist. People need shared standards, visible feedback, and a way to disagree without making the disagreement personal.
The out-of-the-box move was making feedback public by default. That allowed quality patterns to roll up to boards and standards instead of living in private threads.
What this proves
- I can design a global customer education quality system.
- I understand Storyline 360 production, Confluence storyboards, Skilljar release testing, and public feedback loops.
- I know how to turn tension into shared standards and better handoffs.