The Design Document: Your Blueprint for e-Learning Standards and Consistency

Technical specifications

Before you can begin development, you will need to define the technical specifications to which you are developing. Here, especially, we learned from our previous experiences of building e-Learning sans a formal design plan.

Development tools

Have you ever storyboarded an e-Learning course without knowing which tools you would be using to build the final product? We have. We were eager to move forward in the next phase of our e-Learning presence, and ended up a little too far ahead of ourselves. We were lucky that our final tool selection did not result in a major redesign, though some modifications were required to fit the template-based system we chose. More disappointing was that with the new development tool, we suddenly had access to many new templates we had not previously anticipated. Had we selected the tool first, our design could have been so much richer. The moral of the story? Don’t let your tools restrict your creativity, but do at least know what they are so you can design to their strengths and find workarounds for their limitations.

The actual tools you select will depend on factors specific to your organization and your budget. There are many good authoring packages out there, some of which require more programming skill than others. After some trial and error, we are currently using a template-based system that allows our instructional designers to build the courses themselves with no programming knowledge required. The trade-off is that while we can develop courses faster and cheaper, we are more limited in some of our development options. In more recent courses, we have been able to get around this to some degree through creatively designed Flash elements in place of some static graphics; though that has caused our development time and cost to creep back up. These considerations should factor into your design plan.

File naming conventions

Once you begin designing your course and creating related documents and media, what do you name the files? Always establish file naming conventions up front so all team members can easily create, find, and retrieve the various course and media elements. There is no universal standard for naming and storing files — just make sure your naming scheme makes sense to your team members and within your organization, and is easy to remember.

Course identifiers

At EI, we begin with a unique course identifier that becomes a prefix for all media elements related to that course. For example, we have a course for restaurant servers currently in development. The course identifier we use is LLFB01. Decoded, the LL indicates the course is for a line level position, the FB indicates the position is within the Food & Beverage department of a hotel, and the 01 indicates that this is the first in a planned series of line-level food and beverage courses.

Frame numbers

Next, we express conventions for referencing individual screens within a course. Our usual standard is a four-digit frame ID that identifies the module number and frame number, sequenced in increments of 10 to allow for inserting additional frames, or screens, later without disrupting the naming scheme. Thus, we might number frames for the first module of a course 1000, 1010, 1020, etc., with the second module beginning at frame number 2000 and the third module beginning at frame number 3000. We might assign the number 1015 to a new frame, added later between frames 1010 and 1020.

Media and other files

We then use a combination of the course identifier, frame number, and media type to name media elements and link them to specific screens within the course. We might therefore name an animated graphic for screen 1010: LLFB01_gfx_1010.swf. Finally, we also detail comparable conventions for naming work product and resources such as storyboards, the course glossary, and help files.

Delivery hardware and software

Many design decisions will be constrained by the of the end user. It is therefore crucial to identify the target delivery platform. Are there limitations of operating system, screen resolution, Web browsers, plug-ins, or other software that you must contend with? Will users be on a dial-up or broadband connection? What are the hardware specifications of the end user?

Once you have answered these questions, ask what the design implications are. Systems without speakers or headphones will affect your ability to use audio for presenting content. If most users are on dial-up connections, you may have to avoid high-bandwidth media such as high-resolution video. If users are on a corporate network that locks down systems and prevents installation of software, you’ll need to limit your media to the plug-ins and versions that are already available.

Data tracking and interoperability

One lesson EI learned regarding technical standards of interoperability is that if you have any intention of deploying your course on more than one learning management system (LMS), or if there is the possibility of migrating your course to a new LMS down the road, think early and often about how you will get a program that runs fine on LMS “A” to do the same on LMS “B.” This means building your course to standards such as AICC (Aviation Industry CBT Committee) or SCORM (Shareable Content Object Reference Model) from the start, and recording decisions about which technical specifications you are adopting in your design document.

By way of example I offer our first effort at building an interactive online course. At the time of development, we weren’t thinking ahead to the possibility of licensing our online content to clients for use on their own systems, or the fact that we might not always be so enamored with the LMS we were using at the time. Both of those scenarios came to pass and we found ourselves rebuilding the original course to allow it to communicate with a client’s SCORM-conformant LMS. The good news is that the rebuilt course later transferred very nicely when we made our own switch to a new internal LMS.

Related to standards are issues of accessibility and tracking. Accessibility is increasingly becoming a buzzword in e-Learning design, and Section 508 accessibility guidelines should be a factor in your design if you are developing programs for federal agencies, in particular. Even without a Section 508 requirement, it’s prudent to document any accommodations (if any) you plan to build into your course for users with visual, hearing, mobility, or other impairments that may affect how they use the program.

Finally, we document the data we intend to track for each user. For our courses, this usually consists of time spent in each module, bookmarked locations, quiz and test scores, and module completion status. Conforming to the appropriate SCORM or other technical specifications allows you to pass this data easily back and forth between the course and the LMS.

Media standards

Media elements play a large role in any online course. As such, we devote a section of our design document to detailing conventions for the various types of media to be included in the project.

Text

With text standards, we lay out a few basic style guidelines such as: write concisely and in the active voice, use short sentences and/or bullets, and “chunk” content to avoid the appearance of dense screens. Writing style is one of the hardest areas to achieve consistency in across a multi-designer team. This section of the design document does not substitute for a good style guide (and you may want to list the specific style references you want your team to use, such as The Chicago Manual of Style or The Gregg Reference Manual), but it does offer a few helpful hints for instructional designers and technical writers and lets internal or external clients know what to expect in the presentation of text content.

We also specify what reading level we are targeting with onscreen text (e.g., 8th grade reading level for a supervisory level course) and define any standards for how to word text prompts. For example, the instructional text prompt on the last screen of a module in our courses always reads, “You have completed this module. Click Exit to close the window and return to the menu.” By specifying these standards early, all of our instructional designers are working consistently. This allows us to focus later quality assurance reviews on content and design, rather than details of uniformity.

Audio

Here, we spell out standards for voiceover, music, and sound effects. For voiceover, we indicate where we will use it and whether or not all onscreen text will be narrated word for word. Some of these decisions will tie into the capabilities of the end user’s delivery platform (loudspeakers, bandwidth, etc.) and whether or not you have opted to create a course that is Section 508 compliant or which otherwise addresses accessibility concerns. We also specify where we will use music and sound effects to achieve a consistent effect across the course or product line. For example, we often choose to use music on the opening screen of each module.

Visuals

Visual images essential to online course development are frequently used to provide an example for or otherwise support and reinforce the content on-screen. Our goal is to provide instructionally meaningful visuals, as stated in our design documents.

Graphics

Static, animated, and interactive visual images in e-Learning courses may come from a variety of sources. They could be original images created by an artist, existing graphics or photos from an internal or stock library, or custom photos taken specifically for the project at hand. There is a cost trade-off for original graphic design or custom photography vs. limitations or suitability of “generic” images from a stock library; these considerations should factor into your planning.

List other graphic standards here too. For example, standards we have documented in the past include graphically calling out key points or fun facts in a stylized text box and including an animated opening title sequence at the start of each module.

Video

Like audio, the use of video will depend on the delivery hardware. If users are on dial-up connections, consider using shorter video clips and higher compression settings. Higher compression results in smaller video windows and lower resolution, so you might want to test settings on a dial-up connection to achieve the desired balance between video quality and download speed.

Typically, for an e-Learning course we also specify the source of video footage — either from existing assets or new video production. Obviously, new video production will impact your project’s timeline and budget. When we choose to use clips from existing videos to present new information, or to reinforce or demonstrate concepts presented in the course, we provide guidelines in the design document for what is acceptable. This usually means that existing video content must be current, accurate, and relevant, and footage should not appear “dated” (clothing, hairstyles, etc.). Finally, we define screen location standards for the consistent placement of video on each screen that uses it.

Project management

Although not essential to the actual design of the course, you may want to conclude your design document by including project management details that might be helpful for future reference. Such details would include:

• Team members — a list of project team members along with their roles and responsibilities. Team members may include the project manager, instructional designers, programmers, graphic artists, audio and video producers, quality assurance reviewers, customer and/or client contacts, and subject matter experts.
• Key dates — a development timeline with milestone dates for key tasks and deliverables.
• Quality assurance and pilot testing — are there quality assurance reviews or a pilot testing phase before full launch of the course? If so, who will be involved and how will you collect and process feedback?
• Approvals — who gives final approval and sign-off that the project is complete?
• Archiving and maintenance — how and where will files be archived or backed up? How will the program be maintained or updated in the future? Is there an anticipated revision cycle?

Conclusion

There is a lot to think about, and a lot of work involved, in writing a well-crafted design document, which means that it is a step often omitted from the development process. The good news is that when you have a detailed design plan in place, it becomes your standard for development, and the course practically writes itself. If you have never written a design document before, the hardest part is writing the first one. The truth is that after you’ve written it once, you have a template for all future e-Learning programs. (See Sidebar 1 for an at-a-glance design document outline.) Much of the information will be fairly static and won’t change dramatically from one course to the next. Just remember that it is a living document. If it is not perfect or complete at first, you can continue to refine it as your team learns and your needs evolve.

Comments

Login or subscribe to comment