rockidscience.com Instructional Design Basics

25Oct/12Off

Rare Breeds in Elearning

turtle2

The last Pinta Island tortoise, Lonesome George, died this summer.  George was found in 1971 and spent the last 40 years alone—lonesome was an apt name for him.

Unfortunately, our field has created some Lonesome Georges recently. New technologies and evolving skills-sets have made some specialized roles unnecessary or less important.

One recent rare breed is developers, as you no longer need real programmers to get your content online.  Today I will talk about this breed and why you shouldn’t count them out.

Problem Children

Over the years, I have had several incidents with developers on my projects.  These incidents usually center on them not doing what I want with the content.   A common scene in my world is, I turn in storyboards and wait for them to work their magic.  Then when I review it online and I am left thinking, “… this is nothing like what I documented in the storyboards.”

Conversations soon follow and in my experience, three common reasons are usually to blame for these instances:

 1.    Skill/Technology Gap

The developer didn’t follow the storyboards because they didn’t know how.  In these instances, they may lack the skills or technology needed in order to meet the needs as defined in the storyboards.  This is actually common—here technology changes and many programmers have to continually develop their skills.  In addition, many parts of our courses fall outside of traditional programming.  Animation, video effects,… fall into roles of multimedia development, which may not be something a true programmer knows or cares about.

 2.    Unclear Storyboards/Documentation

The programmer didn’t follow the storyboards because they didn’t know what I wanted.  Here my storyboards were not clear or very organized, so the programmer did the best they could.  This is also common as I am not always sure what I want—sometimes I only have a vague idea and it takes several iterations before my vision becomes clear.

 3.    Control Issues

The programmer didn’t do it because they didn’t want to. Unfortunately, programmers can be control freaks and this issue can sometimes appear in the middle of your projects.  When this happens, if they don’t like a design they may just ignore it.  Often the programmers have valid reasons for doing this—it could be a usability issue, back-end networking or security related.

Playing Nice

Regardless of the reason, whenever this happens it has the potential to become a problem that may require a crucial/challenging/difficult/… conversation.  In this regard, you need to pick your battles carefully.  Here you need to determine if your need is important enough to fight over, that is, is it worth the extra time needed to change the course back to the design in the storyboards and is it worth the potential damage to the relationship you have with the programmer—a relationship you may need later on.

In the least, you should talk with the programmer to see what happened and why.  This is important, as not following the storyboards, isn’t a good way to handle these situations. In this regard, it is easier to change a design around when it is at the storyboard stage than after it has been built. In addition, if there are design concerns then the programmer and ID should work together to define a strategy that will meet all needs.

Talking with the programmer can help you avoid these problems in the future.  In this regard, it can create a collaborative environment that will allow them to bring up their concerns before building the content. Involving the programmers early on in the storyboards is another way to avoid these problems—getting and addressing their concerns upfront will save time later.

Why You Need Them

It may sound like programmers are difficult to work with and that they deserve to fade out like Lonesome George, but this isn’t the case.  Our field is always changing and at the moment we are experiencing a rapid evolutionary cycle:

  • New technologies like mobile (SmartPhones, Tablets, eReaders), augmented reality, and location based content continue to define new needs.
  • Social networks, Open Badges and LMS integration (cloud and private) are creating opportunities for big data and recommendation engines.
  • Voice, touch and gesture interface systems are emerging and are changing how we interact with technology.

These technologies absolutely require real programming skills and can’t easily be addressed with standard course building tools like Articulate and Captivate. So continue to pick your battles and work on your relationships as developers may be rare but they are not dying out.

As a reference tool I’ve create the Types of Programmers document—maybe it will help you deal with these creatures.

19Feb/12Off

Can’t Touch This

den

The den was once my man cave—my safe place to go and watch TV or get some work done. Lately though this has become Max’s playroom.  And if you saw it, you would note a series of pillows, blankets and other obstructions strewn around the room.

These steps are necessary, as Max sometimes focuses on the wrong thing. In this regard an angry cat or an expensive Smartphone can be more interesting than toy blocks.
So to keep Max focused on the right things I have found that a little guidance is necessary.  Hiding things from him works for now and making access difficult is also a good solution—so a nice gate is handy, but even that is temporary. As I continue to interact with him, I can tell that this is a battle we’ll have for many years to come.

Unfortunately this is also a battle we as designers may have to face with our project sponsors, that is, how do we keep them focused on the right thing?

Today I’ll talk about some of my war stories with sponsors.

I Know What I Want

Project Sponsors are the ones that come to us requesting services so without them and their needs we wouldn’t be building training initiatives. Because of this I can’t bag on them too much, but as a designer I know that I need to watch out for them as they can set us up for failure.

Here sponsors may come to us with preexisting ideas on what the problem is as well and how it needs to be fixed. Often these sponsors are subject matter experts so it is a good idea to listen to them in this regard.  Just know though that their expertise can lead to tunnel vision and may cause them to focus on only a narrow portion of the problem.

This is the case I experienced awhile back when one sponsor voiced a need to get their students using specific codes in a software application.  These codes were important as they helped identify trends and problems in their workflow. This identification then allowed analysts to come in and figure out ways to maximize efficiencies and or cut costs.

When the sponsor approached me she had it all figured out—her users were not entering the right codes so they just needed additional training on them. And her solution focused on step-by-step training on each of the codes.    However, as I talked with her it became apparent that this solution wasn’t going to solve the problem.   In this regard these users had already received step-by-step training on the codes and it didn’t work.

So I talked with her some more and discovered that users were given a codebook to help them with their processing activities. This codebook was a large job-aid that listed all of the codes and appropriate use cases for each. This was a great performance tool, but it wasn’t being used much.  In addition I discovered that the end users didn’t really understand how these codes could save the organization money—they didn’t see what an error meant for the company and themselves.

So the ultimate solution didn’t focus solely on the codes, rather our total problem and solution, focused on the need to get her students using their codebook as a performance support tool and connecting the use of codes to losses and savings within the organization.   From that focus we then came up with a game that users played.  This game covered the most common problem areas with the codes and had the users interact with them in a simulated environment.  Here users saw the connection of the codes to the company.

Can’t We All Just Get Along

Besides focusing on the wrong thing you may encounter a situation where the sponsors can’t sign off or agree on the goals/objectives of a solution.  This is a real problem as you can’t start building the training until these goals and objectives have been finalized.

This is the case I experienced early in my career when I had to work with two sponsors from different divisions. This project surrounded a training initiative for case processing software. This project was complicated by the fact that several groups made up the user audience.  And here my sponsors represented each group and advocated for their specific needs relating to the training.

As I worked with the sponsors I discovered that one of them wanted training surrounding the step-by-step processing requirements in the software and the other wanted to focus on the factual and conceptual content within the software.   These differences caused some tension within the group and kept us from agreeing on the goals and objectives for the course.

As I continued to work with them I discovered that they wanted similar things when I pushed them on it—here they agreed that they needed all of this content as part of the solution. So they recognized each other’s needs but they couldn’t agree on which was more important.  This reignited the fighting in the group and as this fight continued tunnel vision set in—my sponsors only saw what was important to them.

This went on for several weeks and I employed a variety of strategies to try to get them to agree—I met with them together, I met with them one-on-one, other designers were used to facilitate discussions, I laid out the similarities, I advocated for each need, … all to no avail.  We were stuck and we were soon at a point of no return as the implementation date was fast approaching.

Ultimately I was able to get them to agree and move forward by moving around the sponsors. Here I met with key managers in their areas and explained the situation.  These managers were then able to champion and sell the need for the total solution in a way that worked.  The sponsors finally agreed and we able to develop a solution with steps-by-step processing as well as conceptual, factual and attitudinal information.  This last knowledge type I added to the project as it is a need that is often overlooked   (See knowledge types for software training for more information).

Leading a Horse to Water

Max's Interest Levels

As these stories illustrate your project sponsors can get stuck focusing on things that can derail your training initiatives.  Here they may be blinded to the real problem or may not see the full needs of their audience. Regardless of the type of project sponsor you have it is your job to guide them back to a safe place.

Fortunately your interactions with these sponsors are usually limited to the front end analysis part of your projects. Once the goals and objectives have been finalized these sponsors usually go away—leaving you stuck to deal with SMEs, Project Managers, and the occasional ID.

Max is a different story—I’m stuck with him for a while and as the graph shows I’ve got a lot of distractions to deal with here; however, I’m looking forward to these challenges!

23May/11Off

Max Comes Home

I’m a new dad and it wasn’t too long ago that I was leaving the hospital for the first time with my son.  And as I pulled away from the hospital I remember feeling like I got away with something—that at any moment someone would stop me and take it all away.  Surely being a parent wasn’t this easy, there had to be more to it then that and there must be some course, some test or other requirement that I needed to take/pass before I could take on this responsibility.

No one stopped me on that day; nor have they stopped me or my wife since.  We are learning as we go and “Winging it” seems to be ok when it comes to parenting.

This benefit of the doubt—“it will be ok” or “they will figure it out”—isn’t something that I experience much in the working world.  Here I have to continually justify my positions and needs.  And the group that I most often have to work with in this regard is my subject matter experts (SMEs).   Today I’ll talk about some of my experiences here.

Follow the White Line

On a project I worked on a few years ago it became time for the SMEs to complete their initial reviews of some Captivate movies I had been developing. Now since it was their first review, I didn’t worry about perfecting the timing of the captions.

My reason for this were quite sound—I knew that the SMEs would have a lot of content issues to report and each resulting fix would throw off the caption timing.  So spending a lot of effort here wouldn’t really solve much, in fact, it would only double my work as I would have to readjust the timing again when the fixes were applied.  In addition timing is a functional issue and not something that the SMEs should worry about—they are content experts and should hit that with their reviews.

Imagine my surprise though when the comments from the SMEs came in, “The caption on frame six needs to display a little longer,” and “The timing is off on frame 2 of 32 …” What I got was a bunch of comments about the timing rather than content fixes.

Now in their defense, the SMEs were fine—they saw something that was obviously wrong and reported it.  Giving me the benefit of the doubt probably didn’t make a lot of sense to them as they didn’t know the reasons for the timing being off. If I had communicated this information earlier I could have prevented them from reporting these timing issues and kept them focused on the content.

Communication in this regard is important as you need to guide your SMEs on what they should expect and focus on with their reviews.   Following this level of communication will help you with other common review issues.  For instance, proofing and editing is similar to timing in that it is functional and is usually one of the last things that are performed with online content.  With SMEs, it is not uncommon to find one or two grammar kings/queens, so make sure to keep them on task and focused on content rather than editing.

As you work on these projects you will find that guiding and focusing your SMEs is important throughout your project development cycle.  Here you may need to continue to define the roles within the project as well as outline specific activities and expectations of these roles.  Doing this will keep everyone on track and help you avoid unneeded time delays.

It’s All Good

Sometimes receiving the benefit of the doubt can be a bad thing and the SMEs should be checking your activities.  This was the case on a project I worked on several years ago—here the SME loved everything I did. And his response to the chunking and sequencing of the content I did was, “… that’s great—it is exactly what I wanted.”  Later I developed the interface and content flow for a drag and drop interaction and his response was, “that’s perfect.  You rock!” In these and the other reviews, the SME failed to provide meaningful feedback on the course content and according to his reviews the course was ready for publishing.

I knew though that my sequencing, the drag and drop interaction and the other content I worked on probably wasn’t perfect.  I knew this because there are subtle distinctions, thoughts and ideas that only a SME knows about with their content.   When these clarifications are missed then the learners may have a more difficult time internalizing the information.

So if you find yourself in a situation where the SME isn’t providing you with feedback in the reviews make sure to dig deeper.  Set up some time to meet with them and go over the content and audience with them.  Ask them “is there anything else that needs to be hit here—will this group understand this or …”

You may need to revisit the course goals and objectives with them, as this documentation will highlight course needs.  In addition accessing the information about your users will help highlight any specific needs each group may have concerning your course.

Types of SMEs

As you work on your projects you will find that there are many Types of SMEs and that their willingness to give you the benefit of the doubt may differ. Some of them may send you on your way and let you figure it out while others may give you a harder time.  Regardless of which type you work with just remember that everything will be ok, after all, it’s just a course you are building and not something truly important like a baby.

 

 

28Oct/10Off

No Respect

A comedian I wasn’t supposed to watch when I was growing up was Rodney Dangerfield; so naturally, I would watch his act whenever I could.  And though much of his subject matter was over my head at the time, I did find myself laughing at his material.  His no respect routine was a favorite:

My psychiatrist told me I was crazy
So I said I wanted a second opinion.
He said okay, you're ugly too.
Rodney Dangerfield

Goodness that is good stuff and as a kid, the no respect thing was something that I could relate to. Even as an adult, Rodney’s bit holds weight and this is especially true if your job involves quality assurance/testing.

In this regard, few understand or want to understand the contribution carried out by the lowly tester. Today I’ll talk about this humble hero and show you why good testers are necessary in order to produce a great course.

Why You Need Them
In a perfect world no one makes mistakes—everything we write is free of grammar and spelling errors; our courses function without hiccups; and the images in our courses are crisp and appropriate for the content.  Unfortunately we don’t live in a perfect world and this is why dedicated people are needed for testing activities on our projects. Without these folks your final course may have:

  • Spelling/grammar mistakes;
  • Poor navigational features;
  • Dead links, images, buttons and other resources;
  • Improper bookmarking and completion tracking; and
  • Inconsistent styles.

Such mistakes can be costly to the students taking your courses.  Here mistakes can damage the creditability of your content or make it difficult for your students to process/internalize the information.   Either result is bad for your course, so don’t mess around in this regard—dedicate time and resources to testing.

When to Test
Testing isn’t a one-time process and ideally you should start this activity early in your project. In this regard, things are much easier to fix on paper so your testing should begin at the storyboard level rather then when the content gets online.

The main type of quality assurance (QA) you will do at the storyboard level is Content verification.  It is at this point that SMEs, Editors, and Instructional Designers review the content to make sure that it matches the course requirements and that the information is clear.  Some typical areas that these groups should review can be found here.

Functional reviews are the next type of testing that you need to perform. These activities are performed as your course is being built.  Here people are checking the course to make sure everything is performing like it should.  Typical tests that should be verified at this level can be found here.

Having access to the storyboards, style guides and other documentation is necessary at Functional reviews as these resources define how the course should look/operate.

A key thing to remember with your testing is the need to be systematic—every page in your course should be tested and every test case must be verified for each page.  This approach will ensure that all of your content is consistent and as error free as you can make it.

How to Report a Problem
It is crucial to maintain clear communication as you test—here you need to make sure you document the exact problem and what the resolution should be.  This is easily done at the storyboard level as tools like Microsoft Word have features that facilitate this need.  With Word you can use the track changes and comment features to clearly identify the problem and what the change should be.

Communication becomes a little more challenging at the Functional level as these features may not be available.  Despite this, you still need to communicate the problem and resolution.  This is important as the developer needs to be able to find the problem in the course before they can fix it.  In addition, the developer may need to duplicate the issue in order to understand what is causing the problem.

So when reporting problems your descriptions should indicate:

  • The location (URL, page, frame) of the problem within the course,
  • The exact steps you have to do to produce the problem,
  • The specific problem you encountered and
  • The expected behavior for the course.

Once you report the problem though your work is not done.  The next step is to verify the fix once the developer has updated the course.  This is important as they developer may have failed to fix the issue entirely or they may have introduced another issue into the course while fixing the original problem.  Having a collaboration tool like a database or spreadsheet that everyone is working from can help keep track of these back and forth interactions.

Getting Respect
Testing a course can be a tedious job—hitting every page and running the same list of test cases over and over again can quickly put one to sleep.  But if you want a quality course, it’s a job that needs to be done and done well.  Once you have that great course then you’ll get your respect.

And as to Rodney, well he has since passed away but I think he got his respect in the end.

12Sep/10Off

How to Play Nice

In previous posts I’ve talked about several things that geeks, nerds and dorks across the globe love.  And one thing that many of these folks like to talk about is the Alien verse Predator question. Here we have two species that have been fighting for millennia and some people have opinions on which is the toughest or which would win in a real one-on-one fight.  To me, this debate has always been silly as the Predator obviously wins—seriously the guy has a nuclear device attached to his arm.

But this post isn’t about that debate; rather it’s about playing nice and how that is needed in your course development projects. Here issues like people missing their deadlines, having problems communicating, having unclear roles/responsibilities and other factors can quickly throw a wrench into your project.   You need people to play nice in this regard and a good project manager (PM) can help out here. So much so in fact that a skilled project manager could even get the Alien and the Predator to play nice for a bit.

Today I’ll talk about some of my experiences where a skilled PM was needed.

Playing Nice—Keeping Your Deadlines
As an Instructional Designer I often work with content that I don’t know much about.  In these instances I work with a Subject Matter Expert (SME) to ensure that the content is accurate. Often these SMEs are assigned this task because they are the best at what they do—they have demonstrated mastery on a skill and as such are valued. Because of this knowledge they are often quite busy and don’t have a lot of time to devote to side tasks. This is unfortunate for me and other training developers as their role as a SME is often looked on as a side task.

This was the case on one project I worked on a few years ago. Here the SMEs had numerous assignments that took precedence over their role as SME and this translated into them missing deadlines. This happened so often that the project schedule became meaningless.

Now if I or the other project team members were only working a couple of projects at a time this might not have been a big deal; however, this wasn’t the case.  Here it was common for team member to have 5 or 6 active projects at one time.  So when these SMEs missed their deadlines, we often didn’t have the time available to work on that task when it finally got to us, that is, our other project work had us allocated to other tasks.

The PM on the project was aware of these conflicts but refused to alter the schedule to account for the missed deadlines. Because of this, I and the other team members had to find a way to make up for the lost time.  Here we worked extra hours, shifted other project work and cut corners—these measures negatively impacted the quality of the projects we were on.

The PM in this instance should have stepped in and adjusted the schedule to meet the missed deadlines. In addition they should have worked with the SMEs to identify more realistic durations for their work tasks.  Duration is an important concept with projects, as it doesn’t necessarily equal work effort.  Here a task may only take five hours to complete but because of your work schedule, you may need two days in order to work those 5 hours. These two days is what is known as the duration and this is what should set the timeframes of the tasks within your projects.

A weekly status meeting could have also helped with this project.  Here the PM could have worked with the SME to identify possible conflicts with their deadlines—if the PM knew the SME was likely to miss a deadline then they could have communicated that to the team ahead of time.  This advance notice could have provided the team time to prepare for the missed dates.

Playing Nice—Understanding Your Role
On another project I worked on awhile back, I experienced a different issue; here the SME didn’t fully understand their role in the project. As I indicated above I often don’t have the content expertise for the courses I am developing.  When this is the case it is crucial to have an active collaboration between the ID and the SME.  Here the ID should be working with the SME to expand and or rework the course content into sound instructional strategies. The SME needs to provide content and be available for questions and clarification needs.

As I was working on this project I needed to create some scenarios to use for the various interactions within the course.  I contacted the SME several times through voice and email indicating my need and why this was important.  Here I basically wanted the SME to give me some real world situations that they had encountered in their job.  From this I was going to develop my scenarios and interactions.

To say that this SME was less then responsive in this instance would be an understatement—I got nothing here.  So to meet my need, I researched information about the job and created some scenarios based on my notes here.  My notes though were not entirely correct as the organization had unique requirements for that job. This meant that the scenarios I developed from my notes didn’t really fit into what users would experience on the job.  So in essence, I wasted 20 hours researching content and developing scenarios that couldn’t be used.

The PM on this project was aware of the situation from the start, but choose to keep out of it. Here they missed a good opportunity to interact with the SME and explain the various roles within the team. When the SME still refused to demonstrate appropriate behaviors for that role then the PM should have contacted the project sponsor to find another SME.

This problem should have been addressed upfront though by explaining the role and responsibilities of the team members before the project started.  Here it is always a good idea to have a kick-off meeting where the PM can define each person’s role in the project and what is require from each role.  In addition weekly status meetings could have strengthened this need as these meetings illustrate the bigger picture—who’s doing what; what does everyone need...

When Do I Need a Project Manager
It is probable that many projects you work on will not have a dedicated project manager. This can be nice if it is a small project or one that has a few close people working on it.  With the bigger and more complex projects you will need someone in this role as many things can cause problems in a project.

To help you get started on what to expect from project managers I’ve put together a short table of Types of Project Managers you may encounter.  As you read it you can see that some PMs will be much better at getting people to play nice.  If you have encountered other types of PMs please add comments to this post describing them.