In this solo talk, Andy Campbell argues that learning designers habitually begin course creation without first understanding the technical realities of the Learning Management System (LMS) where the course will live. He likens this to building a piece of furniture without measuring the doorway it must pass through. Campbell describes the common pain of discovering, late in the process, that files are too large, tracking fails, mobile behavior is unexpected, or the LMS lacks needed features, forcing costly redesigns. He proposes a simple, early‑stage “technical discovery” practice: use a sandbox LMS to upload test assets, experiment with mobile playback, examine tracking and reporting, test deep linking, and simulate learner interactions such as pausing and resuming. This hands‑on exploration surfaces hidden LMS capabilities (e.g., robust video handling, assessment options, chunking content) and clarifies constraints, allowing designers to make informed design decisions before investing weeks in building a course. Campbell emphasizes that the LMS is part of the learner experience, not just a delivery container, and that understanding its quirks reduces friction for learners. He concludes with a concrete workflow recommendation: before opening authoring tools or storyboarding, spend time “messing around” in the LMS sandbox, ask administrators tough questions, and deliberately break things (in a safe environment) to map the system’s edges. This proactive discovery saves time, avoids redesign, and leads to more learner‑centric solutions.
Chapters
I'm a builder. I love making stuff, and one of the easiest ways to get me completely distracted is to give me a new tool and say, hey Andy, see what this thing can do. Crap, there goes my afternoon, because I'm going to click everything. I'm going to try things that probably weren't intended to work together. I'm probably going to break something, And eventually I'm going to figure out where the edges are. And weirdly enough, I think more learning designers need to do exactly that with their LMS, because here's something I've seen happen way too many times. We get excited about an idea, we start designing, maybe there's a video, there are interactions, maybe simulations, maybe branching, maybe we've got some really cool idea that nobody has tried before. And we build this beautiful thing, then eventually someone asks, okay, how are we putting this in the LMS? And that's when everything starts to get ugly. The file is too big, something doesn't track correctly, the platform doesn't support something the way we assumed it would, mobile behaves differently, reporting sucks, or there's some bizarre technical restriction nobody knew about because, well, Nobody checked. And now we're redesigning something we already built. That drives me nuts because we didn't really have a design problem. We had a discovery problem. We designed the thing before we understood the environment where the thing had to live, and that's backwards. I think about this like building something physical. Imagine designing this beautiful piece of furniture, You spend weeks on it, everything is perfect, and then you try to move it into the house and it doesn't fit through the damn door. Well, the doorway probably would have been useful information to have before we built the furniture. Your LMS is the same doorway. Actually, it's more than that. It's part of the experience, and I think that's something we forget. We tend to treat the LMS like the place where learning goes when we're finished designing it. Build a course, export SCORM, dump it into an LMS, done. But I don't think about it that way anymore. The delivery environment is part of the design, which means I want to understand it before I make a bunch of design decisions. And here's the other reason I like doing this. Sometimes you find cool crap. Maybe your LMS can do something nobody on the team is using. Maybe it handles video really well. Maybe there's assessment options you've never touched. Maybe you can link directly into resources. Maybe you can break an experience into smaller pieces instead of cramming everything into one giant course. Maybe there's functionality sitting there that's just changing your entire approach, but you're never going to discover any of that if the LMS is basically a filing cabinet where everybody dumps SCORM packages. So when I'm starting something new, I like doing a little technical discovery, nothing fancy. I just want to play with a sandbox. What can I upload? What breaks? What does this look like on a phone? What can I track? What does the reporting actually tell me? Can somebody leave halfway through it and come back? Can I deep link to something? What happens if I divide this into smaller experiences? What happens when something fails? And here's one I think we really underestimate. What does this actually feel like for the learner? Not the course. The whole thing, because I can spend 3 weeks making a beautiful learning experience, but if somebody has to click through 7 confusing screens, sign in twice, hunt through a catalog, and sacrifice a goat just to launch the damn thing, I've got a design problem. That friction counts because the learner doesn't experience our course separately from everything around it. They experience the whole messy system. And that's why I don't think constraints are necessarily bad. I actually like constraints once I know they're there, because now I know the sandbox I'm going— I'm playing in. I know where the walls are. I know what I can push. I know what I can work around. And sometimes I know, nope, this platform isn't going to do what we need. That's useful information too. Because now I can make that decision before I spent 3 days building something we're going to throw away. So here's something I encourage you to try before your next project. Don't open Storyline yet. Don't start building slides. Don't start storyboarding the giant beautiful experience you've already got forming in your head. Go mess around with your LMS. See Seriously, click around, upload something ugly, try it on your phone, leave halfway through something and come back, look at the reporting, ask whoever administers the thing annoying questions, try something you're pretty sure won't work, break something. Obviously, maybe don't break production. I feel like I should probably say that, but experiment. Figure out where the edges are, because that's part of being a designer. We're not just designing what's inside the course, we're designing how somebody gets what they need when they need it in the environment where they actually work. And the more of that environment you understand, the better decisions you can make. So learn the sandbox before you build the castle, because discovering a limitation while you're screwing around That's an experiment. Discovering it after you've built the whole damn thing, that's your week.
