Overview
The course design and development process is always evolving. Please consult with project stakeholders to verify the most current process, terminology, and handoff timeline.
Terminology
Competency Context Worksheet (CCW) —This is a course-level document provided by the Educational Product Designer (EPD) to the Design and Development team at Design kickoff. It captures the course description, assessment strategy, skills, competencies (with cognitive levels and weights), standards alignment, recommended sources, and course-level scope notes. It is the foundation that informs the Scope and Sequence and Task Models.
Scope and Sequence Document (SSD) — This document is the Instructional Designers’ (ID) primary deliverable at the end of Design Stage 1. The SSD is a planning document that includes the Competency/Evidence Statement/Learning Objective table, course description, learning resource (LR) strategy, assessment strategy, and a course outline broken into sections, lessons, units, and components. It documents stakeholder-approved content before development begins.
Course Structure and Build Document (CSBD) — Also called the "Build Doc." This is the Design Stage 2 expansion of the SSD. It copies over the approved SSD content and adds granular detail (component type/modality, purpose, scope, descriptions/examples) for each unit and component. This is the document ITXs use to actually build the course, so accuracy is critical.
Task Model — A document that communicates assessment design specifications to developers and vendors, and serves as a stakeholder-approval checkpoint before development. This is drafted by the Assessment Developer (AD) using the official Task Model Template. It includes Scope of Evidence, Characteristic Features (required attributes an item/task must have), Variable Features (allowed variation), and, for OAs, ~5 sample items per evidence statement.
Blueprint (BP) — A planning/QA tool that ensures every competency and evidence statement is adequately and proportionately assessed, with item counts aligned to ES weight. ADs create blueprints for OA summative and OA formative assessments (PAs generally don't need one unless a vendor is building the PA/PA-formatives). Completed on the WGU Excel blueprint template, this document then sent to the Assessment Strategist (AS) and psychometrician for finalization.
Evaluation Management Application (EMA) Template — EMA is the platform where Performance Assessments (PAs) are published for students. The EMA Template is the standard Word document ADs use to build out a PA task: requirements, rubric, Design Notes/ES alignment, intro, attachments/weblinks, and a sign-off box for peer review, Product Development Owner (PDO), and Assessment Strategist (AS) approval before submission to Publication.
Course Planning Tool (CPLT) Items — The CPLT is an ungraded pre-course assessment students take with a mentor before starting the course, containing 3 knowledge questions per competency plus two readiness questions (confidence and experience). CPLT items are coded distinctly from live OA items (with a "D" instead of "V" in the item code) and are submitted to Publication separately from the Objective Assessment (OA) and Performance Assessment (PA).
Objective Assessment (OA) Items — Individual questions (usually multiple-choice) that make up an Objective Assessment. Each item has a stem, key (correct answer), and distractors, and must align explicitly to an evidence statement. Items are coded by domain/subdomain/competency/ES/item number/family letter/version, and get built, banked, and checked by Quality Assurance for editing, a Course Congruence Check (CCC), beta testing in Assess.ai before publication.
Performance Assessment (PA) Items —Performance Assessments are made of tasks (not discrete items like OAs), each built out on its own EMA template with requirements and a rubric.
General Guidelines
Abbreviations: Abbreviations in competencies, objectives, evidence statements, and skills should be spelled out the first time they appear within each component, with the abbreviation appearing in parentheses after the spelled-out term. For example, if an abbreviation appears in two separate evidence statements, spell the abbreviation out the first time it appears in each evidence statement since the evidence statements may not appear together and in the same order in the course. If an abbreviation is used in a competency title, spell it out in the title, with the acronym in parentheses, and use only the acronym in the competency text.
Example:
Competency 732.05.1: Evaluates Guidelines for Health Information Management (HIM)
The learner evaluates ethical guidelines within HIM research.
Articles: Be careful when using articles such as a and the. The may indicate that there is a specific correct answer (e.g., Identify the appropriate uses of technology in the classroom) when that is not the case. Often, it may be clearer to avoid articles altogether (e.g., Identify appropriate uses of technology in the classroom).
Modifiers: Avoid modifiers in competencies, objectives, and evidence statements. There may be, however, instances where modifiers are useful.
Examples of Appropriate Modifiers:
Identify appropriate uses of technology in the classroom.
Determine the correct data structure to use with a tree problem.
Examples of Unnecessary Modifiers:
Describe the different types of computer complexity problems in algorithms.
Outline the basic philosophical foundations of middle schools.
Identify specific examples of an observed teacher using best practices for creating a community of learners within a science classroom.
Numbers: Avoid numbers within the text of the objective or competency. Using numbers in a competency, evidence statement, skill, or learning objective often restricts the content that we expect students to know. Design statements such as competencies and learning objectives should be general enough to the subject that students are not given unfair hints or clues as to what exactly they will be tested on. Delete numbers when you see them, leaving a comment for why you are doing so.
Example:
Identify three ways technology can be used to promote cognitive development.
An exception to this rule may be if there is a universally accepted number of something, and the SMEs want to include that in the objective or competency (e.g., Identify the three states of matter.). Use of the article the is appropriate in this case.
Explanatory information: Information that explains how to measure an objective or evidence statement by providing topics, examples, or other background information should be included in the notes rather than in the statement itself. Examples of this include lengthy parentheticals and lists.
Essential Course Information Section
Course Name: Course names should not use ampersands. Ampersands are only appropriate in the short name of a course and in the domain name. The short name of the course may abbreviate words or eliminate spaces to save characters.
Course Description: The course description is a brief introduction to the course that includes the course’s themes, scope, and relevance to the students’ program. The description is provided to students prior to enrolling in the program and course. It is also used to inform the course design and to understand how the course fits into the larger program. Therefore, a course description should briefly explain what the student is expected to learn and why they are taking the course.
Structure: Course descriptions should, in general, be one paragraph. The description should be short and simple. Avoid questions and bullet points.
Content: Course descriptions should avoid the following content:
competency titles
references to technologies or learning activities
CU count
assessment types
complicated or industry-specific vocabulary or jargon
information more appropriate for the course introduction (e.g., how the student will engage in the course, LR platforms)
Subject: Keep the course as the subject whenever possible, not the student (e.g., "This course will prepare students to analyze graphs," not "Students will become proficient in analyzing graphs.").
Tense and point of view: Use present or future tense in the course description, but be consistent within the paragraph. Use third-person point of view. Do not use pronouns such as you, us, your, or I.
Student/candidate/learner: Refer to WGU students in the course description as student, and use learner for students of WGU students (e.g., in Teachers College).
First sentence: Begin each course description with the course title followed by an active verb and compelling statement.
Example:
Algebra for Secondary Mathematics Teaching explores important conceptual underpinnings, common misconceptions and students' ways of thinking, appropriate use of technology, and instructional practices to support and assess the learning of algebra.
Last sentence: The last sentence of the paragraph should refer to prerequisites for the course. (e.g., "The following courses are prerequisites:" or "Introduction to Interpretive Dance is a prerequisite to this course.") If there are no prerequisites, say so. Do not include the course code in this sentence, only the course title. This is because course codes can change in future developments whereas course titles often do not. (There may be rare exceptions that necessitate the use of a course code for clarity.)
Primary Learning Resources: These sources should generally be in APA 7 format unless the source indicates a different reference format. If an ISBN is included, it should be at the end of the source, similar to how a URL is treated. Do not include dashes or a period at the end. Sources in the notes for evidence statements and learning objectives need not be formatted.
Example:
Van de Walle, J. A., Karp, K. S., & Bay-Williams, J. M. (2018). Elementary and middle school mathematics: Teaching developmentally (10th ed.). Pearson. ISBN: 9780134802084
Design and Development Components
Competencies
Competencies are created by the design team to align with various skills. Quality assessment editors may note grammar, spelling, or more complex errors. However, no changes to competency statements should be made without academic, EPD, PDO, and AS approval.
Competency statements usually follow a syntax to support readability, assessment, and reusability.
[The student] + [(verb) + (optional dependent clause/s) + (simple or complex object) + (optional prepositional phrase)].
Example: The learner builds professional connections and relationships by leveraging network strategies and best practices.
NOTE: Competency numbers mean nothing to students and should not be student-facing or included in the course content.
Evidence Statements
Evidence statements (ESs) are measurable statements that define what evidence will be collected from students through assessments to demonstrate their competence for a given competency. Each ES represents a distinct, assessable portion of a broader competency, and together they provide a complete picture of a learner's mastery. ESs are necessary because they shift the design focus from "what should students learn?" to "how will we know they've learned it?" They ensure that all major aspects of a competency are actually assessed, and they guide the creation of learning objectives and assessment items even though students never see the ES language directly.
Each ES begins with "The learner," followed by a single measurable verb matched to the appropriate cognitive level, as determined by the WGU Leveling Framework. The cognitive level of an ES can never exceed that of its parent competency, though it may be lower, and at least one ES must match the competency's level exactly.
Examples:
· ES 1: The learner identifies specific roles and functions of development team members. (Level 2)
· ES 2: The learner explains how a provider's role and responsibilities influence decisions in a professional context. (Level 3)
Objectives
Learning objectives (LOs) break down competency statements into specific, measurable knowledge, skills, and behaviors at the lesson level. Each LO defines what a student needs to know and demonstrate within a single lesson. LOs collectively guide both content selection and formative assessment, ensuring the course reliably and validly evaluates student performance. LOs are important because they're the mechanism that translates a broad, course-level competency into concrete, teachable, day-to-day chunks. They scaffold up to the evidence statements, which in turn scaffold up to the competency, keeping the entire course tightly aligned from the smallest page of content to the highest-level outcome.
LOs generally start with a verb, or a stated condition followed by a verb, and each LO corresponds to one lesson. Lessons should be added or combined if a clean LO can't be written for one. The verb's complexity should align with the verb used in its corresponding evidence statement, but it does not need to match word-for-word. The cognitive level of the LO should be the same as or below the level of the competency it supports, per the WGU Leveling Framework.
A single ES can be supported by several LOs, but each LO aligns to only one ES.
Examples:
· LO 1: Describe the scope and standards for professional nursing practice, the levels of professional nurses, and their role in providing safe and quality care in various healthcare environments.
· LO 2: Explain the legal and ethical principles that apply in the scope of the nursing practice.
Task Models
Task models are documents that communicate assessment design specifications and guidance, giving developers and vendors expectations and models to follow when creating assessment items or tasks. Task models are used for both Objective Assessments (OAs) and Performance Assessments (PAs). They also serve as a review-and-approval medium for stakeholders before development begins. The AD drafts the task model using the official Task Model Template, then works with SMEs during design workshops to refine it. Structurally, OAs and PAs differ slightly: for OAs, all competencies assessed under the same assessment code go into a single Task Model document with a heading per competency. For PAs, each task typically gets its own Task Model document unless the AD and AS agree to combine dependent tasks under one document, each with its own Level 1 heading. Once the AD and SMEs consider the task models complete, they're handed off to the PDO and AS on the date set by the project manager for academic review.
None of the core Task Model sections, including Scope of Evidence, Characteristic Features, Variable Features, or Sample Items, are written as student-facing content. They're internal design specifications meant for developers, vendors, SMEs, and reviewers, describing what an item or task must include rather than presenting actual instructions to a student.
