In this monologue, Andy Campbell warns instructional designers against defaulting to their favorite tools—like Articulate Storyline, video, or AI generators—without first understanding the learner’s real problem. He illustrates how enthusiasm for building can blind designers to the actual need, using examples such as a monthly‑used process that would be better served by a quick, in‑context reference rather than a full course, and a scenario involving an upset customer that requires interactive practice. Campbell advocates a disciplined approach: start by asking what the learner is trying to do, where the difficulty lies, and what would help them at the moment of need. Then select the smallest effective solution, even if it’s a one‑page guide, reserving richer interactive tools only when they truly add value. He acknowledges the personal satisfaction of creating polished content but stresses that the ultimate goal is to deliver something that learners can find, use, and that genuinely supports their work.
Chapters
Have you ever had somebody mention a project and your brain immediately starts building it? You're picturing the screens, you've got an interaction in your mind, and you're thinking, oh, I know exactly how I could do this. Meanwhile, the other person hasn't even finished explaining the problem. I get that appeal. I used to teach art. I like making stuff. Give me a tool and a little room to experiment, and I'm interested. There's something satisfying about taking an idea and making it work, but being excited about what I could build doesn't necessarily mean I've figured out what somebody needs. And that's where I think we can get ourselves into trouble with our favorite tools. If you're comfortable in Storyline, everything starts looking like a Storyline project. If you're good at video, you're thinking about video. Now we have AI making it even easier to get something built before we've had much of a conversation about why we're building it. Say somebody needs help remembering the steps in a process. They only use once a month. You could make a really nice course about it. They could take that quiz or course, pass the quiz, and then a month later they're back at their desk thinking, crap, which thing am I supposed to click first? And at that point, they're probably not looking for the course. They're looking for the steps, preferably somewhere they can find them before they accidentally delete something. So maybe we've given them a short reference, or we give them a short reference. Maybe we put the instructions right where they're doing the work. And if there are decisions that tend to get people into trouble, We can spend some time practicing those. We don't have to make every part of the problem fit inside the same thing. Now, if the person needs to handle an upset customer, a list of steps probably isn't going to cover it. They need a chance to try the conversation, get feedback, and figure out what to do when the customer doesn't politely follow The script, which inconveniently customers tend not to do. That's the conversation I want to have before I pick the tool. What are they trying to do? Where does it get difficult? What would actually help when they're standing there trying to do it? Sometimes the answer will absolutely be something interactive in Storyline. Great, go build it. I'm not suggesting we all abandon our software and start handing out index cards. I just want a reason for the choice that goes a little deeper than, well, that's what I usually do. And honestly, choosing something smaller can be uncomfortable. A one-page guide doesn't look like 3 weeks of impressive production work. But if people can find it, use it, and get on with their day, I'm pretty happy with that. I still want to build cool stuff. I just want the person using it to have a better reason to care than the fact that I had a great time making it.
