Before You Design Training, Diagnose the Problem

One of the things I've been thinking about since starting my graduate program in Learning Design & Technology is how quickly we tend to jump from a problem to a solution. Someone isn't doing something correctly, a process isn't working, adoption is low, or performance isn't where it needs to be. The natural response is often, "We need training."

I've spent much of my career around learning, technical content, certification, product education, and enablement, so this pattern isn't new to me. What's changing is that graduate school is giving me more formal language and frameworks for examining decisions I've made throughout my career. Needs analysis is a good example. The basic idea seems obvious: understand the problem before you design the solution. In practice, that's harder than it sounds.

The question "What training should we build?" assumes we've already determined that training is the answer. A better place to start is with performance. What are people doing today? What do we need them to be able to do? What's the gap between those two states, and most importantly, what's causing it?

That last question matters because not every performance problem is a learning problem.

Someone might know exactly what to do but be working with a process that's overly complicated. They might understand the policy but lack access to the right information at the point of need. The technology might be getting in the way. Expectations might be unclear. People might not receive useful feedback. Incentives could even be pushing behavior in the opposite direction.

None of those problems are necessarily fixed by putting someone through another course.

That's one of the things I like about needs analysis. It forces you to resist the urge to start building. Instead of beginning with a modality, you begin with questions. Who is the audience? What does successful performance look like? What are people doing today? What evidence do we have? What do learners themselves say is getting in the way? What do managers or subject matter experts see?

In my current coursework, we're applying this process to a real instructional problem: how to help K-12 teachers use AI-assisted development, or "vibe coding," to adapt existing lessons into multimodal learning experiences. Instead of assuming teachers simply need training, we're looking at the current state, the desired state, and what might actually be creating the gap. We're using surveys and interviews to learn more about their experience with AI and digital tools, their confidence, motivation, and the practical constraints they face. It's a useful reminder that good instructional design starts well before an authoring tool is opened.

Once you've determined that learning really is part of the problem, the next question becomes more interesting: What exactly does someone need to learn?

That's where task analysis comes in. A task that looks simple to an experienced person can become surprisingly complicated when you break it apart. There may be prerequisite knowledge, concepts that need to be understood, procedures that need to be followed, decisions that require judgment, and attitudes or behaviors that influence the outcome.

Experts are often especially difficult to learn from because they've internalized so much of what they do. Steps that once required deliberate thought have become automatic. When an expert says, "You just do this," there's often a lot hidden inside the word "just."

I've seen versions of that problem throughout my career working with complex technology. A subject matter expert can explain a product or process accurately and still not explain it in a way that helps someone else perform. Good learning design has to uncover the decisions, dependencies, assumptions, and practice opportunities that sit beneath the surface.

Only after that work does it make sense to ask what the learning experience should look like.

Maybe the answer is instructor-led training. Maybe it's a short digital module. Maybe people need guided practice, a scenario, a job aid, a checklist, or something embedded directly into the workflow. Sometimes the right answer might be documentation or performance support rather than a course at all.

The technology matters, but it shouldn't make the decision for us.

I've worked across a lot of platforms and authoring environments over the years, from early multimedia tools to learning platforms, content management systems, proprietary publishing environments, and now AI-assisted development. Those tools have changed dramatically. The core questions haven't changed nearly as much.

Who are we designing for? What do they need to be able to do? What's preventing them from doing it today? What kind of practice will help? What feedback do they need? How will we know whether the intervention actually improved performance?

That's probably the most useful connection I'm making between graduate school and my professional experience right now. These aren't entirely new questions for me. I just have better language and more structured ways to ask them.

And there's something valuable about returning to those fundamentals after years of working in the field. Experience gives you instincts. Frameworks give you a way to examine those instincts, test them, and occasionally challenge them.

Before we build the course, create the video, open the authoring tool, or ask AI to generate anything, it's worth making sure we understand the problem we're actually trying to solve.