Click here to get this post in PDF
Most descriptions of the custom eLearning development process are written to reassure buyers. Analyze, design, develop, implement, evaluate. Clean boxes, tidy arrows, everything proceeding in order.
Anyone who has run one of these projects knows it does not feel like that. It feels like a negotiation between what the business asked for, what the subject matter expert actually knows, what the budget permits, and what will still be true in six months.
This walkthrough covers the same phases, but from the inside. What gets produced, who needs to be involved, and what tends to go wrong.
Phase one: discovery and requirements
The purpose of discovery is not to gather content. It is to find out what problem the training is supposed to solve and whether training can solve it.
A surprising proportion of eLearning requests are not learning problems. If people know how to do something and are not doing it, the cause is usually process friction, unclear accountability, conflicting incentives, or simply not having time. Building a course for a motivation problem produces a course that gets completed and changes nothing.
The questions worth asking early are direct. What are people doing now that they should be doing differently? How do we know? What happens as a consequence? What else would need to change for the new behavior to stick?
What comes out of this phase
A performance objective stated in observable terms, a defined audience with their real working conditions documented, a scope boundary naming what is explicitly out of scope, and a measurement approach agreed with whoever will judge success.
Where it goes wrong
Discovery gets compressed because everyone is impatient to see something. The result is a project that produces exactly what was requested and does not fix the underlying issue. Time spent here is the cheapest time in the whole project.
Phase two: instructional design
This is where the learning experience takes shape, and it is the phase that most determines whether the finished product works.
Instructional design services cover the structure and sequencing of content, the choice of learning approaches, the design of practice and feedback, and the assessment strategy. The output is usually a design document and then a detailed storyboard.
The storyboard is the contract
A storyboard specifies screen by screen what learners see, hear, do, and receive as feedback. It is deliberately unglamorous, often just text and rough layout notes, because it is meant to be cheap to change.
This matters more than it sounds. Changing a storyboard takes minutes. Changing the same thing after development takes days. Every hour of genuine scrutiny at the storyboard stage saves several later. Which is why the single most valuable discipline in eLearning course development is getting stakeholders to review the storyboard properly rather than skimming it and saving their real feedback for the first build.
Working with subject matter experts
SMEs know the subject. They are usually not good at knowing what a novice needs, because expertise makes the intermediate steps invisible. They also tend to want everything included.
The productive approach is to interview rather than request documents. Ask for specific scenarios, common mistakes, how they would spot someone doing it wrong, and what they wish people understood earlier. This produces far better raw material than a policy document ever will.
Where it goes wrong
Design by committee. When five stakeholders each add their priority topic, the module doubles in length and loses its focus. Someone needs authority to say no, and that authority should be established before design begins rather than negotiated during it.
Phase three: development and production
Now the storyboard has become a working product. Media gets produced, screens get built, interactions get programmed, and everything gets assembled in an authoring tool.
Development typically proceeds in stages. A prototype or alpha covering a representative section, then a full build, then revisions.
The prototype matters
Building one complete section first, in final visual style with real interactions, surfaces problems while they are still cheap. Stakeholders who could not visualize the storyboard suddenly have opinions. Better to hear those opinions on one section than on twenty.
It also validates technical assumptions. Does the interaction work on the actual devices learners use? Does the platform track it correctly? Does the file size hold up on a warehouse connection? These questions are much less pleasant to answer at the end.
Version control and review discipline
Consolidated, tracked feedback in a single document beats scattered emails every time. Contradictory comments from different reviewers need resolving between reviewers, not by the development team guessing. Agreeing the number of review rounds in advance keeps expectations realistic.
Where it goes wrong
Scope creep dressed as feedback. “Could we just add” is how a ten-module program becomes a fourteen-module program with the original deadline. Changes are legitimate, but they need to be visible as changes with associated cost and time implications.
Phase four: quality assurance
Testing custom training development output covers more ground than people expect.
Functional testing confirms navigation, interactions, and media all behave correctly across the browsers and devices in actual use. Content testing verifies factual accuracy, currency, and consistency of terminology. Tracking testing confirms the module reports correctly to the platform, which is the failure people notice fastest and care about most. Accessibility testing checks keyboard navigation, screen reader behavior, color contrast, captions, and transcripts.
Accessibility deserves particular attention because retrofitting it is expensive and because in many jurisdictions it is a legal requirement rather than a nice addition. It is far cheaper to design for it than to remediate.
Where it goes wrong
QA gets squeezed when development runs late, because it sits between development and a fixed launch date. Protecting testing time is a discipline that repays itself the first time it catches a tracking failure before launch rather than after.
Phase five: launch and iteration
Launch is a communications exercise as much as a technical one. Learners need to know what the training is, why it exists, when it is due, and what happens if they have problems. Line managers need enough context to support it.
Then comes the part most projects skip. Early data tells you a great deal. Where do learners drop out? Which assessment items does everyone fail, indicating either a teaching gap or a badly written question? How long does it actually take compared with the estimate? What questions reach the helpdesk?
Two or three targeted fixes in the first month, based on real behavior, improve outcomes more than another full module would.
How long the whole thing takes
For a single module of moderate complexity, six to twelve weeks is realistic from kickoff to launch. Larger corporate eLearning development programs run longer, though usually with parallel workstreams rather than strictly sequential ones.
The variable that most affects the timeline is not production capacity. It is stakeholder and expert availability. A project waiting three weeks for a review is a project three weeks late, regardless of how fast the development team works.
For a fuller walkthrough of how these phases connect and what to prepare for at each stage, this complete guide to custom eLearning development covers the process in more depth.
FAQs
1. What is the difference between instructional design and eLearning development?
Instructional design is the work of deciding what the learning experience should be, including structure, approach, practice, and assessment. Development is the work of building it, covering media production, screen assembly, interaction programming, and platform packaging. Some professionals do both, but they are distinct skill sets and larger projects usually separate them.
2. How much subject matter expert time does a custom eLearning project require?
More than most SMEs expect. For a single module, plan for an initial interview of one to two hours, availability for follow-up questions during design, a storyboard review, and a build review. Across a multi-module program this becomes a meaningful commitment and should be agreed with the SME’s manager before the project starts rather than requested opportunistically.
3. What is a storyboard and why does it matter so much?
A storyboard is a screen-by-screen specification of what learners will see, hear, and do, produced before any development work begins. It matters because it is the cheapest point at which to change direction. Revisions at storyboard stage take minutes, while the same change after development can take days and consume the budget that was allocated elsewhere.
4. How many rounds of review should we plan for?
Two or three substantive rounds is typical and workable. One after storyboard, one after the first build, and a final check before launch. Open-ended review cycles are the most reliable predictor of a project overrunning, so agreeing the number and the sign-off authority upfront is worth doing explicitly in the statement of work.
5. Can we develop custom eLearning in-house instead of using a partner?
Yes, if you have instructional design capability, production skills, authoring tool expertise, and the capacity to sustain all three alongside business as usual. Many organizations have some of these but not all. A common middle path keeps design and subject matter ownership in-house while using external capacity for production, which preserves institutional knowledge while resolving the bottleneck.
6. What should we do if the content changes while the project is running?
Distinguish between corrections and changes of direction. Corrections to factual detail should be absorbed as part of normal quality work. Changes to scope, structure, or objectives should be handled formally, with the cost and schedule impact made visible before they are agreed. Projects that treat every change as a minor amendment end up substantially over budget without anyone being able to point to the decision that caused it.
You may also like: Main Considerations When Choosing an eLearning Development Company
Image source: elements.envato.com
