D800 Human-Computer Interaction, catalog number ICSC 6203, is the four-CU graduate course in the WGU School of Technology that builds interface work on evidence from psychology, design and engineering rather than on taste. The deliverable is almost never a beautiful screen. It is an argument with a screen attached: here is the user population, here is what research on attention, memory and error predicts about them, here is the design decision that follows, and here is the evaluation that tested it. Strong developers lose the most time here, because the interface feels like the work when the reasoning is the work.
What ICSC 6203 is actually testing
Three separate abilities sit inside a graduate human-computer interaction course, and rubric aspects tend to sample all three. The first is describing a user population without inventing it. A persona assembled from your own assumptions is not user research, and evaluators reading a graduate submission can tell the difference between a population characterised from observation, interview, task analysis or published study and one characterised from imagination. If your project genuinely has no access to users, say so and name the substitute you used, because a stated limitation reads as method and an unstated one reads as a gap.
The second is applying a named principle and showing the trace from principle to pixel. Recognition beats recall, so the toolbar shows labelled actions rather than expecting the operator to remember a keystroke. Working memory is small, so a seven-step wizard carries forward the values already entered instead of asking twice. Targets that are small and far apart cost time and errors, so the destructive action is not adjacent to the one used forty times an hour. Each of those sentences has the shape evaluators want: principle, consequence for this user, design decision. A submission that lists heuristics in one section and shows a design in another, with no line drawn between them, has answered two aspects at half strength.
The third is evaluation as a method rather than an opinion. Heuristic evaluation and usability testing answer different questions, cost different amounts and fail in different ways. Graduate work names which one it ran, why that method fits the question asked, how many people took part in what role, and what the method cannot tell you. An expert walkthrough with three reviewers finds violations of known principles; it does not tell you what a real operator will do at the end of a night shift.
Turning scored aspects into a design report plan
WGU keeps scoring detail inside your Course of Study rather than in the public catalog, so the first working session on D800 is a reading session. Open the rubric, count the aspects, and write them down as a list before you write anything else. Every aspect is judged on its own against a three-point scale, and a score of 2 in each one passes the task. Nothing averages, so a superb design rationale does not lift a thin evaluation section.
Where the course is assessed by a performance assessment, that aspect list is your outline. Use the rubric's own nouns as headings. Evaluators are scoring aspect by aspect, and a document arranged in the order they read is a document that gets scored rather than searched.
The word budget, worked. Say your rubric shows seven scored aspects and the directions ask for a report of about 2,600 words. Reserve 180 words for an opening that names the system, the users and the problem, and 120 for a closing that states what you would do in the next iteration. That leaves roughly 2,300 for scored content, or 330 words an aspect. Then move money. Design rationale and evaluation findings are where graduate HCI submissions are won and lost, so take 50 words from each of the four descriptive aspects and hand 100 extra to each of those two. An aspect answered in 90 words is nearly always a claim with no trace behind it, and an aspect that swells past 600 has usually eaten its neighbour.
Artefacts complicate the arithmetic. Wireframes, flow diagrams and prototype links carry evidence, but they do not carry the argument on their own. Budget a caption and two or three sentences of prose for every artefact you include, explaining what it shows and which claim it supports, and count those words inside the aspect they serve.
A structure that fits an HCI design and evaluation report
Where your task directions specify their own headings, those directions win every time. Where they leave the arrangement to you, this shape maps cleanly onto how interaction design aspects are usually written.
| Section | What belongs in it | What earns the aspect |
|---|---|---|
| Problem and users | The system, the tasks it supports and who performs them, with how you know | Scored for grounding; sourced characterisation beats a confident guess |
| Requirements and scenarios | Task scenarios written as something a person does, not as features | Scored for realism and for covering the tasks that actually matter |
| Design rationale | Each significant decision with the principle and the user evidence behind it | The aspect thin submissions fail; a decision with no reason is decoration |
| Prototype description | Fidelity, scope, what is interactive and what is stubbed | Scored for honesty about what was built rather than for polish |
| Evaluation method | Method, participants or reviewers, tasks, measures and procedure | Scored for repeatability; a stranger should be able to run it again |
| Findings | What happened, separated cleanly from what you think it means | Scored for evidence handling; observation and inference kept apart |
| Revisions | Changes driven by findings, with the finding named for each change | Scored for the loop closing; changes with no finding behind them read as taste |
| References | HCI literature, standards and any published data about the population, APA formatted | Scored where citation is named; a used source with no in-text citation is a return |
Keep one rule through the whole document: every claim about a user is either observed, cited or labelled as an assumption. Graduate evaluators are lenient about small studies and unforgiving about confident invention.
Evidence craft when the evidence is human behaviour
Interaction design work has an unusual evidence mix. Half of it is published research about how people perceive and remember, and half is data you generated by watching people use something. The two are cited differently and abused differently.
- Attribute principles to their source. Established heuristic sets, standards for usability and accessibility, and textbook models of memory and attention all have authors and dates. Writing that users prefer consistency, with nothing behind it, is an opinion in a graduate paper.
- Report the shape of your study before its results: how many participants, how recruited, what tasks, what counted as success, how long the sessions ran.
- Keep observation and interpretation in separate sentences. Four of six participants clicked the wrong control at step three is an observation. They mistook the icon for a save action is an interpretation and needs the evidence that supports it.
- Quantify what can be quantified without pretending to precision you do not have. Times, error counts and completion rates are useful with six participants; statistical significance is not.
- Treat consent and privacy as part of the method. Say that participants agreed to take part and that recordings or transcripts were handled with identifiers removed.
- Never invent participants or fill a results table with plausible numbers. Fabricated user data is the one failure in this course that a resubmission cannot repair.
The strongest graduate submissions state the limits of their own evidence in one plain sentence, then continue. Five participants from one department cannot represent a national user base, and saying so before an evaluator says it for you converts a weakness into evidence of judgment.
What separates Competent from a submission sent back
Aspects score independently, so returns in D800 are usually narrow. A design report rarely comes back because the design was poor. It comes back because one aspect asked for a justification and received a description.
- Every design decision that matters has a named principle or a named finding behind it.
- The user population is characterised from something, and the something is stated.
- The evaluation section describes a method precise enough to repeat, not a summary of impressions.
- Findings are separated from interpretations, and revisions point back to specific findings.
- Accessibility appears as a design consideration rather than a paragraph bolted to the end.
- Artefacts are captioned and explained, and nothing important lives only inside an image.
Performance assessment work at WGU can be revised and resubmitted without a grade penalty, so a return costs time rather than standing. Time is the whole budget in a six-month flat-rate term: a four-CU course that closes in week five instead of week fifteen is what makes the next course possible. Where any part of this course is assessed by a proctored objective assessment, we prepare only. We build a study plan, drill the principles and the evaluation methods and give an honest readiness call, and we never sit an assessment or ask for portal credentials.
Six mistakes that cost time in D800
- Designing for yourself. The person who built the system is the least representative user of it. Every decision defended by what feels natural is a decision with no evidence.
- Listing heuristics without applying them. A section that names ten principles and a design section that mentions none leaves the connective aspect unscored.
- Confusing a preference survey with a usability test. Asking people whether they liked an interface measures something, but not whether they could use it.
- Skipping the task analysis. Interfaces are judged against tasks. Without a task list, findings have nothing to be findings about.
- Treating accessibility as a compliance appendix. Contrast, focus order, target size and error messaging are design decisions with rationale, and they belong in the rationale section.
- Polishing the prototype and rushing the write-up. The rubric scores the document. A beautiful mockup with a thin evaluation section is the most common return in graduate HCI work.
How support works on this course
Send the task directions and what your Course of Study says about how D800 is scored. What comes back is aspect-mapped: a report skeleton with the rubric's own nouns as headings, a design rationale rewritten so each decision carries its principle and its evidence, an evaluation protocol written so somebody else could run it, and a findings layout that keeps observation apart from inference.
We also review the parts students most often over-build. A prototype at the wrong fidelity eats days without moving a single aspect, and knowing when to stop drawing and start writing is worth more in a flat-rate term than any extra screen.
Questions students ask about D800
Is D800 the same course as ICSC 6203?
Do I need design or graphics skills for D800?
Can you run my usability study or sit the exam for me?
Design report due and the rationale section is thin?
Send the task directions and your Course of Study rubric. You get an aspect-mapped report skeleton, a rationale that traces each decision to evidence, and an evaluation protocol somebody else could repeat.
Where D800 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.