Instructional Myopia!

Whether you are an instructional designer, eLearning programmer, or a graphic designer; you have seen and “experienced” scripts. The quotes are deliberate, as this article devotes itself to the lofty objective of enhancing the quality of experience that we have with scripts and storyboards. This article isn’t about is the quality of instructional design within the script, but about the quality of instructional design around it.

Are you flummoxed?

If you are, you may be suffering from instructional myopia, something that all of us (especially, the instructional designers,) suffer from until we change the lenses we use to view our work! The symptoms of instructional myopia are:

• A fixation on the end user / ultimate audience
• Red swollen eyes
• 60 to 72 hour-weeks
• Hallucinations (you see yourself amidst fire-breathing graphic designers and programmers, who circle you menacingly.)

Unbelievable…? Believe it! Instructional myopia is an illness that almost all instructional designers suffer from. Some are not affected too badly, others are; some are intuitively vaccinated against it, others don’t even know that they are affected.

Let me try to unravel the shroud of mystery around instructional myopia by telling you that it’s nothing but a particular shortsightedness that allows us to see only our end-user as the audience for a script. It is the tendency to forget that though the end-user or the learner is our audience for the final course, we also address others through the script. These others are those who along with the instructional designer develop a course. They are the graphic designers, the programmers, the editors, and even the ID reviewers.

Some how we always end up concentrating all our instructional design efforts towards the end user, paying little attention to the interim audience. Of the many reasons that I am tempted to ascribe it to, the one that I feel contributes most strongly towards inducing this shortsightedness is the fact that we work under tremendous pressure of deadlines.

While we work on our script in the project pressure cooker, we tend to save time by cutting down on our communication with our co-creators. We suddenly begin to imagine them as omniscient, perfect beings that would be able to peek into our minds and find out how we imagined a particular animation or interaction. On the other hand, some of us decide to don the mantle of omniscience ourselves, and cross the domain expertise border. Both these approaches are destructive for the course.

Let me share a couple of experiences before we move on:

1. A script that I received for review had a smart format that had a lot of space for visual description. I like scripts that forebode interesting visuals and the format of this script promised me a long interesting review; so I settled down and began. Can you imagine my feelings when I saw that almost all frames had been treated with the same word-pinching, sentence crunching, time saving format painter – “Create appropriate graphics”, or “Create appropriate animation”? The information on interactions was limited to stray instructions such as “Create a drag and drop exercise.”
   
   
2. Another recent experience had me looking a script that overflowed with “instructions” to the graphic designer about colors and sizes of the fonts to be used, detailed descriptions of photographs “shot” in 1930s(!), and detailed descriptions of two huge character animations. All these instructions had nothing whatsoever to do with the content. The content dealt with documentation procedures!

These examples depict two opposite ends of the instructional designer’s involvement in the script. In the first example, the instructional designer was in a hurry, and he didn’t want to spend time explaining the animations! In the second example, the instructional designer was trying to be exceedingly thorough, without realizing the fact that he was encroaching into the domain of his peer. He was so immersed in detailing his thoughts that he forgot to check the instructional relevance of his visualization. In both these examples, the instructional designers did not understand their interim audience.

In the first case, the instructional designer assumed that visualizing graphics, animations, and interactions formed part of the graphic designer’s or the programmer’s job. In the second case, the instructional designer did not trust the graphic designer’s creativity at all; he, among other things, also managed to insult the graphic designer! In both cases, the instructional designer failed to analyze his interim audience, namely the graphic designer and the programmer.

Almost all scripts that I receive for review are devoid of any “Note to ID Reviewer.” The ID reviewer is usually treated as an alien who is not at all useful unless he cleans, completes, and packages the script without giving any adverse remark. Interim audience…? No Sir! An ID reviewer is more of Interim hurdle! If he is a reviewer, why does he need “Notes to the ID Reviewer”?

If your question is – “so how does it matter?” you are new to the eLearning industry. Those who’ve been here will tell you that your failure to understand and address your interim audience most certainly results into more discussions, meetings, heartburns, crib-sessions, and sometimes, client calls and project fires!

Well! So far…not so good! We’ve talked about the bad practices...unless we talk about good practices, what use is this article?

So let’s get down to work and figure out what we should do to win the love and friendship of our peers and enable them to create courses that look great, that not just interest but also amaze the client, and impart the learning effectively to the end user or learner.

• Find out more about your interim audience. Just the way you analyze your end user, analyze your interim audience. Check out their attitudes, preferences, thought processes, and their requirements from a script. Find out how programmers, graphic designers, and reviewers are different from you.
  
  
• Customize your comments/notes to the graphic designers and programmers to suit their specific requirements. One of the graphic designers working on your project could be more comfortable with vernacular tongue; have you ever given it a thought! A short custom-made vernacular-in-English description could be of immense help. Of course, you may want to first find out if your script has a client review scheduled!
  
  
• Check your boundaries. What ever you do, don’t encroach. You may consider yourself an authority on ActionScript or Photoshop; remember your domain. The line-of-control cannot be breached. If at all you feel that there is an instructional significance of using a red font instead of blue, make a suggestion. If you have a brilliant idea for the color theme of your course, “suggest” it, do not “specify” it. If you think that a particular interaction should be created exactly as you’ve specified, let the programmer know why. He might have an equally good reason of not wanting to code it the way you specified (ready templates.)
  
  
• Always write notes and not instructions to your peers. The moment you change “instruction” to “note” your tone will automatically change. The face that they will see reflected in your notes will be that of a friend, and not of a remote robotic entity called the instructional designer.
  
  
• Make suggestions; ask for opinions; and give references to make conversation. We are all humans and we like to enjoy our work. Even when our end user expects formal British English, our interim audience stays sweetly Indian. We follow traditions, we respect age and experience, we make our guests comfortable. Our interim audience can be thought of as guests in our script; let’s make them comfortable.
  
  

I am sure you know it all, it is just that life moves too fast; we seldom sit back and look at how we write what we write. If we pull the brakes on the vicious circle, which keeps spinning so fast and keeps us moving in the same rut, we will know that sometimes, somehow, we don’t write what we plan to; sometimes we don’t write all that we want to; and sometimes, we write more than we need to. At such times, it’s good to remind ourselves, of the fact that Instructional myopia is fatal if not diagnosed and treated in its early stages.

While writing, we need to get into the shoes of each one of our interim audiences, one by one, and review our scripts to see whether they make sense, whether our language is too blunt, or too sharp, and finally whether we are encroaching.

This will not just bring down the time that we spend in clarification meetings; it will also make us happier, less afraid of receiving phone calls and emails from our graphics and programming friends (after all, if we make friends with them there will not be any need of fear!) It will also reduce rework and errors considerably. In fact, it’s easier to lose instructional myopia and experience the advantages of writing for the interim audience, than to list them!

So, shift your gaze, chuck the end-user lenses, and review your script from a fresh viewpoint. Instructional Myopia is curable, if diagnosed early and treated correctly!

Author: Shafali R. Anand