D654 Prototyping and Iterating I, catalog number DES 3300, is the three CU course in the WGU School of Business design sequence covering usability testing and iterating on mockups to create user centered digital products. It is the point in the sequence where an idea stops being defensible in the abstract and meets a person who has not been told what it is supposed to do.
The test is the deliverable
Students usually arrive at DES 3300 expecting the mockup to be the work. The mockup is the instrument. What is being scored is the testing: whether the sessions were designed to find problems rather than to confirm the design, what they revealed, and what changed as a result.
That distinction shows up immediately in how tasks are written for participants. A task that says have a look at this screen and tell me what you think produces opinion, and opinion is nearly worthless. A task that says you have just been charged twice, find out what happened and get it fixed produces behaviour, and behaviour is data. Weak submissions consistently ask for reactions; strong ones set goals and then stay quiet.
The second scored theme is iteration with evidence. A change made because a participant struggled is defensible. A change made because you preferred the alternative is not, however sensible it looks. The aspects usually want a visible chain: observed difficulty, diagnosis of the cause, specific change, and a retest or a stated intention to retest.
Turning scored aspects into a section plan
The scoring detail sits in your Course of Study. Count the aspects and use them as headings in the written portion. Each is judged independently against a three point scale and each needs a 2, so a polished mockup paired with a weak test protocol is a returned task.
This course produces prototypes, session notes and revised mockups. Name each artefact where it answers an aspect and refer to specific screens or versions by label, so scoring does not depend on interpretation.
The word budget, worked. Suppose six scored aspects and about 1,700 words of written work alongside the artefacts. Reserve 130 words for an opening naming the product and the users and 110 for a close. That leaves near 1,460, about 240 per aspect. Then take 50 words from each of two descriptive aspects and give 100 to the aspect covering findings and 100 to the aspect covering what you changed. Describing a prototype is cheap; reporting what happened when someone used it is the material that earns marks.
A structure that fits a usability testing deliverable
Where your directions specify a structure, follow it. Where they do not, this ordering matches how testing aspects tend to be scored.
| Section | What belongs in it | How it gets read |
|---|---|---|
| Prototype scope | What the mockup covers, at what fidelity, and what is deliberately missing | Stating what is not built prevents participants testing the wrong thing |
| Test plan | Goals, participant profile, tasks written as goals, and what would count as failure | Defining failure in advance is what makes findings credible |
| Sessions | How many, how conducted, and how you avoided leading participants | Facilitation discipline is itself scored in many rubrics |
| Findings | What happened, by task, with severity assigned | Observations without severity leave prioritisation unexplained |
| Diagnosis | Why each problem occurred, in terms of a design principle | Separates a fix from an understanding |
| Iteration | The changes made, shown as before and after | The core evidence of the course |
| Next round | What remains untested and what you would do next | Naming the gap reads as competence rather than as omission |
Write the tasks before finishing the prototype. Tasks written afterwards tend to follow the paths you happened to build, which guarantees the test avoids exactly the places the design is weakest.
Evidence craft for usability work
Usability findings are easy to assert and easy to substantiate, and the difference is visible in scoring.
- Report by task and by participant. Three of five participants failed to complete task two is a finding; users found it confusing is not.
- Record what participants did before what they said, since behaviour is the stronger evidence.
- Assign severity with a stated scale, so prioritisation is visible rather than implied.
- Quote participants sparingly and anonymise them, and never quote in a way that mocks a person for struggling.
- Cite usability principles and any heuristic set you applied, rather than treating them as general knowledge.
- Use APA in the written portion and credit any assets or components you did not create.
Include a problem you decided not to fix, with the reason. Prioritisation is part of the competence being assessed, and a submission that fixed everything either had a trivial prototype or ran out of honesty.
What separates Competent from a submission sent back
Independent aspect scoring keeps returns narrow, and here they land on protocol and diagnosis.
- Tasks are goals rather than instructions, and none of them name the control the participant should use.
- Success and failure were defined before the sessions ran.
- Findings are reported by task with counts and severity.
- Every change traces to an observed problem, not to a preference.
- Before and after states are both shown.
Performance assessment work can be revised and resubmitted with no grade penalty, so a return costs calendar. Terms run six months at a flat rate, and testing needs participants who have to be scheduled, so the elapsed time here is longer than the effort suggests.
Six mistakes that cost time in D654
- Tasks that name the button. Telling someone to use the filter control tests whether they can read, not whether the design works.
- Helping during the session. The silence when a participant is stuck is where the finding is; filling it destroys the data.
- Collecting opinions. What people say about a design correlates poorly with whether they can use it.
- Too much fidelity too early. A polished mockup attracts comments about colour and hides structural problems.
- Fixing symptoms. Moving a control that nobody found may not address why it was invisible.
- No severity or prioritisation. A flat list of issues gives an evaluator no evidence of judgment.
- Testing with people who already know the design. Anyone who has heard you describe the concept cannot produce first use data, and a session with a friend who is trying to be encouraging generates warmth rather than findings.
Running a session that produces usable findings
The mechanics of a usability session are where inexperienced testers lose most of their data, and the fixes are small and specific.
Open by lowering the stakes properly. Say that the design is being tested rather than the participant, and mean it, because people who feel examined stop reporting confusion and start performing competence. Ask them to think aloud, then demonstrate what that sounds like for ten seconds, since most people do not naturally narrate.
Give one task at a time and then stop talking. The instinct to fill silence is the single biggest source of contaminated results, because a small hint at the moment of hesitation erases the exact finding you came for. Count to ten before saying anything. If they ask what they should do, return the question: what would you do if I were not here.
Watch for the moments that matter more than the outcome. Where their hand hovers before moving. Where they scroll past the thing they need. Where they say the word interesting, which almost always means confused. Where they complete the task successfully but by a route you did not anticipate, which is a finding about your model of the product rather than about them.
Close by asking about the experience only after all tasks are done, so opinions cannot influence the behaviour you were measuring. Then write your notes within the hour. Memory of a session degrades quickly, and notes written the next day tend to record conclusions rather than observations, which is exactly the material a rubric wants you to have kept.
How support works on this course
Send the rubric from your Course of Study and the task directions. What comes back is aspect mapped: a test plan with tasks written as goals, a facilitation guide, a findings format with counts and severity, diagnosis tied to design principles, and before and after documentation. The sessions and the participants stay yours, because observed behaviour is the one thing that cannot be supplied.
D654 pairs directly with the second prototyping course, and work started here carries forward. Terms run six months at a flat rate, so scheduling participants early is the difference between one term and two.
Questions students ask about D654
Is D654 the same course as DES 3300?
How many participants does a usability test need?
Can you build the prototype and run the tests?
Where D654 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. 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.