Deeper Design: Beyond Traditional Instructional Design

In “Deeper Design: Working Out Loud,” I described how a team of instructionaldesigners and developers went about settling on the objectives for what we decidedto call our “Future of Work” course, working out loud and in honor of JayCross. My purpose in these “Deeper Design” articles is to demonstrate theprocess that the team went through, applying design elements that go beyondtraditional instructional design (ID).

Deeper design goes beyondtraditional ID, reflecting on what’s known about how we learn and what thatimplies for the elements of learning. Too often, other than saying we need anobjective and practice (and getting those wrong), we talk about “content”without enough talk about the subtleties. I’ve addressed the details of deeper designin a series of Learnlets blog posts. These are my best thinking about learning design. The team of instructionaldesigners has worked to produce a course that we will launch the week ofSeptember 12.

Moving from objective to practice

Once we crossed the thresholdfrom objective to design (and it’s never as clean as all that), we startedlooking 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’resupposed to immediately move from objective to practice. Indeed, our firsteffort was to start creating a scenario that would involve the decisions wewanted to make. Learnnovators created the first scenario using BranchTrack, butwe swiftly moved to exchanging Word docs before authoring in Storyline. (At onepoint, the team at Learnnovators created a diagram in PowerPoint to help meunderstand the flow when I had trouble keeping track of the choices, and Iadded some additional color-coding to help me.)

Identifying the right scenarios in the right order

Embedding the right decisionswasn’t trivial. The first stab had us dealing with people to get acceptance ofour view. In the story, we had a resistant IT guy who we had to convince toopen the firewall. While this is realistic, it wasn’t core to what was reallyneeded. First, the decision has to be made in the executive suite that openingthe firewall is part of a larger plan.

The scenario shifted to anexecutive team meeting where the learner is in the role of the new HR leaderwhile the CEO is concerned with working smarter, not harder. The decision thenis to get the executive team (particularly the CEO) to understand theopportunities embedded in going more social and starting small. Pushing forcollaboration and communities was included.

Negotiating the details

Implicit in this was the notionthat the objective defines the practice that defines the model, though we’dchosen the model first. In retrospect, we were pushing some models we thoughtuseful, then looked for decisions (and likely misconceptions) to focus theobjectives, then went to push those decisions into practices. I think it’s agood thing to be jointly driven by principle and by real issues. Though, to befair, we had to infer the likely mistakes; while I surveyed, I didn’t get a lotof feedback about what mistakes people were making. That’s not unusual, and notnecessarily a bad thing for the design team to understand the material andanticipate likely problems.

Learnnovators: When we initially startedworking on the first scenario, we wrestled with several questions: who is thelearner in terms of the role they play, who will they be talking to in theorganization, etc. To ensure that we all had a fair idea of the outcome of thescenario, we decided on a few parameters before starting to write a scenario:

• The role played by the learner, and who theywould 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 andhow to use audio. In the scenarios? On content pages? Going beyond my ownpreferences, I checked what was known. Not only did I review the information inRuth Clark and Richard Mayer’s e-Learningand the Science of Instruction (which isn’t really relevant), and Julie Dirksen’sDesign for How People Learn, I alsopinged my network. The resulting information convinced us that we would havenarrated dialogue for the scenario, but not narration for content.

Learnnovators: We eventually dropped theidea, since narrated dialogue for the scenario would have meant a repetition oftext displayed on screen, which in general is bad practice. And, based on thepresumption that learners are intelligent enough to read and deduce nuances in thedialogues (this wasn’t a soft-skills course, where tone and inflection wouldhave been hugely important), we decided to do away with audio altogether.

We had initially made the screens animated—thatis, each line of dialogue fading in one-by-one in the sequence in which thecharacters would speak them. Then we realized that the animation was notrequired, as people are quite used to reading comics; so the animation, and theaccompanying scrub bar we had included, got hacked.

Engaging the learners: Visual style and dialogue

Another issue was the visualstyle we would use to convey the scenarios. Would we use stock photos? Isuggested a distinctive visual style and referenced Roy Lichtenstein’s work(continuing my campaign for more use of graphic-novel-style formats). TheLearnnovators searched and sourced a visual artist known for other imaginativework.

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 someverbosity can usually be trimmed. More importantly, however, we wanted to tryto make it sound the way people actually talk. That’s not always natural tomany writers, particularly if they’ve been highly rewarded for capturing expertnuances in accurate language. A second pass is almost always a good idea (evenon my own prose!), to trim and tighten.

Learner activity

We then added an activity, at theend of the first scenario, where learners would choose to sequence severalactions and we would provide feedback. This started as five decisions, andthere were 25 possible outcomes. Eventually, we decided on having three optionsto sequence and only three different feedback options.

Collaboration takes time! Scenario by scenario, draft by draft

There was considerable back-and-forthbetween the team members, with drafts and edits flowing to and fro. This isgood, in general, as we were practicing what we preach about the collaborationwe’re covering as a topic. It is somewhat time-consuming and could be a concernin terms of predictable time schedules. However, on the other hand we were gettingto know one another, and there was an expectation that this initial exchange ofprinciples 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’treally sufficient practice, so we started creating a follow-up. The secondscenario focused on follow-through, including opening up the firewall andchoosing a community manager.

That second scenario, drafted byLearnnovators, 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 editingincludes cutting down the language and making it more natural, but ourinteractions have helped develop a shared understanding of what matters inscenarios.

Similarly, their first draft ofthe content, based upon my related blog posts, was nicely done but alsobenefited 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 waspretty tight to begin with.

Learnnovators: We initially had the idea ofpresenting the content as well through a scenario. But then, all the practice activitiesare based on scenarios, and doing the same thing again with the content wouldcomplicate things and take the learner in circles. So we stripped down thecontent of all frills and made it into a simple, no-nonsense affair thatlearners can access quickly.

Testing the pedagogy

At the same time, we werewrestling with the pedagogy. Ideally, I like a problem-based approach, with aproblem that motivates learners to go through the content. I thought of ascenario to open with, then some content, and then further scenarios (anapproach I used in a prior project). Here, however, the problem was newer, andnot so tied to a particular problem, so it was hard to set up. Instead, weconsidered opening with a question, presenting some very brief content, thenlaunching into the two scenarios. It’s not as dynamic as I’d like, but it’srelatively generic stuff, and we did want them to hear the message. I asked ifwe could prototype both a regular and a problem-based approach to test, as wellas try out the scenarios to see how they worked with others.

Our first module ended up withthe scenario and a “reference” button. Ultimately, I wanted this buttonseparated from the navigation buttons and increased in salience. (I want them to access the content!) So weended up with a problem-based learning environment, intrinsically.

This was largely the high-leveldesign, and at the same time we were “sweating the details.” The lower-leveldesign continued with a number of iterations and some testing. I will tell thisstory in the next “Deeper Design” installment.