Why platform is as important as design
Most conversations about why learners abandon a course focus on design. Scripts are too long, visuals are cluttered, and ratings feel punitive. Such criticism is usually fair. But there is a silent culprit that rarely appears after death, and it sits beneath the design rather than within it. It is the platform itself, the technology layer that determines how learning experiences are delivered, sequenced, measured, and assembled. If those layers are built carelessly, even the best instructional design can degrade on the way to the learner.
This article is aimed at people who create learning, not people who write code. The argument is simple. The decision of the engineering layer behind the learning platform is a hidden pedagogical decision. When you design a learning experience, you become involved in how the system that provides the learning experience is built, even if you never interact with the system yourself.
The problem of completion is also partly a problem of delivery.
The statistics on course abandonment are sobering and well-documented. While traditional self-paced courses have a very hard time following through, with industry analysis repeatedly finding that only about 10-15% of participants finish what they start, massive open online courses have historically reported dropout rates of over 90%. We tend to interpret these numbers as motivational or design stories. Often they are also about infrastructure.
Consider what actually happens between learner intent and completion. Users open the platform, wait for content to load, go to where they left off, resume videos, take quizzes, and expect their progress to be saved. Each of these steps is the surface of an engineering layer. Modules loading slowly, videos buffering on mobile connections, progress bars silently failing to record the last session, and assessments losing answers on submission. None of these are flaws in instructional design, but they all have the same effect as bad design: learners leaving and not coming back. Completion research consistently points to the first week and first few sessions as a critical intervention period, meaning that the moments when technical friction is most likely to push someone out are also the most critical moments.
Cognitive load is formed not only by the content but also by the interface
Instructional designers are naturally familiar with cognitive load theory and Richard Mayer’s cognitive theory of multimedia learning. This framework is based on three well-documented assumptions. That is, people process auditory and visual information through separate channels, that each channel has limited processing power, and that meaningful learning requires active processing rather than passive reception. From these, Mayer derived a set of principles aimed at reducing extraneous load so that working memory can be spent on the material itself, rather than fighting the presentation.
This is the part that gets lost. Irrelevant cognitive load is not only generated by content. It is generated by everything the learner has to deal with outside of the lesson, a large part of which is interface and performance. The split-attention effect described by Mayer and Moreno, in which related information is separated spatially or temporally and forces the learner to mentally piece it back together, can be introduced by a layout engine as easily as by a slide designer. Captions that are half a second out of sync with the narration violate the principle of temporal continuity, no matter how carefully the storyboard was written. When a page reflows when an asset loads, moving the text the learner was reading, it imposes the very extraneous processing that the consistency principle warns about. Even if the design is based on a principle, it is possible to undo it through delivery.
As such, the engineering team’s choices regarding rendering, asset loading, synchronization, and responsiveness are not neutral technical details. They are determinants of cognitive load and therefore of learning.
Data integrity makes adaptive learning honest
The current enthusiasm for adaptive and personalized learning is justified by the evidence. Our analysis of adaptive platforms shows that personalized feedback loops can significantly reduce abandonment. We also found that well-designed personalization is based on a continuous and reliable data stream about each learner’s behavior. But adaptability is only as good as the underlying data, and that data is a product of the engineering layer.
When a platform records learner interactions inconsistently, the adaptation logic built on top of it becomes personalized towards a distorted situation. A recommendation engine that thinks the learner skipped a module that they actually completed because the synchronization routine dropped an event will provide the learner with the wrong next steps and undermine the learner’s trust in the system. Even if the instructional strategy is good and the algorithm is good, the experience can fail because the data layer underneath both is unreliable. This reframes data integrity from an IT concern to a pedagogical prerequisite for learning teams. If you don’t measure accurately, you won’t be able to adapt to your learners.
What learning teams should ask the people building the platform
This does not mean that instructional designers need to be engineers. This means that the two fields need to talk about different things sooner than usual. The most effective EdTech work I’ve seen treats learning objectives, rather than feature lists, as the starting point for the technology architecture, mapping out the learner, instructor, and administrator journey in detail before building a single component. The order is important because a platform designed around learning objectives behaves differently than one designed around a general feature checklist. Teams approaching education-focused platform development in this manner tend to surface the cognitive load and data integrity issues mentioned above while the design is still possible, rather than patching it later.
In practice, the learning team may pose a series of small questions that have a very large pedagogical impact. Given how much learning is now happening on mobile phones, how does the platform behave when mobile connectivity is poor? How is progress saved? And what happens to the learner’s state if a session is interrupted? How are videos, captions, and on-screen text synced? Who owns the timing? How reliably is learner interaction being captured? And is that data reliable enough to drive personalization and reporting? Where in the system might delays, layout changes, or friction occur during the first few sessions where the risk of abandonment is highest? These are not feature requests. These are the points where instructional design either survives contact with real-world delivery or quietly collapses.
takeout
Good instructional design is necessary, but not sufficient. The engineering layer that provides the learning experience is making educational decisions whether or not someone frames it that way. And that decision manifests itself in completion rates, cognitive load, and whether the adaptive system is reliable. Learning experts have spent decades rigorously studying what happens on screens. The next benefit comes from being equally rigorous about how screens are built and delivered, and learning and engineering teams treating that boundary as a shared responsibility rather than a hand-off.
Share with
