WGU D299: Learning Experience Design Lab

Where D299 Fits in Your Learning Design Program

D299, Learning Experience Design Lab, is where everything you have been reading about learner analysis, design thinking, accessibility, and learning technology stops being theory and turns into something a real human being can click through. WGU lists it in both the M.S. Learning Experience Design and Educational Technology and the M.Ed. Education Technology and Instructional Design. It is worth 3 competency units in every standard path in WGU's program guides, and degree-seeking students take it only after the Learning Experience Design foundations series and the two courses in their chosen pathway, K–12 or adult learners.

Direct answer: There is no proctored test in D299. You pass by building a working prototype of an e-learning module that solves one clearly defined instructional problem, giving genuinely useful feedback on other students' modules, and then writing an honest analysis of the feedback you received along with a specific plan for acting on it. Read every line of the rubrics before you build anything, and pick a topic small enough to actually finish.

The course description WGU publishes is refreshingly plain. You identify an instructional problem, design and develop a functional prototype of an e-learning solution, experiment with design tools and techniques, provide quality feedback to peers, and receive quality feedback from peers about your own module. The final beat is the one that matters most professionally: obtaining user feedback and incorporating it to continuously improve the experience.

The course also carries structural weight. WGU's program guides list it as a prerequisite for the first capstone, Identifying Learner Needs and a Research Problem, so a stalled Design Lab stalls your whole run at the finish line. If you are still mapping out the degree, the School of Education guide hub collects the other courses you will meet along the way.

What the Design Lab Actually Measures

D299 is assessed through performance tasks; there is no multiple-choice component. Beyond the course-planning step every WGU course opens with, the published competencies name three things:

• Creating an e-learning experience that addresses a specific instructional problem. This is the build. You define the problem, define the target learner, write measurable objectives, and produce a functioning prototype module rather than a storyboard or a description of one.
• Providing quality feedback and recommendations for improving an e-learning experience, based on peer evaluation. You review classmates' modules and write feedback substantial enough to be actionable. Vague praise does not demonstrate this competency.
• Planning how to implement feedback and recommendations to improve an e-learning experience. You take what reviewers told you about your module and lay out how you would revise it, with reasoning for what you adopt and what you set aside.

WGU describes this program as built around seven cross-cutting themes — Design Thinking; diversity, equity, and inclusion; social and emotional learning; learning analytics; learning technology; Universal Design for Learning; and accessibility — and the Design Lab is where you show them in a finished artifact rather than an essay. Practically, that means objectives that are measurable and aligned to what the module teaches and checks, navigation a stranger can follow, and accessibility decisions that were deliberate. The storyboarding and usability-testing habits from Foundations II carry straight over, and if assessment alignment is your weak spot, so do the ones from D184 Standards-Based Assessment and D293 Assessment and Learning Analytics.

How Hard Is D299, and How Long Should You Budget?

Conceptually, D299 is one of the friendlier courses in the program: nothing to memorize, no test anxiety. The difficulty is logistical and craft-based — knowing what a good e-learning module looks like is easier than finding the hours to build one and getting it through a review cycle.

The scheduling trap is structural rather than anecdotal. The work is sequential by definition — you cannot analyze feedback you have not received yet, and peer feedback arrives on other people's timelines. WGU publishes no official completion time, and any week count quoted online is one student's experience rather than a benchmark, so build your own estimate: the hours the prototype will realistically take in the tool you plan to use, plus a buffer for turnaround you do not control. Two things shorten that timeline more than raw effort does — starting in week one of your term instead of week four, and choosing an authoring approach you already know or can learn in a weekend.

Use the waiting period rather than losing it. While peer feedback is in flight, review your own module against the rubric as harshly as a stranger would, and draft the skeleton of your feedback analysis so incoming comments get slotted into a structure instead of a blank page.

A Practical Build Plan for the Design Lab

Because this is production work rather than recall, the tactics that serve you look nothing like exam prep. Build backward from the rubric, and protect momentum.

1. Read the rubrics first, then write the problem statement. Paste every rubric aspect into a working document as a checklist row. Then write one paragraph naming the instructional problem, the target learner, and what those learners will be able to do afterward that they cannot do now. If that paragraph is fuzzy, everything downstream will be fuzzy.
2. Scope ruthlessly. Pick a narrow topic you already understand — a single workplace procedure, one math concept, one safety practice. A small module executed cleanly reads better than a sprawling one that is half-built.
3. Outline and align. Draft your objectives, then map each screen, activity, and knowledge check to a specific objective. Anything that does not map is either mislabeled or should be cut, and the table you build here is a gift to your future self when you write the analysis task.
4. Build in passes. Structure first, then content, then interaction, then polish. Check accessibility as you go — alt text, readable contrast, meaningful link text, captions or transcripts for media — because retrofitting it at the end is miserable.
5. Test it on a stranger before you submit. Hand the prototype to someone outside the course and watch where they hesitate. Every hesitation is a usability finding you can fix before an evaluator sees it.
6. Give the peer feedback you would want. For each module you review, name something specific that works, something specific that does not, and a concrete recommendation tied to a design principle.
7. Analyze rather than summarize. Group the feedback you received into themes, decide which recommendations you will implement and in what order, and justify the calls. Declining a suggestion is fine when you explain the design reasoning behind it.

Flashcards have little role here, but retrieval practice still does: before each work session, close your notes and write from memory what the rubric requires of the piece you are about to build. If you cannot reconstruct it, reread it before you spend two hours building the wrong thing. The curriculum-mapping discipline from D630 Designing Curriculum and Instruction I is the same muscle you are using here.

Where Design Lab Submissions Lose Points

The requirements most likely to trip you up are predictable, and all of them are avoidable before you submit.

• Describing a module instead of building one. The course asks for a functional prototype. A slide deck about your intended design is not the same deliverable.
• Objectives that cannot be measured. "Learners will understand workplace safety" gives an evaluator nothing to check. Name the observable behavior and the condition.
• Alignment drift. The objectives promise one thing, the content teaches another, and the knowledge check assesses a third. That gap is easy to spot from the outside.
• Accessibility treated as decoration. Missing alt text, low contrast, image-only instructions, and uncaptioned media undercut a module in a program that names accessibility and UDL as core themes.
• Thin peer feedback. "Nice job, very clear" does not demonstrate the feedback competency. Your comments have to be specific enough that the recipient could act on them tomorrow.
• An analysis that only summarizes. Restating what reviewers said is not a plan. The task wants your decisions and your reasoning.

D299 Readiness Checklist

• Can you state your instructional problem, your target learner, and your desired outcome in three sentences without hedging?
• Can you show a table mapping every screen and activity in your module to a specific measurable objective?
• Can you open your prototype on a device you did not build it on and navigate it without getting stuck?
• Can you point to concrete accessibility decisions — alt text, contrast, captions or transcripts, descriptive link text — rather than assuming your tool handled it?
• Can you explain how your knowledge checks give a learner useful feedback rather than just a score?
• Can you write peer feedback that names a specific element, a specific problem, and a specific recommendation grounded in a design principle?
• Can you sort the feedback you received into themes, defend which items you will implement first, and justify anything you chose not to adopt on design grounds rather than convenience?
• Have you reread each rubric aspect one final time and confirmed your submission addresses it explicitly?

D299 FAQ

Is D299 an objective assessment or a performance assessment?

D299 is assessed through performance tasks. There is no proctored multiple-choice exam. You submit a functional e-learning prototype, quality feedback on classmates' modules, and a plan for implementing the feedback you received.

How many competency units is D299 worth?

Three competency units. WGU's program guides list Learning Experience Design Lab at 3 CUs in every standard path for both the MSLxDET and M.Ed. ETID programs.

How long does D299 take?

WGU does not publish a completion time, and it depends on your tool fluency and how fast peer feedback comes back. Budget the build hours, add turnaround you do not control, and start early rather than compressing the peer stage at the end of your term.

What can I build my e-learning module about?

The course asks you to identify an instructional problem, which leaves the topic open — K–12 subject lessons and workplace training both fit, depending on your pathway. The safest choice is a narrow topic you already know well, because it lets you spend your effort on design quality instead of content research.

Do I need expensive authoring software to pass D299?

The course description points to experimenting with various e-learning design tools and techniques rather than to one required product. Choose something you can learn quickly and finish in; an accessible, well-structured module in a simple tool holds up better than an unfinished one in a complicated tool.

Where can I confirm the official course details?

Check your course page in the WGU learning portal and the official program page for the M.Ed. Education Technology and Instructional Design, since task instructions and rubrics are revised periodically. Everything on this site is independent study support and is not affiliated with or endorsed by WGU. You can browse the rest of our course guides on the full study guide index.