How to write amazing digital learning resources

A discussion with Clint Smith and Graeme Kirkwood, instructional designers who work with Sprout Labs, and Bruce Ransley, a technical writer we work with. Clint, Graeme and Bruce share their experiences in writing learning programs and offer some valuable advice for designing the best learning experiences.  

Subscribe using your favourite podcast player or RSS

Subscribe: Apple Podcasts| Spotify | Amazon Music | Android | RSS

Transcript

Robin:
It's Robin here, the host of the Learning While Working podcast. In this podcast I'm continuing the thread of thinking and talking about stories and writing for learning resources. This podcast is a discussion between Bruce Ransley, Clint Smith and Graeme Kirkwood. Each of them does a short introduction at the start.

Instructional designers are often seen as writers. But writing a storyboard is really just an outcome of a process. That's not to say that actually being a great writer also needs to be a really important skill that instructional designers all have.

The podcast starts with a framework from Clint on the types of writing that are needed for self-paced digital learning. Then we end up with some great advice from each of the three participants on writing learning resources.

I hope you enjoy this podcast. I will probably have these three people back on the podcast some time in the future as well.

Welcome to the Learning While Working podcast. Today I have Clint, Graeme and Bruce to talk about issues and ideas around writing learning resources. Could each of you just do a quick introduction? Over to you, Graeme, first.

Graeme:
Well I've worked in education and training for many years, and in more recent times, working with Sprout Labs as an instructional designer on a range of government and corporate and private projects.

Robin:
Cool. Over to you, Clint.

Clint:
Okay. I'm based in Melbourne. Current work, very similar to Graeme's, I think, as an instructional designer on larger projects. My background's also in education and training, and specialising in online learning.

Robin:
Cool. So Bruce, you're the odd one out in the group. Over to you.

Bruce:
I am indeed, quite odd, yes. I'm a technical writer. Essentially, that just means I'm really, really good at explaining complex information in plain language. In other words, I get to ask the really dumb questions of very smart people and try to make sense of it.

Robin:
Clint, you've got this really nice framework about the different types of writing that's needed for self-paced learning resources. What was that framework again?

Clint:
It's fairly simple. It's just, we're thinking about what are the different kinds of writing you do. Because when you talk about the work involved, it seems to me there's different roles. The one that kicks off really from Bruce's comment is: one role is writing information, explaining things, concepts or processes or rules, and that's the process of exposition, I guess it's also called, and that's standard, and, of course, fill.

That's the information, you then have to design activities. You have to write the activities, which is things for the learner to do, in simple terms. Of course, in self-paced learning there's a fairly set repertoire of your options for that, and picking the right one is the skill. Then I think there's also one that's often missed, is what I call the narrative voice. Doing the linking stuff between, "We're now going onto this," and, "Now we've finished that," and, "Introducing this."

There's a lot of the motivational stuff goes in that, giving the learner their bearings of where they're up to and why they're doing it. Then the last one is sort of scenarios. I'm thinking here things that require writing dialogue or creating character. That's really quite a different sort of writing and a different sort of skill. Very often, a storyboard will involve all of those, and possibly more.

Robin:
What I really like about it is a framework that covers across all those sorts of activities and scenarios, and really takes things beyond that sense of just being about explaining things. Bruce, in some ways, that explaining bit is really your bit. I'm really interested to think through and for your opinion on how do you think that writing a bit of text or even a script for a video is really different in a learning project to other sorts of projects you encounter?

Bruce:
The first thing I would say is writing is hard. We tend to forget that. We're all expected to do it at work every day in our jobs, it doesn't necessarily mean we're really good at it. One of the things that is difficult to first get your head around is the style in which you need to write. Your questions about, I suppose, putting yourselves in the shoes of the audience, the people you're writing for. You can write in a number of different styles. It can be formal, informal, friendly, chatty, but either way, it has to suit the people you're addressing. That's something we tend to forget.

I think too often, people confuse telling somebody something with communicating clearly. The examples I can think of is the angry boss, a week later saying, "Why didn't you do that? I told you last week that we needed to do A, B and C." Or a trainer failing to understand why even though he told us what to do, we're still not getting it. If you fail to put yourselves in the shoes of the audience and just tell something, then that message risks being misunderstood. I suppose from my point of view, it's empathising with the audience and somehow getting the subject matter expert or the expert to see what they're trying to say with fresh eyes, and not be too galvanised by what they know and what's already stuck in their head. It's opening up their thinking process, so when they're writing, they're doing it in the right style and the right manner.

Robin:
In actual fact, there's a really nice line, Clint, I've heard you say a couple of times. "In some ways, instructional designer's role is to actually be the novice, the learner." There in that questioning process you go through is actually trying to get the subject matter expert to see from that viewpoint of actually being a learner.

Clint:
Yes, that comes pretty naturally for me most of the time. [laughs] In some ways, it's better if you don't know the subject matter, because you're coming into it literally from the novice point of view or the learner point of view, so you're an advocate for the learner. If the materials and the people talking at you are not making it clear to me, well they're not gonna make it clear to the learner either. That's the bottom line of it.

Robin:
To jump around a little bit, with that sort of instructional voice you talked about, Clint. Graeme, a couple of times in resources, you've actually used a character for this particular part. How's that work?

Graeme:
I was just gonna jump in on Clint's comments then. I think it can be interesting to take that notion of the learner as a novice and dramatise that. One of the ways I've done that in the past is to, I guess in a way, present two characters in a storyboard. One of them is the learner and the other one is a guide or an expert of some sort. What you can write, in effect, is the conversation between them. So the role of the learner character becomes one of asking questions and the role of the guide can be to answer those questions and provide information, but that strategy can be fairly tedious and heavy-handed.

It's often more interesting if you manage the role of the expert guide as being a facilitator of activities or experiences, which will lead the learner towards understanding. That makes that guide role a lot more flexible and interesting then. I think, to boil that down, that notion of presenting a conversation between two characters, who can be presented on screen or on page by photographs or drawings or cartoons, to make it seem like this is a conversation between two people.

Robin:
It's an interesting thing as well, about being between two people, it becomes very solid, practical, plain English, casual language, as well. So you get out of that language of experts.

Graeme:
And it also allows the learner character to say, "Thanks for that explanation, but I'm still foggy about X, Y and Z." To kind of push some key learning points but in a more casual, relaxed way.

Robin:
Clint, you talked about the activities and you actually separated the activities out from the scenarios. Was there a reason, or did that just come out that way?

Clint:
[laughs] No, it just came out that way. Scenarios obviously are part of providing activities for the learners to do, but it just seems to me that there's the basic suite of self-paced options, from things that you also use in quizzes. Scenarios, I simply set them aside because it requires a different sort of writing. The precision involved, and that's not to be underestimated, the precision involved in doing a good multiple choice quiz which obeys the rules, as it were, and the purpose for multiple choice question, I'll rephrase that. Multiple choice can be used as a learning stage, not just as a summative quiz. This is quite a distinction there.

Developing the answers so that they are assisting the learner to get to a point of understanding is quite different than doing a quick ten point test. I set those aside. It's a very lean art, I think. It's absolutely minimalist. You just don't want any words that you don't need. It has to be crystal clear. It has to make sense. Whereas, let's say, if you're writing a scenario and you want to pop a bit of dialogue in there, then yes, it's gotta be mean and lean, but it's not quite the same precision. I think it's a different set of skills. It's more like the creative writing skills, of creating a character out of those words.

Bruce:
I agree, Clint. I said before, writing is hard. Whatever forum you're doing it in, there's a real art to getting it right, but none more so with something as 'simple' as a multiple choice question. Robin, you'll understand this as well. You've done software development, you understand logic, and nand gates and nor gates and so on. That kind of thing that goes behind programming and coding. Actually, it's not much different when it comes to writing a clear instruction, say, like how to operate your VCR or whatever. That goes for multiple choice questions as well. I've seen very, very poorly written ones that are in fact ambiguous. I'm sure the person who wrote them had very clear in his or her mind what they wanted from the student, but as the learner, it's been impossible to determine what the correct answer is, because there's an ambiguity there.

I think a lot of people, when they go to write training materials and any kind of thing that's instructional, underestimate how crucial it is to get the logic right and have no way of querying the right answer versus the wrong answer.

Graeme:
Can I just throw in a third element there, too. I think in that discussion, we're talking about two things that need to be written well, which are clear, sharp, unambiguous, well-targeted questions, and answers with the same characteristics. The third element that's worth keeping in mind there, is there's equally an art to writing feedback for various answers that can set themselves up as options, which is also instructive but can build onto further learning.

Robin:
Yes, I've heard you and Clint, and I've talked about it as well, that sometimes you want people to get the answer wrong so they can actually see the feedback. The feedback's a great opportunity. Sometimes it's interesting because you're almost wanting people to go for the answer that's possibly partially correct, because that's the one that's going to get the best learning experience for them, because of the feedback.

Graeme:
Yes, and that's picking up on a point Clint made. That's why only using quizzes as a summative device is such a limited approach. Quizzes can be really powerful as a learning tool because it enables that feedback stage. As Thiagi said, "The only point of any activity is the debriefing and the feedback that happens afterwards." You don't tend to get than when it's only used summatively.

Robin:
Interestingly enough, Graeme, someone actually retweeted that quote today, from the last podcast. [laughter] Because it is, it's that readjustment when you get feedback of your conceptual and mental models.

Clint:
Robin, just one point to make, which in effect ties those two categories together, the explanation and activities, because we're talking about writing for instruction, we're talking as if it's all words. Whereas clearly, Bruce's work has got—if you can replace a paragraph with a diagram or a process map, which will show it clearly or as well, or support it and save lots of ticks, that's a terrific thing to do. So that comes into the whole process as well, I think, and whether it's an interesting workflow issue, as we've experienced, as a team. If you've got an illustrator doing the illustrating, who is deciding what kind of illustration goes in which order and who specifies that? Of course, the stronger the illustrator's sense of learning design, the more they can contribute that directly. Very often, it's the instructional designer or writer, in Bruce's case, who is making that call as well.

Robin:
That's part of what I call the need to have renaissance skills as instructional designers. To be both—it's a multi-dimensional thing, it's about performance analysis first and foremost. It's about interface design, it's about writing, it's about media and it's about visual communication as well. It's a bringing together of all these things. It's a really challenging thing to find in one person, but still, even if there's experts doing illustration, as you say, it's still the instructional designer that holds it all together.

Bruce:
There's another limit to communication there, too, which is writing a brief for that designer. A lot of my work is in designing websites and how they fit together and how the content fits together, and also writing specifications for those websites, and for the designers involved. That's actually an important part of the wider process too, because if you just say to the designer, "Can I have a picture here, please? Just read that and make a picture," designers, they have a very different skillset. It's not necessarily their forte to be able to synthesise from a technical paragraph and then come up with the best diagram in the world.

So again, you often are translating from one style into another, and being able to do that, to explain to the different members of the team exactly what you want, is not to be underestimated.

Robin:
In future podcasts, I'm actually going to get some of the Sprout Labs graphic designers together to talk about that process, as well. To really flesh that out from their point of view. I think in learning, we switch that around. Because the instructional design role is so pivotal, sometimes they forget about the people who are communicating on the outside. Now, just in the last stage of the podcast, I'm gonna spring a bit of a question on the three of you that I didn't think about before. What would be your biggest gem of wisdom to someone who was starting to write learning resources?

Graeme:
Coming back to Clint's first category of information, exposition, explanation, I think one of the key things that an instructional designer needs to do is make a strategic enquiry or decision. That is, in working with a client, to figure out or to ask them what is their current source of information in the learning that occurs in the company or whatever? What's the current source of content? The answer to that question can head you off in various directions, but one direction may well be that their current source of information is actually quite all right. They may well have, say, a manual of procedures that exists, that is clear and unambiguous and very informative.

In which case, that doesn't then need to be part of your job. You don't need to explain or recreate the information, you need to focus then on the activities which explore it and bring a newbie to understanding of it. They may well have very effective video resources, say. I think of a project I did in construction, many years ago, where—this was my first question, and I discovered in their training already they use a really good video, which explained how to set up roof trusses. So the learning resource that then developed took a very different direction than if explaining about roof trusses had to be part of the exercise. It was more about designing a journey which explored that video, and sort of went in and out. I think that's a key strategic decision upfront.

Clint:
So Graeme, you're talking about, and we've had this chat before, the difference between renovating existing stuff and tearing it down and beginning again. Renovating can work beautifully if you have good bones, say. If there is good stuff. What I find is so many people, they're afraid to start again, because they've already got this stuff that such and such wrote. They've got a pile of this stuff, and they think it's gonna be, "Well, we've got a lot of this stuff already, let's just repackage it and give it a polish." I'm very, very adamant, after many years of doing this, that is not necessarily the right way to go. Unless, as in your example, it was a good pile of stuff to begin with.

Graeme:
I think in that case, if the answer to your question is they've got plenty of material but it's terrible, that heads you off in one direction, which means you've gotta recreate an alternative. But also, if they've got plenty of material already, it's terrible, but they're very attached to it, then suddenly you've got a whole lot of politics in how you're going to have to approach it. So I think that's sort of the enquiry into what's the source of information and what's it like and what are their attitudes toward it, is a pretty key strategic thing.

Robin:
Clint, what would be your general wisdom?

Clint:
I think it's something like tipping it upside down. As you're deciding what to include, information and activities and their combination, if you don't have an activity for the information, for the bit of info, leave it out. That's to say, the reason for putting information there, is then to apply some practise in applying or using it or in developing it. If you haven't got the activity, don't put it in, because it has no value. It's not of importance. That ought to remain in the manual, to be read later. In a learning program, the whole purpose is to give the learner some opportunity to practise and apply that information and that learning.

Bruce:
There's no harm, Clint, in leaving stuff out, generally speaking. Your training material doesn't need to be exhaustive by any means. Would you agree?

Clint:
Absolutely, because you've got to select what the core things are. In my case, I'm very keen on making sure that it links to the job. The first question I'm asking is, "What do I have to do in this job? What's the task? What’s involved? What are the steps?" Rather than, "What are the concepts involved? What are the rules? What are the principles?" I think the work tasks provide the structure and then you feed in what's required to be able to perform those tasks.

Graeme:
I think allied with that is the notion of sequencing, too. It may be, you could ask well when—this bit of information for which there are no activities, you may well say, "When are they meant to learn that?" If the answer is, "They don't need to learn it until a later stage of their progress, perhaps when they're more experienced or they have a lot more workplace application under their belt," then you can actually approach it in a different way.

Clint:
Yes, Graeme, I think the realpolitik of all of that is that, for many clients for understandable reasons, once you put everything in, and particularly what is said, what needs to be said, and that sort of prescriptive, "thou shalt" stuff, that's extremely hard to design then, if you've got that. As you say, you need to play the politics to shoot that out of the learning programme, put it somewhere else.

Robin:
Actually, listening to you, and realising that approach that Bruce and I have actually talked about on the Sprout Labs blog post, of separating out the resources and the information into different documents, into guides, e-books, infographics, podcasts, it's really deeply embedded into the practise of what we do. It's really interesting to hear it reflected back in that way. Bruce, how about you?

Bruce:
Just on that note, I like to think of it as, people love to tell us what they know, not what we need to know. So you tend to get, if you ask an expert to write something, he damn well will. He will display how clever he is to the nth degree, and that's not terribly helpful as a learner. That's the part that goes over your head and it does not work, in whatever form of communication you're talking about. Sorry, Robin, back to your question. If you're asking about what my gem of wisdom is: first of all, there's an assumption that if you're working as part of a team, as many of us are, we have people above us, beside us, below us in this team, but it's your primary task to write whatever this is—do not just go ahead and write it.

What I like to do is get everybody involved in the process together in a room and discuss what it is we're writing, and start a discussion in a workshop kind of format. And Jeez, that's a wonderful way to start a fight. At the end of the fight, with whiteboard marker in hand and you've jotted down the key points, you've eventually got everybody to agree. If you facilitate well enough, you've got everybody to agree what it is that needs writing. So my general wisdom is, only after you've done that should you even bother putting pen to paper, because you risk spending three weeks writing something, and then having the fight. That's not the right way to do it.

Robin:
Cool. Repeatedly, we've worked with that process of collaborative co-creation of things, it just works so well to get people into the spot that they build consensus, innovation and also become learner- or audience-centred, as well, because there's a strong voice of the learner in the room. Which quite often ends up being the facilitator or instructional designer doing a, "I don't understand what you're saying." Cool. Thank you for joining me today. That was a really great session. Lots of really great ideas in there, as well. So thank you for joining me on the podcast.

Bruce:
No worries, Robin.

Clint:
Thanks, Robin.

Graeme:
Thank you.