Deeper learning, not surprisingly, requires an associated analysis phase. In the last post, we discussed the need for a performance focus. While this is necessary, it isn’t sufficient. What else do we need? First, we need to understand our audience. However, we need more for deeper learning than we have required before. Second, we need to work with our stakeholders to share the results of our analysis and get agreement. Here are some thoughts about a deeper learning analysis.
In typical learning design, we need to understand our current audience’s knowledge level. Combined with the objectives to be achieved, we have the roadmap for our learning path. That is, we know we need to take learners from where they are to where they need to be. We work backwards from the objectives, and stop when we’ve reached where our learners are now. That’s fine, perhaps, for purely cognitive needs, but we need more for deeper learning.
For one, we need to understand our audience. In particular, what differentiates them from society as a whole? Initially, it’s likely to be their role. Are there any constraints around that? Firefighters, for instance, typically have some physical constraints like a minimal ability of weight to handle. Accountants are expected to have some base level of ability with numbers. Sales folks tend to have some drive.
More important, perhaps, is their interests! What do they find fascinating? Here, our subject matter experts, as suggested in the previous discussion, can help us. They found this topic interesting enough to be worth becoming an expert! They’ve spent much time doing this. Why? What is it about this that they find fascinating? Is there something there we can integrate into the contexts we’ll use for examples and practice? Ideally, we are developing intrinsic motivation.
As an example, after I’d established some reputation for being involved in serious games, a colleague approached me for help with a project they were developing. When I asked the topic, I was told ‘computer auditing’. After I expressed less then enthusiasm, my colleague demurred. “That’s what I thought,” he said, “but when I asked them, they said it was like playing detective. You work backward to find the cause of the problem. Most of the time it’s an error, but occasionally, it’s deliberate!” Right there he had the basis of a game. The point being that finding the intrinsic interest provided a basis for building meaningful practice.
Once you’ve identified the elements you’ve analyzed, I strongly suggest you get agreement with your stakeholders on what you’ve found. You’ll be designing solutions from this basis, so you really want to make sure that they agree that you’ve identified the necessary components. On principle, you want to have a thorough basis for your design. Pragmatically, you’d like to have an explicit statement upon which to resist if later on there’s pushback on the focus of your solution. I suggest this be consolidated in a document, likely one you already have in your process (I call it a concept document), that’s circulated, refined, and, importantly, signed off on.
Overall, you should have identified a performance gap that needs to be addressed, framed as a set of decisions people need to be able to make, and the contexts in which they occur. As indicated in the previous post about the information you need from subject-matter experts, there are some additional elements you’ve collected and need to convey. You also should have a conceptual model or models (causal conceptual relationships that explain and predict outcomes) that guide successful performance. In addition, you’ll want the consequences of the decisions. That includes the common ways people go wrong, and the consequences of those choices. You should have stories of successes and failures that you’ll carry forward. Finally, you should identify what you know about the audience, and their interests as well as the experts.
This should all be documented, and presented to the stakeholders (including the subject matter experts) for agreement. You’ll want to get any updates to improve or correct this, and then you want to get explicit agreement. Often, at this point, you’ll get some feedback, and agreement. Then, further feedback will emerge. To prevent this, I’ll suggest that you insist upon someone consolidating all the feedback in one round, and after signoff any further feedback is considered a scope change (with associated consequences).
I’ll note that frequently I find that by this time, I have a good idea of what sort of experience will be required. If so, you might be able to save time by including that in the document and getting agreement as well. On larger projects, these may be two separate steps, but in practice on many typical learning projects this is feasible. Really, you should describe a pedagogy and any framing (e.g. a fantastic world in which the experience will take place). Justify the decisions from the analysis. I wouldn’t go further; sharing storyboards, etc.; this really is appropriate at a later stage.
Once you’ve obtained signoff on your analysis, you’re ready to proceed to the creative aspect of specifying the experience. This, to me, is the fun part. Yet it still needs to be grounded in the rigor of the analysis. In some instances, different folks will do the analysis and then the design. In other circumstances, they’ll be the same folks. Regardless, the needs at each stage are different, but the principles guiding them need to be equally rigorous.
Those are my thoughts on the analysis phase of designing deeper learning. What are yours?
