In “Deeper Design: Working Out Loud,” I described how a team of instructional designers and developers went about settling on the objectives for what we decided to call our “Future of Work” course, working out loud and in honor of Jay Cross. My purpose in these “Deeper Design” articles is to demonstrate the process that the team went through, applying design elements that go beyond traditional instructional design (ID).
Deeper design goes beyond traditional ID, reflecting on what’s known about how we learn and what that implies for the elements of learning. Too often, other than saying we need an objective and practice (and getting those wrong), we talk about “content” without enough talk about the subtleties. I’ve addressed the details of deeper design in a series of Learnlets blog posts. These are my best thinking about learning design. The team of instructional designers has worked to produce a course that we will launch the week of September 12.
Moving from objective to practice
Once we crossed the threshold from objective to design (and it’s never as clean as all that), we started looking at the first topic (see the bulleted list in my previous article), that of the flow of information (based on the Coherent Organization model).
On principle, when designing we’re supposed to immediately move from objective to practice. Indeed, our first effort was to start creating a scenario that would involve the decisions we wanted to make. Learnnovators created the first scenario using BranchTrack, but we swiftly moved to exchanging Word docs before authoring in Storyline. (At one point, the team at Learnnovators created a diagram in PowerPoint to help me understand the flow when I had trouble keeping track of the choices, and I added some additional color-coding to help me.)
Identifying the right scenarios in the right order
Embedding the right decisions wasn’t trivial. The first stab had us dealing with people to get acceptance of our view. In the story, we had a resistant IT guy who we had to convince to open the firewall. While this is realistic, it wasn’t core to what was really needed. First, the decision has to be made in the executive suite that opening the firewall is part of a larger plan.
The scenario shifted to an executive team meeting where the learner is in the role of the new HR leader while the CEO is concerned with working smarter, not harder. The decision then is to get the executive team (particularly the CEO) to understand the opportunities embedded in going more social and starting small. Pushing for collaboration and communities was included.
Negotiating the details
Implicit in this was the notion that the objective defines the practice that defines the model, though we’d chosen the model first. In retrospect, we were pushing some models we thought useful, then looked for decisions (and likely misconceptions) to focus the objectives, then went to push those decisions into practices. I think it’s a good thing to be jointly driven by principle and by real issues. Though, to be fair, we had to infer the likely mistakes; while I surveyed, I didn’t get a lot of feedback about what mistakes people were making. That’s not unusual, and not necessarily a bad thing for the design team to understand the material and anticipate likely problems.
Learnnovators: When we initially started working on the first scenario, we wrestled with several questions: who is the learner in terms of the role they play, who will they be talking to in the organization, etc. To ensure that we all had a fair idea of the outcome of the scenario, we decided on a few parameters before starting to write a scenario:
- The role played by the learner, and who they would be talking to in the scenario
- The decisions that they would have to make
- The misconceptions they are likely to have
Trade-offs
There were questions that arose, trade-offs that we needed to evaluate. For one, the issue was about whether and how to use audio. In the scenarios? On content pages? Going beyond my own preferences, I checked what was known. Not only did I review the information in Ruth Clark and Richard Mayer’s e-Learning and the Science of Instruction (which isn’t really relevant), and Julie Dirksen’s Design for How People Learn, I also pinged my network. The resulting information convinced us that we would have narrated dialogue for the scenario, but not narration for content.
Learnnovators: We eventually dropped the idea, since narrated dialogue for the scenario would have meant a repetition of text displayed on screen, which in general is bad practice. And, based on the presumption that learners are intelligent enough to read and deduce nuances in the dialogues (this wasn’t a soft-skills course, where tone and inflection would have been hugely important), we decided to do away with audio altogether.
We had initially made the screens animated—that is, each line of dialogue fading in one-by-one in the sequence in which the characters would speak them. Then we realized that the animation was not required, as people are quite used to reading comics; so the animation, and the accompanying scrub bar we had included, got hacked.
Engaging the learners: Visual style and dialogue
Another issue was the visual style we would use to convey the scenarios. Would we use stock photos? I suggested a distinctive visual style and referenced Roy Lichtenstein’s work (continuing my campaign for more use of graphic-novel-style formats). The Learnnovators searched and sourced a visual artist known for other imaginative work.
And I also tweaked the dialogue. I usually find I can cut down most prose in content by about 40 to 60 percent, but that amount isn’t always the same with spoken language, though some verbosity can usually be trimmed. More importantly, however, we wanted to try to make it sound the way people actually talk. That’s not always natural to many writers, particularly if they’ve been highly rewarded for capturing expert nuances in accurate language. A second pass is almost always a good idea (even on my own prose!), to trim and tighten.
Learner activity
We then added an activity, at the end of the first scenario, where learners would choose to sequence several actions and we would provide feedback. This started as five decisions, and there were 25 possible outcomes. Eventually, we decided on having three options to sequence and only three different feedback options.
Collaboration takes time! Scenario by scenario, draft by draft
There was considerable back-and-forth between the team members, with drafts and edits flowing to and fro. This is good, in general, as we were practicing what we preach about the collaboration we’re covering as a topic. It is somewhat time-consuming and could be a concern in terms of predictable time schedules. However, on the other hand we were getting to know one another, and there was an expectation that this initial exchange of principles and practices would lessen as we shared our perspectives.
Indeed, this is what happened. When we’d created this first scenario, I realized that one scenario wasn’t really sufficient practice, so we started creating a follow-up. The second scenario focused on follow-through, including opening up the firewall and choosing a community manager.
That second scenario, drafted by Learnnovators, didn’t need a redo from me, but instead got just an edit, something I’ve done with almost any content from anyone. My usual editing includes cutting down the language and making it more natural, but our interactions have helped develop a shared understanding of what matters in scenarios.
Similarly, their first draft of the content, based upon my related blog posts, was nicely done but also benefited from some trimming and refinement. Here, since it wasn’t dialogue, the point was not to make it colloquial but instead to make it read naturally. They had already picked up the lesson from the scenario, however, and it was pretty tight to begin with.
Learnnovators: We initially had the idea of presenting the content as well through a scenario. But then, all the practice activities are based on scenarios, and doing the same thing again with the content would complicate things and take the learner in circles. So we stripped down the content of all frills and made it into a simple, no-nonsense affair that learners can access quickly.
Testing the pedagogy
At the same time, we were wrestling with the pedagogy. Ideally, I like a problem-based approach, with a problem that motivates learners to go through the content. I thought of a scenario to open with, then some content, and then further scenarios (an approach I used in a prior project). Here, however, the problem was newer, and not so tied to a particular problem, so it was hard to set up. Instead, we considered opening with a question, presenting some very brief content, then launching into the two scenarios. It’s not as dynamic as I’d like, but it’s relatively generic stuff, and we did want them to hear the message. I asked if we could prototype both a regular and a problem-based approach to test, as well as try out the scenarios to see how they worked with others.
Our first module ended up with the scenario and a “reference” button. Ultimately, I wanted this button separated from the navigation buttons and increased in salience. (I want them to access the content!) So we ended up with a problem-based learning environment, intrinsically.
This was largely the high-level design, and at the same time we were “sweating the details.” The lower-level design continued with a number of iterations and some testing. I will tell this story in the next “Deeper Design” installment.