If you are just getting started in e-Learning — or even if you are a seasoned veteran — what tools are you using to plan and organize your approach to each course? Are you recording the design decisions your team makes along the way? What are you doing to ensure consistency of design across multiple courses or multiple developers? A well-written design document helps solve these problems by outlining the design specifications, standards, and conventions specific to your e-Learning development.
The design document does just what its name implies — it formally documents the design decisions your team makes for a given project. It serves as an excellent reference tool and ensures that everyone on the team is speaking the same language and following the same rules, and it’s a great way to bring new team members up to speed quickly. The design document also tells your clients, whether internal or external, exactly what features and functionality they can expect from the finished program.
What, then, goes into a design document? At the Educational Institute of the American Hotel & Lodging Association (EI), we consider the design document a living document that continues to evolve as our team refines its processes through feedback and experience. In its current incarnation, the structure of our design document template comprises six major sections: Project Specifications, Standard Course Features, Design Strategy, Technical Specifications, Media Standards, and Project Management. This article will help you create your own practical design document by walking through each section in detail and reviewing the information and best practices our organization has found helpful. Although the decisions you make and the information you choose to document may differ from ours, this should serve as a good place to start.
Our first step in any e-Learning project is to outline its most fundamental requirements — those attributes that define what we are building and for whom. The methodological and technical aspects of how we will conceptualize, build, and maintain the program come later in the design document.
We begin by specifying the basic parameters of the project: a brief description of the course and its learning objectives, the intended audience, targeted length, and any prerequisites. If there are specific audience characteristics that should be taken into consideration, such as the level of computer and/or job experience, language or literacy barriers, or secondary audiences who may also participate in the training, those should be noted here. Also indicate the overall course length, as well as any standards for the maximum length of individual modules within the course. For example, we typically try to keep our modules to no more than 20-30 minutes in length to make it easier for users to complete the course in several short sessions.
We also define the exact materials or output that the team will submit for review and approval during various phases of course development. For EI, that most often includes:
- Detailed course plan — a comprehensive outline of course content and structure.
- Draft storyboards — a screen-by-screen breakdown of content, interactivities, media, and audio script.
- Supporting resources — often a course glossary or external PDF files (worksheets, forms, job aids) that users can launch and print from within the course.
- Assessments — draft questions for quizzes, exams, and course evaluations.
- Prototype module — a sample module with media for clients to approve before proceeding with development of the full course.
- Completed, fully enabled program — the completed program for full testing.
Depending on your needs, you may choose to combine or eliminate some of the above deliverables, particularly if you are working in a rapid development or rapid prototyping environment.
Existing content resources
Finally, we document all existing and available resources we will derive the course content from. If we or our clients have subject matter experts, existing training or documentation, or other materials to be used as a source of content, it is listed here as a reference for all team members.
Standard course features
The next step is to establish a high-level course framework. The decisions made at this stage will ensure consistency of presentation across all modules within a course, or across all related courses that are part of the project.
Begin by deciding what elements will be included in your course. Some of the typical course components referenced in our design documents include:
- Tutorial module — generally provides instructions about using the program and navigating within the course. If plug-ins or third-party downloads are required, include links within the tutorial. Be detailed in the design document about what information your tutorial module will contain.
- Overview module — typically presents an introduction to the content to be covered within the course, including course objectives and a brief description of the roles or responsibilities of the people being trained.
- Content modules — state the intent to organize core content into one or more brief, logical modules. You will expand upon details about content modules in the Preliminary Course Plan section later in the design document.
- Wrap-up module — summarizes key information presented in the course and provides concluding thoughts. Often, the wrap-up module will include additional resources or an action plan.
- Assessment or user evaluation — assessment and evaluation details are spelled out later in the Testing and Evaluation Strategy section of the design document, but the inclusion of these pieces is introduced here as a course component.
Because a course, especially a long one, is typically broken up into a series of modules, you’ll want to document the items or screens that should be standard across all modules. For example, your design standard might be that each module opens with an animated title screen or a synchronized musical introduction, or you may want to include a printable job aid or a summary of key points at the end of each module. Documenting such decisions ensures consistency and uniformity from one module to the next.
Interface and navigation controls
Other global course elements to consider include the interface and navigation controls that will appear on each screen of the program. Describe the informational sections the interface will incorporate, which may include course title, module title, progress indicator or location within the module, or a text prompt that provides instructions for what to do next.
If you plan to use submenus or other means to allow users to jump directly to specific topics or points within a module, provide a description of those here too. For example, you may choose to have a topic menu running down one side of the screen that is visible at all times and which links to subsections within the module. Alternatively, such a menu could be a pop-up from a button in the interface.
Describe the basic navigational controls that allow users to progress through the program in the design document as well. This typically includes Next, Back, Help, and Exit, along with any other features your design team chooses to add. For instance, you might want to include buttons that let the user replay a screen, toggle audio on and off, or launch a course glossary or other resources.
The Design Strategy is the core of the project and typically the longest section of the design document. Here we document methods, strategies, and constraints for presenting content, engaging users, and evaluating their learning.
Treatment and/or themes
If your program will consistently apply a themed treatment, identify it clearly and get any necessary approvals early in the design process. For example, you might have a character or “personality” who leads the user through the content, a running theme that defines the graphical look, such as “space” or “high tech,” or simply a style or color scheme to which the interface and all graphical elements must adhere. Although your team may not actually develop graphics until later in the process, you will want to identify the “look and feel” early so your designers can use appropriately themed language and examples when writing supporting content.
Figures 1 and 2 show examples from a course in which developers did not identify stylistic themes at the outset of development. Notice that the style of graphics is inconsistent with the interface, and even inconsistent with each other from one screen to the next. By contrast, notice that the graphics in Figures 3 and 4 are cleanly integrated with the interface.
Figure 1 Course screen with no clear graphic theme.
Figure 2 Style of graphics is different than Figure 1, even though this screen is from the same course.
Figure 3 Photos are integrated with interface in a common theme.
Figure 4 Original graphics are integrated with interface.