WGU C773: User Interface Design

What C773 Actually Asks of You

WGU C773, User Interface Design, sits in the School of Technology and is the course where software and IT students stop asking whether a thing works and start asking whether a person can use it. It covers user interface design project constructs, the design process itself, user-centered web design, core design principles, color and typography and layout, wireframing, navigation hierarchy, and the design of interactive elements. What makes it different from most of the technology catalog is how it is graded: you are not recalling definitions, you are producing design work and defending your choices in writing.

Direct answer: Treat C773 as a small consulting project, not a study-and-test course. Read the task prompt and rubric before you read a single page of course material, then work backwards — every wireframe, page, and paragraph you produce should answer a specific rubric line, using the vocabulary the rubric uses. Students who read the rubric last are the ones who get sent back for revision.

An administrative note before you plan anything: C773 is an older course code and may not appear on newer versions of every degree plan. Confirm the code, title, and assessment details on your own Degree Plan in the WGU portal, since materials and requirements are attached to the version you were placed in. If your plan lists a differently coded course with a similar title, the approach below still transfers, but check the specifics with your course instructor.

Students usually meet this course inside a software development, web development, or IT-facing path, often near foundational coursework such as D322 Introduction to IT. It punches above its size: interface decisions are the part of your work users judge first, and the accessibility content is the same content that keeps real products out of ethical and legal trouble.

The Competency Areas Your Submission Is Graded Against

C773 is assessed by a submitted performance assessment rather than a proctored exam. The published competencies cluster into a handful of areas, and a complete submission touches nearly all of them:

• Project constructs — stakeholders, audience, goals, scope, and constraints, described clearly enough that a reader understands who the design serves.
• The design process — the phases from research through evaluation, and why each one exists.
• User-centered web design — the relationship between what a real user is trying to accomplish and what the site actually offers them.
• Design principles — hierarchy, alignment, proximity, contrast, consistency, feedback, error prevention, and recognition over recall.
• Color, typography, and layout — choices made for meaning and legibility rather than taste, with accessibility contrast treated as a requirement.
• Wireframing — a structural plan for a page, showing what goes where and why, before any styling exists.
• Building the interface — actual pages that demonstrate best practice, with a navigation hierarchy that holds together.
• Interactive elements — forms, controls, validation timing, error messages, confirmation, and undo.

Your task prompt supplies a case-study client with stakeholders and an audience. Every design decision you make needs to trace back to that client's users, not to what you personally find attractive. Evaluators are reading for that chain of reasoning more than for polish.

How Hard Is It, and How Long Should You Budget?

The concepts in C773 are approachable, and the reading is lighter than a programming or math course. The difficulty lives somewhere else: this is a written and built deliverable, and unclear writing or a missing rubric element sends it back regardless of how good the design is. Students with front-end, design, or product experience move quickly. Students who have never written a design rationale usually spend more time on the prose than on the pixels.

Rather than budgeting by day count, budget by milestone: rubric read, client and audience analysis drafted, wireframes done, pages built, rationale written, self-review against the rubric, submit. Leave room in your term for at least one revision cycle, because evaluator feedback on a first submission is normal rather than a failure.

If you are carrying something heavier in the same term, such as D385 Software Security and Testing, start C773 early. Task-based courses reward steady work far more than a final sprint, and a submission sitting in the evaluation queue does not care how busy your last week is.

A Working Plan for the Task

The most effective structure moves from understanding the client to defending your decisions, with the build in the middle rather than at the start.

1. Start with the rubric. Copy every rubric line into a document and leave space under each. That document becomes your outline, your progress tracker, and your final self-check. Note the exact nouns the rubric uses and reuse them in your headings.
2. Analyze the client and the audience. Write down who the stakeholders are, who the users are, what each group wants, and where those wants conflict. Almost every later justification you write will point back to this section.
3. Learn the principles well enough to name them. Work through the course material and, for each named concept, write the definition in your own words, one example done well, and one done badly. The bad examples are what make your critique specific instead of vague.
4. Do interface teardowns. Open three sites in the client's sector, one of them deliberately clunky, and write five observations each that name a principle and the fix you would make. This is the exercise that turns memorized terms into usable design language.
5. Wireframe before you style. Structure first: what content exists, how it is grouped, what the navigation hierarchy is, where the primary action sits. Sketching on paper is fine. Do not open a color picker yet.
6. Build, then run an accessibility pass. Check text alternatives, heading structure, keyboard operability and visible focus, contrast, and form-control labels. Consult the official accessibility standards directly rather than a summary, and say in your writeup which requirements you applied.
7. Write the rationale, then self-evaluate. For each decision, state the choice, the principle behind it, and the user benefit. Then read your draft against the rubric line by line and mark anything that is implied but not explicitly stated. Implied does not score.

One habit worth naming: when two design options both seem fine, choose the one that reduces the user's effort, memory burden, or chance of making an error, and write that sentence down. It is a defensible tie-break and it reads well to an evaluator. The same disciplined rhythm serves you in D197 Version Control and other short technology courses.

Where Submissions Come Back for Revision

• Design decisions with no stated reason. A beautiful page with no rationale scores worse than a plain one that explains itself.
• Answering with personal taste. "This looks better" is not an argument. "This supports the stated user task because…" is.
• Partial rubric coverage. Missing one required element is the single most common cause of a return, and it is entirely preventable with a line-by-line check.
• Treating accessibility as optional polish. It is threaded through the competencies and it is easy for an evaluator to verify.
• Skipping the process content. Research inputs, prototyping fidelity, and evaluation methods feel less interesting than visual design and are still part of what you must demonstrate.
• Reusing someone else's work. Submissions are checked for originality. Do not copy, paraphrase, or buy a completed task — a plagiarism finding is a far bigger problem than a revision request.

Readiness Checklist

• Have you mapped every rubric line to a specific section of your submission?
• Can you describe your client's stakeholders and audience, and the conflict between their goals?
• Does each design choice have a stated principle and a stated user benefit?
• Do your wireframes show structure and hierarchy rather than styling?
• Does your navigation hierarchy hold up if someone lands on a deep page first?
• Can you state what you did about text alternatives, headings, keyboard use, focus, and contrast?
• Are your form errors constructive, specific, and recoverable?
• Can you explain when you would use low-fidelity versus high-fidelity prototyping?
• Can you distinguish expert heuristic evaluation from usability testing with real users?
• Has someone outside the course read your rationale and understood it without you explaining?

FAQ

Is C773 an objective assessment or a performance assessment?

Public course-material listings for C773 consistently show a submitted task with a grading rubric rather than a proctored exam, and the course competencies are written as things you build and explain. Your Degree Plan and course page in the WGU portal are the authoritative source for your version of the course, so confirm there before you plan your term.

How long does C773 usually take?

It varies widely with writing speed and prior design exposure, and no reliable public figure exists. Plan by milestone instead: analysis, wireframes, build, rationale, self-review, submit — and leave slack for one round of evaluator feedback.

Do I need design software or prior design experience?

No prior experience is required, and you are not graded on tool proficiency. Paper sketches, a free wireframing tool, or ordinary presentation software are all workable. What is graded is the quality of your decisions and how clearly you justify them.

How much does accessibility matter here?

Treat it as a core requirement rather than a finishing touch. It has firm, checkable rules, which makes it one of the easiest places to lose points through omission and one of the easiest to secure with a deliberate pass before you submit.

What should I do if my task is returned for revision?

Read the evaluator comments against the rubric line they reference, fix only what is flagged plus anything obviously adjacent, and resubmit. Ask your course instructor to look at your revision plan first if the feedback is unclear. A returned first attempt is common and is not a mark against you.

Does this course help me outside of the degree?

Yes, more than most courses its size. Accessibility standards, form and error design, information architecture vocabulary, and the ability to justify a design decision in writing are used directly in professional software and web work. They pair naturally with the broader coursework on the School of Technology hub. You can browse the rest of our WGU course guides to plan your term, and confirm program details on the official WGU technology degree pages.