D279 User Interface Design is banner number ITSW 3110 and three competency units in the School of Technology. The catalog lists its subject matter unusually specifically: interface tools and techniques for web and mobile, including clarity, usability, detectability and color schemes. Those four words are effectively a rubric preview, because they describe properties of an interface that can be argued about and demonstrated rather than tastes that can only be asserted. What the course builds toward is the ability to defend an interface decision to somebody who disagrees with it.
Four properties, none of which are taste
Interface work attracts opinion, and a course that graded opinion would be ungradable. The four properties in the catalog description are chosen because each can be evaluated against evidence. Clarity asks whether a user can tell what a control does before using it. Usability asks whether the task can be completed efficiently and without error. Detectability asks whether the user can find the control at all, which is a separate question from whether it is understandable once found. Color schemes bring measurable constraints, because contrast ratios are numbers and color blindness affects a known share of users.
Detectability is the property students are least prepared for, and it is where a lot of real interface failure lives. A perfectly labeled button that sits below the fold, or that looks like body text because the affordance was styled away, fails before clarity ever gets a turn. Visual hierarchy, contrast against surroundings, position relative to where attention lands and consistency with what the same control looked like on the previous screen all serve detectability.
Consistency is the invisible half of the subject. Internal consistency means the same action looks and behaves the same everywhere in your product. External consistency means it matches what the platform's users already expect, which is why platform design guidelines matter: an interface that invents its own patterns spends the user's attention on learning rather than doing.
Web and mobile appear together in the description on purpose. Touch targets have a minimum comfortable size, hover does not exist on touch, and the reachable area of a phone screen held one-handed is not the whole screen. A design justified only for a mouse is half a design in this course.
Turning scored aspects into design decisions and a budget
Each rubric aspect at WGU is judged on its own, needs a score of 2, and cannot be carried by a neighbor. In a design course the most reliable conversion is aspect to decision, then decision to evidence. Every aspect that asks about a property should end up pointing at a specific choice in your artifact and a reason that is not personal preference.
Try the numbers. Suppose eight scored aspects and a design rationale document of roughly 1,600 words. Eight into 1,600 is 200 each. Sort by demand. Two aspects are inventory, listing the screens or the components you produced, which needs about 100 each and releases 200. Four aspects map to the four properties and each wants a claim, the design choice that serves it, and the evidence, so those take 275 apiece, which is 1,100. One aspect asks about the design process you followed, 200. One asks for a reflection or a next iteration, 200. That totals 1,700, so trim the two lighter property sections to 230 and you land near 1,610 with two thirds of the document doing property argument.
Set up an evidence column while you design rather than after. Next to each decision write what supports it: a contrast ratio, a platform guideline, a heuristic, a task time from a walkthrough, or an observation from a person who tried it. Decisions with an empty evidence cell are the ones that will read as preference.
Working the D279 design task?
Send the aspects plus the interface brief. You get a decision table with evidence attached to each row and a model rationale document.
The decision record an interface deliverable runs on
| Decision | Property it serves | Evidence that supports it |
|---|---|---|
| Primary action styled as a filled button, secondary as outlined | Detectability and clarity | Contrast ratio measured, visual weight ranked against surroundings |
| Labels above fields rather than inside them | Clarity | Placeholder text disappears on focus, so the label is gone when needed |
| Destructive actions separated and confirmed | Usability, error prevention | Recovery cost is high and the action is irreversible |
| Status shown by icon and text, never color alone | Color scheme accessibility | Color vision deficiency affects a meaningful share of users |
| Touch targets at the platform minimum or larger | Usability on mobile | Platform guideline figure, cited |
| Navigation in the same position on every screen | Detectability through consistency | Search cost falls when position is learned once |
| Errors shown next to the field that caused them | Clarity and recovery | A message at the top of the form does not say which field |
Seven rows like this, written in your own product's terms, will answer more scored aspects than three pages of description of how the interface looks.
What counts as evidence when the artifact is a design
Four evidence types carry design arguments. Measurements are the strongest and the most neglected: a contrast ratio, a target size in the platform's units, a count of steps to complete a task. Published guidance is the second: platform design guidelines and accessibility guidance are documents you can cite by section. Established heuristics are the third, and they carry weight when applied to a specific element rather than listed. Observation is the fourth, and even one person attempting your task while you watch produces a finding worth more than a paragraph of assertion.
Cite properly in APA where your program requires it. Platform guidelines are organizational web sources with retrieval dates, since they revise. Accessibility guidance has version numbers and named success criteria, so name the criterion rather than referring to accessibility standards in general. Heuristics have authors, and attributing them costs one citation.
Present the artifact so it can be assessed. Number every screen or component figure, caption it with what it demonstrates, and annotate directly on the image where a decision is visible. An evaluator reading your rationale should not have to scroll back and forth guessing which element you mean, and an annotated callout removes that work entirely.
What reads as Competent, and what comes back
WGU marks work Competent or Not Competent, there are no letter grades and no ordinary grade point average, and a performance assessment that misses an aspect returns for revision without penalty. The cost is time in a six month flat rate term, so the objective is a first submission where no aspect rests on preference.
Rationale that reads as Competent has a repeated shape. Here is the decision. Here is the property it serves. Here is the evidence. Here is the alternative I rejected and what it would have cost. That last sentence is the one that most separates strong from adequate, because considering an alternative demonstrates that the choice was made rather than defaulted to.
Returns come from three habits. Description standing in for justification, where a paragraph explains what the screen contains and never says why. Assertions with adjectives instead of measurements, such as claiming a color scheme is accessible without a ratio. And the four catalog properties left unmentioned by name, which is a needless risk when the words themselves signal what the course cares about.
Six mistakes that cost D279 students time
- Designing the pretty version first. Structure and hierarchy decided in low fidelity are cheap to change. The same decisions made in a polished mockup are expensive.
- Color as the only signal. Status by color alone fails for a real share of users and is one of the fastest defects to spot in a submitted design.
- Placeholder text as the label. It vanishes exactly when the user needs it, and it usually fails contrast as well.
- Inventing patterns. Novel navigation costs the user learning time. External consistency with the platform is a defensible position, novelty usually is not.
- Ignoring the states. Interfaces have empty, loading, error and full states. Designing only the full state leaves most of the real experience undesigned.
- Writing rationale after the design is finished. Reasons reconstructed at the end are the ones that read like preference, because that is what they are.
How we work on this course
D279 support is argument construction. Send the scored aspects and the brief and you get a decision record with an evidence column filled in, the measurements and guideline citations that turn preferences into positions, an annotation plan for your figures, and a model rationale document written the way WGU evaluators read design work. Where a section of the course is assessed by an objective assessment, we prepare only, with concept notes and practice items. Objective assessments are proctored, we never sit or assist during one, and we never ask for or use portal credentials.
Interface courses are among the ones students underestimate, because the artifact is quick and the rationale is not. Planning the argument first is what keeps three units inside the term you meant to close them in.
Three questions D279 students ask
Is D279 the same course as ITSW 3110?
What is the difference between D279 and D479?
Which design tool should I use?
Where D279 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.