WGU D279: User Interface Design

What D279 User Interface Design is really about

WGU D279, User Interface Design, is a hands-on course in the School of Technology (you may see it under older codes such as C773 or ITSW 3110). Instead of memorizing facts for a timed test, you learn to design screens the way a working UI/UX designer does: you study a set of user and stakeholder needs, then produce interface artifacts that solve real problems. It shows up in software development and UX/UI degree paths because every application, website, and tool eventually needs an interface that people can actually use.

Direct answer: D279 is a performance assessment, not a proctored exam, so you "pass" by submitting a project that meets every rubric point. The reliable path is to read the rubric first, design deliberately for the users described in the scenario, keep your wireframes clean and mid-fidelity, and write a clear rationale that ties each design decision back to a user need and an accessibility principle.

If you have designed anything before, this course will feel approachable. If you have not, don't worry: it teaches a repeatable, principle-driven process rather than artistic flair. The goal is usability and justification, not making the prettiest screen in the room.

What the performance assessment covers

The submission is built around a scenario in which you analyze needs and then design an interface to address them. The core topic areas you should be comfortable with include:

• User-centered and human-centered design — identifying who the users are, what they are trying to accomplish, and their pain points.
• Stakeholder and audience analysis — translating business goals and user goals into concrete interface requirements.
• Information architecture and navigation — organizing content and labeling menus so people can find what they need.
• Wireframing and mid-fidelity prototyping — sketching layout, hierarchy, and flow, commonly in a tool like Figma or Adobe XD.
• Accessibility — applying WCAG-style thinking: color contrast, readable typography, alt text, keyboard focus, and clear error handling.
• Responsive and adaptive layout — considering how the interface behaves across desktop and mobile.
• Usability and interaction states — hover, focus, active, disabled, empty, and error states, plus feedback for user actions.

Because the deliverable is a document plus design artifacts, the evaluator is looking for evidence and reasoning, not just finished pictures. Every screen you show should be explainable.

How hard it is and how long to plan for

D279 is widely considered one of the more approachable technology courses, largely because there is no timed test to fail. Many students report finishing in anywhere from a few days to about a week, depending on prior design experience and whether their first submission needs a revision. Treat those figures as a range, not a promise — your pace depends on how carefully you read the rubric and how much you rework.

The most common reason a submission takes longer is a returned task. Evaluators send work back when a rubric element is thin or missing, and the fix is usually small. Building thoroughly the first time is almost always faster than a revision cycle, so front-load the care rather than rushing to submit.

A study and build plan that fits this course

Traditional exam tactics like flashcards matter less here; the winning approach is deliberate, rubric-driven production. Use this sequence:

1. Turn the rubric into your outline. Copy each rubric criterion into your working document as a heading. When every heading maps to a rubric line, it becomes obvious what still needs to be answered before you submit.
2. Define your users and stakeholders first. Write down who they are, their goals, and their frustrations. This list is the reference point you return to for every later decision — it is the "why" behind your design.
3. Design the structure before the screens. Map the information architecture and navigation. Decide primary versus secondary navigation and label items in the user's language, not internal jargon.
4. Build mid-fidelity wireframes. Focus on layout, hierarchy, spacing, and flow. Resist the urge to polish visuals; mid-fidelity is the target, and over-styling can actually distract from the usability evidence the rubric wants.
5. Bake in accessibility as you go. Check color contrast, plan alt text, show a logical heading order and focus indicators, and design clear error prevention and recovery. Retrofitting accessibility at the end is where omissions creep in.
6. Annotate your interaction states and rationale. For each key screen, note the states (hover, focus, error, empty) and briefly explain why you made the choice, connecting it to a user need or a usability principle.
7. Do a rubric pass before submitting. Read each criterion out loud and point to the exact place in your document that satisfies it. If you cannot point to it, it isn't done yet.

Practicing "active recall" here means covering your rubric outline and trying to explain, from memory, why each design decision serves a specific user — if you can teach it, you can defend it in your write-up. This same design discipline pays off in later technology courses like C968 Software I, where you build the functionality behind an interface, and D286 Java Fundamentals.

Common mistakes students make in D279

• Skipping the "why." Beautiful screens with no rationale fail the parts of the rubric that ask you to justify decisions. Explain every meaningful choice.
• Over-designing. Pushing to high-fidelity visuals wastes time and can obscure the structure and usability the evaluator is grading.
• Treating accessibility as optional. Missing contrast notes, alt-text plans, or focus indicators is a frequent trigger for a returned task.
• Weak user and stakeholder analysis. If the foundation is vague, every design decision downstream looks arbitrary.
• Inconsistent labels and navigation. Calling the same thing two different names across screens signals a lack of care and invites revision requests.
• Ignoring the response to a revision. When work comes back, quote the exact rubric line, show your fix, and point to the updated artifact so the evaluator can verify it quickly.

D279 Readiness Checklist

Before you submit, confirm you can honestly say yes to each of these:

• Can you name your target users and stakeholders and state what each one needs from the interface?
• Can you point to where every rubric criterion is addressed in your document?
• Can you explain your information architecture and why your navigation labels match user intent?
• Can you show mid-fidelity wireframes for the required screens with clear hierarchy and spacing?
• Can you demonstrate accessibility choices — contrast, alt text, focus order, error handling — with specific examples?
• Can you show the relevant interaction states (hover, focus, error, empty) for key components?
• Can you justify each significant design decision by tying it back to a user need or usability principle?
• Have you checked that labels, buttons, and terminology are consistent across every screen?
• Have you proofread the write-up so it reads as a professional, self-explanatory design report?

D279 FAQ

Is WGU D279 an OA or a PA?

D279 is a performance assessment. You submit a design project rather than sitting a proctored objective exam, so there is no timed multiple-choice test to prepare for.

Is D279 hard?

Most students find it approachable, especially with any prior design exposure. The difficulty is less about complexity and more about attention to detail — missing a rubric element like accessibility or rationale is the usual reason work is returned.

How long does D279 take?

Many students report completing it within a few days to about a week, depending on experience and whether a revision is needed. Building carefully the first time is the fastest overall route.

What tools do I need?

A mid-fidelity wireframing tool such as Figma or Adobe XD is commonly used, along with a color-contrast checker and WCAG guidance for the accessibility portions. Follow the current course materials for the specific tools your version expects.

What should I focus on to pass?

Read the rubric first and design to it. Prioritize clear user and stakeholder analysis, sound information architecture, clean mid-fidelity wireframes, documented accessibility, and a written rationale for your decisions.

What if my submission is returned for revision?

That is a normal part of performance assessments and not a failure. Address each cited rubric line directly, quote it, make the fix, and clearly point the evaluator to the updated part of your document.

For more study guides, explore the School of Technology hub, browse the full guide library, or check the official WGU website for current course details. You may also find D197 Version Control useful as you move deeper into your technology coursework.