D479 User Experience Design is banner number ITSW 3111 and three competency units in the School of Technology. The catalog describes it as exploring user experience tools and techniques with an in-depth view of the activities and deliverables involved, and that phrasing tells you where the grading weight sits. This is a process course. The competency is not producing a beautiful screen, it is running the activities that produce a defensible one and generating the deliverables that carry the findings between them, which is why the artifact list runs from research through personas and journeys to a tested prototype.
A chain of activities, each feeding the next
The thing that separates strong from weak work here is traceability across the process. User experience deliverables are only worth anything when each one visibly comes from the one before it. Research produces findings. Findings produce personas and problem statements. Those produce journeys, which expose the moments where the experience breaks. Those moments produce requirements, which produce information architecture, which produces wireframes, which get tested, which produces the next round of findings.
Students commonly produce all of those artifacts and none of that chain. A persona invented from imagination, a journey map with no research behind it, and wireframes that would have been drawn identically without either. Every artifact is present, the aspects about the artifacts are technically satisfied, and the aspects about the process are not, because nothing in the deliverables shows a finding changing a decision.
Research is the foundation and the part students shortcut. Even a small number of real conversations changes the work, because real users say things nobody invents. If your course scenario supplies research data, treat it as primary evidence and quote it. If it expects you to gather some, a handful of structured interviews with people who resemble the audience is enough to ground everything downstream.
Testing closes the loop. A usability walkthrough with a few participants attempting real tasks produces findings that are specific, quotable and impossible to fabricate convincingly. Aspects that ask you to evaluate or iterate a design are asking for that loop, and a submission that ends at the wireframe has stopped one activity short of the competency.
Mapping aspects to deliverables and budgeting the write-up
Aspects are scored one at a time, a 2 is needed everywhere, and no aspect compensates for another. In a process course the aspects usually name activities, so the mapping is direct and the risk is different: it is easy to produce a deliverable that exists and does not connect.
Budget with connection in mind. Suppose twelve scored aspects and a report of about 2,100 words around the artifacts. Twelve into 2,100 is 175 each. Sort them. Six aspects are artifact aspects, where the deliverable itself is the answer and the prose only has to introduce it and read out the important finding, so 110 each, totaling 660 and releasing about 390. Three aspects are method justification, asking why this research method, why these participants, why this evaluation approach, and those take 300 each, or 900. Two aspects are synthesis, connecting findings to design decisions, at 250 each, or 500. One is reflection at 150. The total is 2,210, so trim one method section to 220 and one synthesis to 200, landing near 2,090 with method and synthesis taking two thirds of the words. That ratio is the point: the artifacts carry the content, the prose carries the reasoning.
Give every finding an identifier and reference it downstream. When a wireframe decision cites finding number four, the traceability aspect answers itself.
Running the D479 project now?
Send the aspects along with the project brief. You get an activity chain, a research plan sized to the scope, and a synthesis structure that connects findings to decisions.
The deliverable chain and what each link owes the next
| Deliverable | What it must contain | What it owes the next one |
|---|---|---|
| Research plan | Questions, method, participants, why each was chosen | A reason the findings can be trusted |
| Findings | Numbered observations with quotes or data, not conclusions | Identifiers that later artifacts cite |
| Personas | Goals, context, constraints, each traced to findings | A user whose needs decide priorities |
| Journey map | Stages, actions, thoughts and the friction at each stage | The specific moments worth designing for |
| Requirements | What the experience must support, derived from friction points | A scope the design can be checked against |
| Information architecture | Structure, labels and navigation logic | A skeleton the wireframes fill in |
| Wireframes or prototype | Task flows a participant can attempt end to end | Something testable rather than viewable |
| Evaluation | Tasks, participants, what happened, what it means | The next round of findings |
Read the last column down the table. If any row cannot deliver what it owes, the artifact above it was decorative, and that is the gap process aspects are written to catch.
Research evidence, honesty and citation
User research evidence is qualitative and that makes precision more important, not less. Report what participants did and said before you interpret it, keep the count visible so a reader knows whether a finding came from one person or five, and quote rather than paraphrase where the wording carries the meaning. A finding written as users found the checkout confusing is an interpretation. A finding written as three of five participants stopped at the shipping step and two asked where the total was is an observation, and interpretations built on observations are defensible.
Do not invent participants. A fabricated study is both an integrity problem and a self-defeating one, because invented data produces findings that agree with the design you already wanted, and an evaluator reading a study where nothing surprising happened has a reason to look closely.
Where your work involves real people, handle their information carefully: consent to be observed, no identifying details in the deliverable, participant one and participant two rather than names. On secondary sources, published usability research, accessibility guidance and established method texts all cite cleanly in APA where your program requires it, and method claims should point at the source that defines the method rather than at a summary of it.
What passes, and what returns
WGU records Competent or Not Competent, with no letter grades and no ordinary grade point average, and revision after a return carries no penalty. A return costs calendar time inside a six month flat rate term, which is the reason to build traceability in from the first artifact rather than repairing it afterwards.
Passing submissions read as one investigation. The persona has a goal that appears in the research. The journey map has a friction point that appears in the requirements. The wireframe has a decision that cites a finding. The evaluation tests the task that the friction point identified. Nothing appears in a later artifact that has no ancestor in an earlier one.
Returns come from artifacts that float. A persona with a name, a photograph, a favorite coffee and no connection to any data. A journey map whose stages are generic rather than drawn from this product. Method sections that describe what an interview is instead of why these questions and these participants. And an evaluation that reports the design worked well, which is the result you get when the tasks were chosen to succeed.
Five mistakes that cost D479 students time
- Designing first and researching to confirm. Research done after the design decides nothing, and process aspects can tell, because no finding ever changes anything.
- Personas as characters. Demographics and hobbies are not the deliverable. Goals, context and constraints traced to findings are.
- Skipping evaluation for lack of participants. Three people attempting real tasks produces usable findings. Zero people produces an assertion.
- Reporting conclusions as findings. Observations first, interpretation second, clearly separated, or the reader cannot check your reasoning.
- Losing the identifiers. Without numbered findings the traceability aspects have nothing to trace, and you end up writing the connections from memory at the end.
How we work on this course
Support for D479 is built around the chain. Send the scored aspects and the brief and you get an activity sequence sized to the scope, a research plan with questions that will actually produce findings, a synthesis structure that carries identifiers from research through to evaluation, and a model report in the register WGU evaluators expect. Where any part of your course is assessed by an objective assessment, support is preparation only. Objective assessments are proctored, we prepare students and never sit or assist during any assessment, and we never ask for or touch portal credentials.
Process courses reward front loading. The plan is what keeps this inside one six month term rather than spreading across two, and terms are the unit that decides what each course actually costs you.
Three questions D479 students ask
Is D479 the same course as ITSW 3111?
How many research participants do I need?
Is D479 just D279 with more steps?
Where D479 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.