At this point in our process, the design team had resolved the fundamental issues: objective, scenarios, how to engage the learners, meaningful activity, and determining the pedagogy. Now, we had to consider some key choices and discern whether our initial ideas were due to personal taste, or untested assumptions, or what was best for the learners.


Getting the right “tone” in the experience is challenging. Ideally, you have to make sure that the right path to take is not obvious. Too often, questions are easy to get right, but you really want to have a reasonable amount of challenge to ramp up both the engagement and the learning outcome. We worked to make sure that was the case as we started looking at the scenarios, though we may have neglected that initially.

Learnnovators: We also added intrinsic feedback at the end of the scenarios; though this (intrinsic feedback) is built into the natural design of a scenario through dialogue, we wanted to “show” the consequences of learners’ decisions once they had reached an endpoint. This we built in through a simple description of what happened in the organization a few weeks or months after they reached the end, followed by an explanation of why this happened.

Art and illustration

Similarly, the Learnnovators commissioned an artist to create the characters in the scenarios. They chose one I didn’t know, but liked the look of. The illustrations were somewhat cartoonish and graphic-novel-ish, which I liked (we don’t use such formats nearly often enough in eLearning). For the second scenario, I suggested doing them differently, maybe making them different colors. They made one green, and that led to a thought of perhaps deliberately throwing in some different novelty in each of the scenarios.

Audio use

As mentioned in my previous article, we were postponing audio, if using it at all, but then the idea came up to use it just for stage setting and cues of outcomes. Despite my initial negative reaction (and probably an implicit bias), we considered it and again decided to try it out. The point is to not answer on the basis of personal viewpoints, but either search for evidence or trial it. Once determined, then it can be persistent throughout.

Scenario content

Our work on scenarios and content continued. Typically, they’d generate a context and initial scenario, which I’d fine-tune. Sometimes I’d want the scenario to be more focused on a particular aspect of the learning (serving as a subject matter expert at times), as we’d get somewhat far afield. Other times, it would be to rein in the dialogue. While you want to experiment and get out there, as your learners will thank you, it requires a fine touch to sound naturalistic.

Learnnovators: Randomizing choices is a great idea in any quiz, especially so in a branching scenario. So this was something Clark flagged for us early on in the design stage, and we achieved it during development.


One of the issues that came up was gender. I’ve been keen to use gender-neutral prose as much as possible ever since I read an article about how to do so (with an implicit “why it’s important”). I use gender-neutral names as much as possible and try to avoid the “he/she”—or, worse, the “s/he”—if I can write it instead in a gender-neutral way. And, of course, we were rendering the characters, so eventually they would have to be depicted as one gender or another. Still, on principle, I fought for making sure the text was gender-neutral, even the dialogue. This was met with general agreement, but the difficulty was somewhat challenging and there was pushback.

Assumptions about the learners

Another personal irritation is not assuming intelligence on the part of your learners. I have a real problem with a label that says, “Click the Next button to continue.” Maybe, maybe, in the early days, but nowadays it’s pretty hard to make the case. First, pretty much everyone has now had some eLearning experience (probably bad). Second, there is considerable experience with interface standards in general. And I think it’s an insult to learners’ intelligence to tell them how to use an interface. There may be instances when it’s appropriate, but in general I don’t like it. Fortunately, there was no argument with this point either.

Learnnovators: This was something we generally agreed with. But while the Next button was obvious and widely understood by learners, it may not be so with other buttons. For such interactions, we decided to provide a subtle visual clue about the “clickability” of the buttons, such as flashing the buttons a few times to indicate they are clickable.


So far in these articles, I have focused on the design process and the way we dealt with the challenges and issues. All along the way, of course, we were concerned with the development phase and played with various prototype builds. Inevitably there were technology problems, and those will be the focus of the next (and final) installment in this story.