Transitioning my Kessler Syndrome project from a design case to a functional learning experience revealed a distinction I had not fully appreciated before LDT 504: having a strong idea is not the same as designing something that works for learners.
The original plan was to build the module in Storyline 360. Instead, it evolved into an AI-assisted HTML simulation developed through ChatGPT, along with a low-bandwidth version. What felt like a change in tools became a larger lesson. Technology can accelerate development, but it cannot decide what learners need. That responsibility still belongs to the learning designer.
Designing Before I Knew Exactly What to Build
The most significant challenge surfaced before I began building the simulation. I struggled to translate the subject-matter expert’s expectations into a design that would be meaningful for learners. It was also my first time creating a learner persona and context builder, and I was unsure what each should include.
Developing the learner persona took longer than expected because I needed to determine which characteristics should genuinely influence the design. I created Jordan “JJ” Jackson as a high-achieving U.S. Air Force Academy cadet. Ultimately, I realized that the persona’s name and background were less important than the questions it prompted: What does JJ need to do? What prior knowledge can I reasonably assume? What kind of practice would build confidence in mission-relevant decision-making?
The context builder presented a similar challenge. The SME wanted cadets to experience the tension of realistic operational decisions in a low-consequence environment. At the same time, the module needed to explain Kessler Syndrome without becoming a lesson in orbital mechanics. Because I was not the subject-matter expert, I had to identify what was essential, what could be simplified, and what required validation.
Looking back, I was treating the persona and context builder as documents I needed to complete correctly instead of as tools for making design decisions. If I were starting again, I would begin with two questions: What does the learner need to do, and what experience does the SME want the learner to have? I would then refine both documents as the design develops.
When the Storyboard Met Reality
On paper, the storyboard looked straightforward. Cadets would assume the role of Mission Control Officer, encounter an evolving orbital-debris situation, and make three increasingly complex decisions: recognize the debris threat, protect mission assets, and respond to a cascading event.
Development revealed how many decisions were hidden inside that simplicity. When I used ChatGPT to turn the storyboard into a functioning simulation, vague instructions produced vague results. Navigation, branching, feedback, visual hierarchy, and the persistence of earlier choices all had to be made explicit.
One important decision involved the mission-control interface. AI could generate an impressive-looking environment, but visual realism was not the learning objective. Cadets needed to notice debris alerts, changing orbital conditions, satellite proximity, and uncertainty in collision probability.
That shifted the question I was asking. Instead of asking, “What would make this look more like mission control?” I began asking, “What helps the learner notice the right information and make a defensible decision?”
I simplified the interface and reduced decorative elements to establish a clearer visual hierarchy. Applying CARP principles—contrast, alignment, repetition, and proximity—along with WCAG-informed accessibility considerations helped me use attentional guidance more intentionally. The same reasoning shaped branching and feedback. Feedback needed to help learners understand the consequences of their choices, not simply tell them whether they were right or wrong.
Development exposed assumptions that had seemed acceptable in the storyboard and forced me to evaluate whether each element actually supported the learner.
AI Could Build It — But It Couldn’t Decide for Me
Generative AI extended what I was able to create. It helped me translate design specifications into functioning HTML, troubleshoot problems, and iterate more quickly. Prompt-driven “vibe coding” also showed me that interactive learning experiences do not have to depend entirely on a traditional authoring tool.
But AI required more human judgment than I expected. A generated screen could function correctly and still be instructionally weak. I had to evaluate each version for cognitive load, accessibility, authenticity, clarity, and alignment with the learning objectives.
The low-bandwidth version made that distinction especially clear. The experience had to work offline without streaming audio, decorative graphics, or animation. AI could generate the code, but it could not decide what had to remain for the experience to preserve its instructional value.
I retained the mission brief, three decision points, choice-specific consequences, formative checks, reconvergence, debrief, and final assessment because those elements carried the instructional logic. I removed media that was not essential and simplified the interface without reducing the judgment learners were expected to exercise.
AI increasingly answered the question, “Can we build this?” My responsibility remained to answer, “Should we build it this way?”
Beyond the Authoring Tool
This project changed how I think about the future of learning design. As AI-assisted development makes it easier to create custom HTML5 experiences, low-bandwidth modules, simulations, and smartphone-forward solutions, learning designers may become less dependent on a single authoring platform.
That freedom also increases responsibility. As more things become technically possible, deciding what is instructionally appropriate becomes more important. Learning designers still need to understand the learner, identify the performance problem, design meaningful practice, create useful feedback, consider accessibility, manage cognitive load, and evaluate whether the final experience supports learning.
Building the Kessler module was, as my instructor said, a “boatload of work,” but it was also rewarding. What excites me most is applying what I learned to workplace training and seeing how thoughtful learning design can help close skill gaps, build confidence, and improve productivity.
What I’ll Carry Forward
The principle I am carrying forward from LDT 504 is simple: technology should support the learning need, not determine it.
I began the course thinking that becoming better at eLearning primarily meant becoming more proficient with development tools. Technical fluency still matters, and some of the “LD muscle memory” my instructor described will come with practice. I now see instructional judgment as the more important capability.
Storyline, HTML, generative AI, and whatever comes next are methods for creating learning experiences. None of them can decide what learners need to notice, what practice will build confidence, or what feedback will help them improve.
LDT 504 taught me that development is where design becomes real—and where the quality of our decisions becomes visible. Technology will continue to evolve. My responsibility is to make sure the learning remains purposeful and effective.