D655 Prototyping and Iterating II, catalog number DES 3400, is the three CU course in the WGU School of Business design sequence covering design critique and the incorporation of feedback into a high fidelity prototype. Where the first prototyping course brought in users, this one brings in other designers, and the two produce different kinds of information that a strong submission keeps distinct.
Critique is a different instrument from testing
Usability testing tells you what breaks. Critique tells you why a design is structurally weak before anyone has to break it. The two are not interchangeable, and DES 3400 rubrics tend to reward students who understand the difference and use each for what it is good at.
Critique is most valuable on things testing cannot reach: whether the visual hierarchy expresses the actual priority of the content, whether the interaction model is consistent with the platform's conventions, whether the system has a coherent structure or is a set of screens that happen to be adjacent, and whether the design will survive edge cases nobody built a mockup for. Those are expert judgments, and they need a framework rather than an opinion.
The second scored theme is what you did with the feedback. Incorporating critique does not mean accepting all of it. Skilled designers reject specific suggestions with reasons, and the reasoning is more scoreable than the compliance. A submission that changed everything it was told to change reads as unable to evaluate advice, which is a different failure from being resistant to it.
Third, high fidelity carries obligations. At this level a prototype is expected to handle states rather than only the happy path: loading, empty, error, disabled and long content are all part of what fidelity means, and their absence is one of the easiest things for an evaluator to notice.
Turning scored aspects into a section plan
Scoring detail lives in your Course of Study rather than the catalog. Count the aspects, then give each a heading in the rubric's own language. Each is judged independently against a three point scale and each needs a 2, so an attractive prototype with a thin account of critique is a returned task.
Version control matters here in a way it did not earlier. Label your prototype versions and refer to them by label when explaining a change, so an evaluator can follow the iteration rather than reconstruct it.
The word budget, worked. Assume six scored aspects and about 1,700 words alongside the prototype. Reserve 130 words to restate the product and the prior findings and 110 to close. That leaves near 1,460, about 240 per aspect. Then take 50 words from each of two descriptive aspects and add 100 to the aspect covering how critique was gathered and 100 to the aspect covering which feedback you rejected and why. Rejection with reasons is scarce material and it demonstrates judgment directly.
A structure that fits a critique and prototype deliverable
Directions win where they specify a shape. Where they do not, this ordering matches how the aspects tend to be scored.
| Section | What belongs in it | How it gets read |
|---|---|---|
| Starting point | The prior version and the findings it carried forward | Establishes what this round was trying to resolve |
| Critique method | Who reviewed it, what framework they used, what you asked them to focus on | Unfocused critique produces unfocused feedback |
| Feedback received | What was said, grouped by issue rather than by reviewer | Grouping shows synthesis rather than transcription |
| Evaluation of feedback | What you accepted, what you rejected, and the reasoning for each | The strongest evidence of design judgment available in the course |
| Changes made | Before and after for each change, tied to the feedback that prompted it | Traceability carries several aspects at once |
| Fidelity and states | Loading, empty, error, disabled and long content states | What high fidelity actually means; frequently missing |
| Handoff readiness | Specifications, components, and what a developer would still need to ask | Practical competence that separates strong submissions |
Ask reviewers a specific question rather than inviting general comment. What would break this for a first time user is a question that produces useful critique; what do you think produces colour preferences.
Evidence craft for critique work
The credibility of this submission rests on showing that critique actually happened and was actually weighed.
- Record feedback close to verbatim rather than in summary, since paraphrase softens exactly the parts worth acting on.
- Name the critique framework used and cite it, so the review has a structure rather than being a conversation.
- Group feedback by issue and note how many reviewers raised each, which is your prioritisation evidence.
- Show version labels on every screenshot so before and after pairs are unambiguous.
- Document accessibility checks with the standard applied, not by eye.
- Use APA in the written portion and credit component libraries, fonts and images you did not create.
Include the piece of feedback you disagreed with most, and the argument you would make to the reviewer. It demonstrates that you can hold a position under pressure, which is a professional competence the course is quietly assessing.
What separates Competent from a submission sent back
Aspects score independently, so returns are usually a single section deep.
- Critique was gathered against a stated framework and a focused question.
- Feedback is grouped by issue with reviewer counts attached.
- At least one piece of feedback is rejected with a documented reason.
- Every change shows a before and after and names its prompting feedback.
- The prototype includes non ideal states rather than only successful paths.
Performance assessment work at WGU can be revised and resubmitted with no grade penalty, so returns cost calendar rather than standing. Terms run six months at a flat rate, and high fidelity work is slow to redo, which makes a documented process more valuable here than in most courses.
Six mistakes that cost time in D655
- Asking for general opinions. Unfocused critique produces taste, and taste cannot be incorporated defensibly.
- Accepting all feedback. Compliance is not judgment, and reviewers frequently contradict each other.
- Only the happy path. High fidelity means the awkward states exist too.
- Undocumented changes. A revised prototype with no record of what changed loses the traceability aspects entirely.
- Confusing polish with fidelity. Fidelity is about completeness of behaviour, not about how finished the pixels look.
- Ignoring handoff. A prototype nobody could build from is an illustration, and saying what a developer would need shows you know it.
Running a critique that produces something usable
Critique is a skill with a structure, and running it well is most of what separates a strong D655 submission from a thin one.
Prepare the reviewers. Give them the user, the goal and the constraints before showing anything, because critique without context degrades into preference within a minute. Tell them explicitly what stage the work is at and what kind of feedback is useful now: structural questions at this point, not typography.
Ask a focused question. Where would a first time user get stuck. What does this design assume about the person using it. What happens here when the data is missing or enormous. Each of those produces specific, actionable material, whereas an open invitation produces a list of things people would have done differently.
Separate observation from prescription while you record. Reviewers usually offer solutions, and the solution is the least valuable part of what they said. Underneath it is an observation about a problem, and the observation is what you should capture, because it may have a better answer than the one suggested. Write both down but treat them differently in your analysis.
Afterwards, group by issue and count. Three reviewers independently pausing at the same screen is a strong signal regardless of what each proposed. One reviewer with a strong opinion about a colour is not. Then decide, and write the reasoning down while it is fresh. That written reasoning is the material several rubric aspects are looking for, and reconstructing it a fortnight later produces the vague justifications evaluators mark down.
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 critique protocol with focused questions, a format for grouping feedback by issue, reasoning for accepting and rejecting specific points, a state checklist for the prototype, and handoff documentation. Plus a walkthrough so the decisions are yours to defend.
D655 is the heaviest production course in the design sequence and it feeds the capstone directly. Terms run six months at a flat rate, so leaving prototype work until late in a term is the most common way this course spills into the next one.
Questions students ask about D655
Is D655 the same course as DES 3400?
Who can I ask for design critique?
Can you build the high fidelity prototype for me?
Where D655 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.