D299 Learning Experience Design Lab, catalog number LXD 6052, is the three-CU build course. You apply the foundational learning experience design strategies to a real instructional problem and produce a functional e-learning module prototype. Functional is the word that changes everything. Up to this point a design can be argued for on paper; here it has to run, and running exposes decisions that a document lets you leave vague. The most common way to lose time in this course is not weak design skill. It is scope, chosen in week one and regretted in week five.
Scope is the first design decision and the one that hurts
Students routinely propose a full course when the task asks for a module. A ten-hour programme built at prototype quality produces something shallow everywhere, and shallow everywhere is difficult to score well on any aspect. A single well-built segment, complete from entry to feedback, gives an evaluator something to judge on every dimension.
The test for a defensible scope is whether the artefact contains one complete learning loop: the learner encounters a situation, attempts something, receives feedback that responds to what they actually did, and reaches a point where they know whether they succeeded. That loop is the smallest unit that demonstrates learning experience design rather than content packaging. Twelve screens containing a full loop beat sixty screens of navigation and summary.
Build quality carries a second decision that students underestimate. A prototype does not need production polish, but it does need to work in the way it claims to work. If your design argument rests on adaptive feedback, the feedback branches have to exist and behave differently, because an evaluator who clicks the wrong answer and receives the same message as the right one has just found a gap between your document and your artefact. Where something is deliberately unbuilt, annotate it plainly and say what would be built in production. A stated boundary is professional; a silent one reads as an unfinished build.
Turning your rubric aspects into a build and write-up plan
WGU keeps the scoring detail for D299 in your Course of Study rather than in the public catalog. Read the rubric before you open any authoring tool, because the aspects usually determine what has to be interactive and what can be described. Each aspect scores independently on a three-point scale and needs a 2.
Build and documentation are usually scored separately, and the write-up is the part students compress at the end. Give it its own schedule rather than its own last evening.
The word budget, worked. Suppose the rubric has five scored aspects covering the documentation and the directions ask for around 1,600 words alongside the artefact. Reserve 150 words for the problem and audience statement and 110 for known limitations. That leaves about 1,340 for scored content, or 268 an aspect. Then weight it. The design rationale aspect and the evaluation aspect are the two that reward extra room, since both explain rather than describe. Take 55 words from each of the three descriptive aspects and add 82 to each of those two.
A scheduling rule that reflects how these courses actually go: build to seventy percent, test, then finish. Students who build to completion before testing discover problems at a point where fixing them means rebuilding, and the revision evidence an evaluator wants never appears.
A structure that fits a lab build and its documentation
Where the task directions prescribe the deliverable set, follow it exactly. Where they leave the documentation shape to you, this arrangement matches how build aspects are usually written.
| Section | What belongs in it | What earns the aspect |
|---|---|---|
| Problem and audience | The instructional problem, who has it, and the evidence that it exists | Usually unscored, but scope decisions are judged against it |
| Scope statement | What the prototype covers, what it deliberately excludes and why | Scored where the rubric names planning; a stated boundary is a strength |
| Design rationale | The learning strategies applied, each tied to a principle and to a feature in the build | The aspect that separates design from assembly; needs feature-level specificity |
| The artefact | The functional module, with a walkthrough path an evaluator can follow | Scored on whether it does what the rationale claims |
| Interaction and feedback | What the learner does and how the module responds to each outcome | Scored on responsiveness; identical feedback for all answers is the classic miss |
| Accessibility | Contrast, keyboard operation, captions, alternative text, reading order | Scored on the build itself rather than on an intention statement |
| Evaluation | Who tried it, what happened, what you changed as a result | Scored on the causal link between finding and change |
| Limitations and production notes | What is stubbed, what would differ in a real deployment | Scored for honesty; unstated gaps are found and penalised |
Give the evaluator a route through the artefact. A one-page walkthrough naming what to click and what should happen at each step protects you from being scored on a path you never intended anybody to take.
Evidence craft when the deliverable is a built thing
Build courses invert the usual evidence problem. The artefact is the evidence, and your job in the documentation is to make its design legible.
- Tie every rationale claim to a specific screen or interaction. Spaced retrieval is used means nothing; the review prompts on screens four, nine and fourteen space retrieval across the module is checkable.
- Cite the learning principle behind each strategy. Design courses at graduate level expect a source for the mechanism, not just a name for the technique.
- Document what you tested and with whom, even if it was two colleagues. Small and honest beats vague and impressive.
- Check accessibility in the artefact rather than describing it. Colour contrast, keyboard navigation and alternative text are verifiable, and evaluators can verify them.
- Clear your rights on assets. Stock images, audio and icons need permissive licences, and attribution belongs in the documentation.
- Use APA for the written work and keep quoted material minimal, since WGU scans submissions for similarity.
What reads as senior is a limitations section that names the shortcuts. Everybody stubs something in a prototype. A designer who says which parts are stubbed and what production would require is describing a plan; one who says nothing is hoping the evaluator does not click.
What separates Competent from a submission sent back
Aspects score independently, so returns here are usually specific: the artefact does not do what the documentation says, or the evaluation section reports opinions rather than changes.
- Every scored aspect has a heading using the rubric's noun.
- The scope is one complete learning loop rather than a thin pass over a whole course.
- Every rationale claim points at a feature that exists in the build.
- Feedback differs by learner response wherever the design says it should.
- Accessibility is present in the artefact and verifiable.
- Each change in the evaluation section names the finding that caused it.
Performance assessment work at WGU can be revised and resubmitted with no grade penalty, which matters more here than in a writing course, since rebuilding takes longer than rewriting. In a six-month flat-rate term the arithmetic is unforgiving: courses closed inside the term is the only figure that changes your effective cost per course.
Where D299 sits alongside a proctored objective assessment, the boundary holds: we prepare only, never sit an assessment, and never ask for portal credentials.
Six mistakes that cost time in D299
- Scoping a course instead of a module. Breadth at prototype quality leaves nothing deep enough to score well, and the deadline arrives with the interesting part unbuilt.
- Choosing the tool before the design. Authoring platforms have opinions, and a design shaped by the default template is a design somebody else made.
- Writing generic feedback. Correct and incorrect are not feedback. Responding to what the learner appears to have misunderstood is the point of building rather than describing.
- Testing after the build is finished. Findings that arrive with no time to act on them produce an evaluation section with no revisions in it.
- Leaving accessibility for later. Retrofitting keyboard operation or contrast into a finished module is slower than building it in, and the aspect is scored on the artefact.
- Submitting without a walkthrough. An evaluator who cannot find the interaction you are proudest of will score what they did find.
How support works on this course
Send the rubric from your Course of Study, the task directions and your problem statement before you build. What comes back is a scope you can finish, a rationale that ties every strategy to a feature, a test plan that fits inside your schedule, an accessibility checklist for the build, and documentation mapped aspect by aspect once the artefact exists.
The scoping judgment is the durable skill. The capstone sequence asks you to design, build and evaluate at greater length, and students who learned here what fits inside a term arrive at the capstone with a realistic plan instead of an ambitious one.
Questions students ask about D299
Is D299 the same course as LXD 6052?
Which authoring tool should I use?
Can you build the module for me?
About to start building and unsure of the scope?
Send your Course of Study rubric, the task directions and your problem statement. You get a scope that fits the term and a rationale plan tied to features you will actually build.
Where D299 sits in WGU's programs
The July 2026 catalog places this code in 3 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.