WGU D479 Task 1 Guide & Example: Complete UX Design Walkthrough

Updated on: Aug 21, 2026

If you’ve just opened the D479 Task 1 instructions and felt your stomach drop at the list of deliverables, you’re not alone. A timeline, a persona, a wireframe, guerrilla testing, feedback analysis, a prototype, and usability tasks all in one submission looks like seven separate assignments stacked on top of each other. It isn’t. WGU D479 Task 1 is one connected UX design process, and once you see how each piece feeds the next one, the workload stops feeling random and starts feeling logical.

This guide walks through that process in order: research, persona, timeline, wireframe, guerrilla testing, feedback analysis, prototype, and usability tasks. It’s written for the person doing this on a lunch break or after the kids are asleep, so every section is built to save you time, not add reading to your plate.

What Is WGU D479 Task 1?

D479, User Experience Design (also listed under the course code C856 in some catalogs), teaches the core UX design cycle: understand a user, translate that understanding into a design, test the design with real people, and refine it based on what you learn. Task 1 is where you do almost all of that work.

User experience design, at its core, means designing a product around what real users need and how they actually behave, rather than around assumptions. That’s why the assignment builds in a persona (so your design has a defined user to serve), a low-fidelity wireframe (so you can test structure before investing in visual polish), and guerrilla testing (so your design decisions get checked against real people instead of just your own judgment). The prototype and usability tasks that close out Task 1 exist to demonstrate that your design actually works for the user you defined, and they set up the peer usability review that typically follows in D479 Task 2.

As a quick mental model, the process for D479 WGU Task 1 looks like this:

Research → Define User → Wireframe → Test → Analyze → Prototype → Prepare for Usability Testing

Keep that sequence in your head as you read the rest of this guide. Nearly every rubric criterion in Task 1 is really just one step in that chain.

D479 Task 1 Rubric Breakdown

Your current course shell has the authoritative, up-to-date rubric wording, and you should treat it as the final word over anything here or anywhere else online. What follows is a plain-English walkthrough of what each type of requirement is generally asking for, based on the deliverables WGU has consistently required for this assessment: a timeline, a persona and design rationale, a low-fidelity wireframe, guerrilla usability testing, feedback analysis, an interactive prototype, and five usability tasks, plus APA citations for any outside images or sources you use.

Timeline requirement

What it means: You need to show that you planned the project as a sequence of phases rather than doing everything at once. What you need to produce: A simple table or chart listing each phase of your UX process and a timeframe for it. Evidence you should have: Dates or week numbers next to each phase, covering research through final review. Common mistake: Listing phases with no timeframes attached, which reads as a description rather than a timeline. How to check your work: Confirm every phase mentioned elsewhere in your submission (persona research, wireframe, testing, prototype) also appears in the timeline.

Persona and design rationale requirement

What it means: You need a defined user, built from research, whose needs actually shape your design choices. What you need to produce: A persona document with demographics, goals, behaviors, and pain points, plus a brief explanation connecting persona traits to specific design decisions. Evidence you should have: At least one explicit line connecting a persona need to a design decision (for example, a persona who travels with young children driving a decision to put family-friendly filters near the top of a search page). Common mistake: A persona that reads like a generic customer profile with no visible link to anything in the wireframe. How to check your work: Pick two persona traits at random and confirm you can point to where each one shows up in your design.

Wireframe requirement

What it means: You need to show the structural skeleton of your design before it’s polished. What you need to produce: Low-fidelity wireframes for the key pages or screens of your project, showing layout, navigation, and content hierarchy. Evidence you should have: Labeled sections, clear navigation elements, and placeholder content rather than finished copy or imagery. Common mistake: Spending hours perfecting colors and fonts at the wireframe stage, which the rubric isn’t asking for yet. How to check your work: Ask whether someone unfamiliar with your project could describe your site’s structure just from the wireframe.

Guerrilla testing and feedback requirement

What it means: You need to show that real people interacted with your design and that you captured what they said. What you need to produce: Documentation of who you tested with, what you asked them to do, and what they said or did. Evidence you should have: Specific quotes or observations, not a vague summary like “testers liked it.” Common mistake: Testing too late to make changes, or documenting feedback without analyzing it. How to check your work: Confirm every piece of feedback you documented is labeled as either actionable or non-actionable, with a reason given.

Prototype requirement

What it means: You need an interactive version of your design that a reviewer can click through. What you need to produce: A working prototype link with functioning navigation between screens. Evidence you should have: A prototype that reflects at least some of the changes your testing feedback pointed to. Common mistake: A prototype link that requires special access, or one where key buttons don’t actually navigate anywhere. How to check your work: Open the link in a private browser window to confirm it works without your own login session.

Usability tasks requirement

What it means: You need to give future testers specific, observable goals rather than vague opinions to gather. What you need to produce: Five usability tasks written as user goals, not yes/no questions. Evidence you should have: Tasks that map to real actions a user of your persona type would actually try to do on the site. Common mistake: Tasks phrased as opinion questions (“Do you like the layout?”) instead of action goals. How to check your work: Read each task aloud; if it can’t be completed by clicking through your prototype, rewrite it.

For anything not covered here, especially exact page counts, file formats, or specific rubric language, check your current D479 Task 1 instructions for the exact requirement.

D479 Timeline

The d479 timeline is your project plan, not a narrative summary. It exists to show you approached the work as a structured UX process rather than a single all-nighter, and it gives you a built-in checklist for what still needs to happen before submission.

A typical D479 timeline moves through roughly this sequence: research and persona development, wireframe creation, guerrilla testing, feedback analysis, prototype development, and a final review before submission.

Illustrative example only. Use your own project information and current WGU requirements.

User Persona

A UX persona is a semi-fictional profile representing your target user, built from whatever research materials the assignment provides (survey data, background documents, or similar). It typically includes demographics, goals, behaviors, needs, and pain points.

The persona matters because it gives your design decisions a defined user to serve. Without one, “make it easy to use” has no real meaning, since easy to use for whom, doing what, is exactly the question a persona answers. With one, you can trace a straight line: Research → Persona → User Needs → Design Decisions. If your persona is a first-time visitor overwhelmed by unfamiliar options, that should visibly shape things like simplified navigation labels or a more guided homepage layout.

Low-Fidelity Wireframe

A low-fidelity wireframe is a simple, mostly gray-scale sketch of a page’s structure: boxes for content blocks, lines for navigation, placeholder text instead of real copy. It communicates layout, hierarchy, and navigation without any of the visual design decisions (colors, imagery, typography) that come later.

A wireframe is not a mockup and not a finished design. If you’re spending significant time choosing a color palette or sourcing final images before you’ve validated your structure with testers, you’re working ahead of where the wireframe stage is meant to take you. Structure first, polish later, tested along the way.

D479 Wireframe vs. Prototype

Confusing these two deliverables is one of the more common sources of lost time on this task, so it’s worth being precise about the difference.

A wireframe shows what’s on each page and roughly where. A prototype shows what happens when someone clicks something. If you submit a beautifully designed but non-clickable image as your “prototype,” or a fully polished visual design labeled as your “wireframe,” you’ve swapped the two, and that mismatch is a common source of confusion during review.

D479 Figma Guide: How to Build Your Wireframe and Prototype

D479 Figma work is common because Figma is a widely used, free-to-start design and prototyping tool with strong support for exactly the wireframe-to-prototype workflow this task asks for. That said, Figma is not necessarily a required tool; other wireframing and prototyping software can work just as well. Check your current course instructions for whether a specific tool is mandated.

How to Create a D479 Wireframe in Figma

1. Create a new project file and set up frames sized for your target device (desktop, mobile, or both).
2. Define one frame per page or screen your site needs.
3. Establish your primary navigation pattern (header menu, sidebar, or similar) and repeat it consistently across frames.
4. Add layout placeholders, boxes and lines standing in for content blocks, not finished visuals.
5. Add headings and labeled content areas so each section’s purpose is clear at a glance.
6. Connect your page hierarchy mentally (which pages link to which) before you touch the Prototype tab.
7. Review the wireframe against your persona’s needs; confirm the layout actually serves the goals you wrote down earlier.
8. Prepare for guerrilla testing by making sure navigation elements are visually obvious, since low-fidelity testers need to recognize a button as a button.

How to Turn the Wireframe Into a D479 Prototype

Once your wireframe holds up under testing, the d479 prototype phase is about making it clickable. In Figma, this means using the Prototype tab to connect hotspots (buttons, links, icons) to destination frames, so a reviewer can navigate your design the way a real user would move through the finished site.

The general flow looks like this: Wireframe → Test → Feedback → Design Changes → Prototype. Build interactive connections for your primary user flows, the paths a persona-driven user would actually take, and confirm navigation moves both forward and back where appropriate. Before calling the prototype done, incorporate whatever actionable feedback came out of your guerrilla testing round, since a prototype that ignores its own testing results tends to raise questions during review.

For step-by-step mechanics of building connections and flows, Figma’s own guide to prototyping walks through hotspots, connections, and flows in detail.

D479 Guerrilla Usability Testing

Guerrilla testing is informal, low-cost usability testing done with whoever’s available (classmates, coworkers, family members) rather than a formally recruited, paid participant panel. The term comes from what usability researcher Jakob Nielsen described as “discount usability engineering,” the idea that even a small amount of real user testing, done cheaply and quickly, beats no testing at all.

The goal isn’t statistical certainty; it’s catching obvious structural or navigation problems before you invest more time building them deeper into your design. You’re trying to learn things like: can someone find what they’re looking for, do they understand what a button does before clicking it, and where do they hesitate or get stuck.

Document feedback as it happens rather than reconstructing it afterward from memory. Note what you asked the tester to do, what they actually did, and anything they said out loud. Testing should happen early enough (against the wireframe or an early prototype) that you still have time to act on what you learn, not the night before the deadline.

If you’re citing a specific minimum number of testers, verify that number in your current D479 Task 1 instructions rather than assuming a figure from an old guide or forum post; requirements can shift between course versions.

D479 Actionable vs. Non-Actionable Feedback

Not all feedback deserves a design change. Part of the skill this task is testing is your ability to tell the difference and explain your reasoning.

Fictional example feedback for illustration only.

The pattern worth internalizing: actionable feedback points to something a user couldn’t do, understand, or find. Non-actionable feedback is usually a taste preference or an unrelated comment. Always explain why you sorted a piece of feedback the way you did; a bare “actionable” or “not actionable” label with no reasoning is a common weak spot.

D479 Prototype: How to Build an Effective Interactive Prototype

Your d479 prototype needs to demonstrate that a real user, following your persona’s goals, could actually complete a task on your site. That means functioning navigation between the pages you wireframed, clickable interactions on the elements that should be clickable, and content that reflects the structure you tested earlier.

Where testing feedback pointed to a real problem, the prototype should show the fix, not just describe it in a caption. A reviewer clicking through your prototype should be able to see the improvement, not have to take your word for it.

D479 Prototype Quality Check

• Navigation works between every page you’ve included
• Important interactions (buttons, menus, forms) respond as expected
• Pages connect logically, matching the hierarchy from your wireframe
• Design reflects the needs identified in your persona
• Appropriate testing feedback has been addressed, and you can point to where
• Prototype link works when opened in a fresh browser session, without your own login

D479 Task 1 Example: Complete UX Design Walkthrough

Everything in this section is a fictional, illustrative example built to demonstrate the process. It is not a real WGU submission, it does not guarantee a passing score, and you should not copy it. Use your own project information, your own research, and your current WGU rubric.

Example Project Overview

Imagine you’ve been asked to redesign the website for a small island tourism board (a scenario similar in spirit to the kind of fictional client-based project this course tends to use). The existing site is described as outdated, with confusing navigation and all its information crammed onto a single page.

Example D479 Timeline

Following the illustrative timeline table above: research and persona work in week one, wireframe and navigation mapping through week two, guerrilla testing and feedback analysis mid-project, prototype build in week three, and usability tasks plus final review in week four.

Example User Persona

Illustrative example only. “Mara, 34, is planning a first-time family trip and has about twenty minutes in the evening, after her kids are asleep, to research destinations. She wants to quickly compare lodging options and see whether activities are kid-friendly. Her main pain point with typical travel sites is having to click through too many pages before finding basic pricing information.”

Example Low-Fidelity Wireframe

Illustrative example only. A homepage wireframe with a top navigation bar (Home, Stay, Explore, Plan Your Trip, Contact), a hero section with a search field, and three content blocks below it for featured lodging, activities, and travel tips. A separate “Stay” page wireframe shows a filterable list layout with placeholder listing cards.

Example Navigation Hierarchy

Illustrative example only.

Home → Stay → Listing Detail Home → Explore → Activity Detail Home → Plan Your Trip → Booking Form

Example Guerrilla Testing

Illustrative example only, with fictional testers. Three informal testers, a coworker, a neighbor, and a sibling, were each asked to locate lodging pricing information starting from the homepage. Two of the three testers scrolled past the search field, assuming it was decorative, before finding the “Stay” link in the navigation.

Example Feedback Analysis

Illustrative example only. “The search field looks decorative, not functional” was logged as actionable, since it directly affected whether testers could complete the task. “The homepage background color felt a little plain” was logged as non-actionable, since it reflected a stylistic opinion rather than a usability barrier.

Example Prototype Changes

Illustrative example only. Based on the actionable feedback, the search field was given a visible border and a labeled button (“Search Stays”) rather than sitting as an unlabeled bar, making its function clearer at a glance.

Example Five Usability Tasks

Illustrative examples only.

1. Locate the pricing information for a family-friendly lodging option.
2. Find an activity suitable for young children.
3. Start the booking process for a three-night stay.
4. Locate a way to contact the tourism board directly.
5. Compare two lodging options using the filter tools on the Stay page.

How to Create Strong D479 Usability Tasks

A strong usability task is objective, specific, observable, connected to your actual prototype, and framed around a realistic user goal rather than an opinion.

Weak: “Is the website easy to use?”

Stronger: “Locate the transportation information you would use to plan your trip.”

The weak version asks for an opinion, which doesn’t tell you anything about whether the design actually works. The stronger version gives a tester a real goal and lets you observe, directly, whether they can achieve it, how long it takes, and where they get stuck. That observable behavior is what usability testing is actually for.

D479 Task 1 Review: Pre-Submission Quality Check

Before submitting, run your own D479 task 1 review using a simple framework:

1. Requirement. Is every rubric item present somewhere in your submission?
2. Evidence. Does your submission actually demonstrate the requirement, not just mention it?
3. Explanation. Have you explained your reasoning, especially for persona-to-design connections and actionable-versus-non-actionable feedback calls?
4. Consistency. Does your persona connect to your wireframe? Does your wireframe connect to your prototype? Does your prototype reflect the feedback you documented?
5. Functionality. Does the prototype link actually work when someone else clicks it?
6. Formatting. Are all required files, documents, and links included in the format your instructions specify?
7. Rubric. Have you checked every single criterion against your current rubric, one at a time, rather than skimming?

Common D479 Task 1 Revision Reasons

These reflect patterns commonly discussed by students and reviewers, not a confirmed, official list of evaluator criteria. Verify specifics against your own returned feedback if you’ve already submitted.

• Persona does not reflect research. Why it matters: an ungrounded persona weakens every design decision that follows from it. Fix: pull specific details from your research materials into the persona document, not generic assumptions.
• Timeline is incomplete. Why it matters: missing phases suggest the project wasn’t actually planned in sequence. Fix: cross-check every activity mentioned elsewhere in your submission against your timeline.
• Wireframe is too vague. Why it matters: reviewers can’t assess structure they can’t see clearly. Fix: label sections and navigation elements explicitly.
• Wireframe and prototype do not match. Why it matters: it suggests the process wasn’t iterative. Fix: confirm the same pages and navigation structure appear in both.
• Navigation is incomplete. Why it matters: broken or missing links prevent a reviewer from evaluating the full experience. Fix: click through every link yourself before submitting.
• Guerrilla testing is poorly documented. Why it matters: without specifics, there’s no evidence testing actually happened. Fix: record direct quotes or observed actions, not summaries.
• Feedback is listed but not analyzed. Why it matters: the rubric wants judgment, not a transcript. Fix: label each item actionable or non-actionable with a stated reason.
• Actionable feedback does not lead to a design change. Why it matters: it breaks the connection between testing and iteration the whole task is built around. Fix: point explicitly to where the prototype reflects the change.
• Prototype is not interactive enough. Why it matters: a static image doesn’t demonstrate the interaction the rubric is testing for. Fix: add functioning connections for every primary navigation path.
• Prototype link does not work. Why it matters: reviewers can’t evaluate what they can’t open. Fix: test the link in a private or incognito window before submitting.
• Usability tasks are too general. Why it matters: vague tasks don’t produce observable, useful results. Fix: rewrite each task as a specific, completable action.
• Student overcomplicates the project. Why it matters: an overly ambitious scope eats time better spent on depth. Fix: keep the site small enough that every page can be wireframed, tested, and prototyped thoroughly.
• Missing or incorrect citations. Why it matters: outside images and sources need proper attribution. Fix: keep a running citation list as you build, rather than reconstructing it at the end.

D479 Task 1 vs. D479 Task 2

Task 1 is where you build and validate the design itself. D479 task 2 shifts into more formal usability evaluation of what you built, based on your current course instructions. This guide focuses on Task 1; read the complete D479 Task 2 guide for a full walkthrough of what comes next.

How to Complete D479 Task 1 Efficiently as a Working Student

1. Phase 1. Read the full instructions and rubric before creating anything, so you know exactly what you’re building toward.
2. Phase 2. Extract research findings from your provided materials and draft your persona.
3. Phase 3. Build your timeline and low-fidelity wireframe.
4. Phase 4. Conduct guerrilla testing against the wireframe or an early prototype.
5. Phase 5. Analyze feedback and sort it into actionable and non-actionable categories.
6. Phase 6. Build your interactive prototype, incorporating actionable changes.
7. Phase 7. Write your five usability tasks.
8. Final phase. Complete your own D479 Task 1 review before submitting.

Every student’s pace differs based on prior design experience, so there’s no universal number of hours or days this should take. Working the phases in order, rather than jumping between them, is what tends to save the most time.

D479 Task 1 Checklist

• Current instructions reviewed
• Rubric reviewed
• Timeline completed
• Persona completed
• Research incorporated
• Wireframe created
• Navigation mapped
• Guerrilla testing completed
• Feedback documented
• Actionable feedback identified
• Non-actionable feedback identified
• Design changes explained
• Prototype created
• Prototype tested
• Usability tasks created
• Citations checked
• Prototype link tested
• Final D479 Task 1 review completed
• Submission checked against current rubric

Need Help With D479 Task 1?

If you’ve worked through this guide and still have questions about a specific requirement, that’s normal. UX design has a lot of moving, interconnected parts, and it’s common to want a second set of eyes before you submit.

Legitimate educational support for this task usually looks like: help understanding what a specific rubric criterion means, a review of your own wireframe or prototype navigation, help interpreting Figma’s prototyping features, or feedback on whether your usability tasks are specific enough to be useful. That kind of guidance can help you catch gaps before submission, without doing the work for you.

No legitimate service can guarantee a pass, guarantee no revisions, complete your assessment for you, or access WGU systems on your behalf, and it’s worth being skeptical of anyone who claims otherwise.

D479 Task 1 FAQs

• What is D479 Task 1? It’s the first performance assessment in WGU’s User Experience Design (D479) course, requiring a timeline, persona, low-fidelity wireframe, guerrilla usability testing, feedback analysis, interactive prototype, and five usability tasks.
• What is WGU D479 Task 1? The same assessment described above; WGU is the university, D479 is the course, and Task 1 is the first of its two performance assessments.
• What does D479 Task 1 require? Broadly: a project timeline, a research-based user persona, a low-fidelity wireframe, documented guerrilla testing, an analysis of actionable versus non-actionable feedback, an interactive prototype, and five usability tasks. Confirm exact requirements against your current course instructions.
• Is D479 Task 1 difficult? It’s less about difficulty and more about scope. Students without prior design experience often find the number of connected deliverables the biggest challenge, not any single piece of it.
• How long does D479 Task 1 take? This varies significantly by student and prior design familiarity, so there’s no reliable universal estimate. Working through the phases in sequence, rather than all at once, tends to help.
• Does D479 Task 1 require Figma? Figma is a commonly used, free tool for this kind of work, but check your current course instructions for whether a specific tool is mandated.
• What is a D479 low-fidelity wireframe? A simple, mostly gray-scale sketch of a page’s layout and navigation, using placeholder content rather than finished visuals or copy.
• What is a D479 prototype? An interactive version of your wireframe with functioning navigation, built to demonstrate that a user could complete real tasks on your design.
• What is the D479 timeline? A structured plan showing the phases of your UX process (research, persona, wireframe, testing, prototype, review) with timeframes attached to each.
• What is guerrilla testing in D479? Informal usability testing conducted with easily available participants rather than a formally recruited panel, meant to catch obvious usability problems quickly and cheaply.
• How should I analyze actionable feedback? Sort each piece of feedback into actionable (points to a real, fixable usability problem) or non-actionable (a taste preference or unrelated comment), and explain your reasoning for each classification.
• How many usability tasks are required? Five, based on how this assessment has been structured. Verify the exact number in your current D479 Task 1 instructions.
• What causes D479 Task 1 revisions? Commonly discussed patterns include vague wireframes, undocumented or unanalyzed testing feedback, prototypes that don’t reflect that feedback, non-functioning prototype links, and overly general usability tasks. See the dedicated section above for a fuller breakdown.
• What is the difference between D479 Task 1 and D479 Task 2? Task 1 focuses on building and validating the UX design itself. Task 2 shifts into more formal usability testing and evaluation of the completed prototype, per your current course instructions.
• Can I use a D479 Task 1 example? Examples, including the illustrative one in this guide, are useful for understanding structure and depth expectations. They should inform how you organize your own work, not be copied or submitted as your own.

Other WGU Guides and Examples

• WGU C207 Task 1: Complete Guide + Worked Example (Linear Regression Analysis)
• WGU C207 Task 2 Guide: Decision Tree Analysis + Example (2026 Edition)
• WGU D473 Guide: Solutions Design and Visualization Capstone
• WGU C216 Task 1 Guide & Example: Complete Investor Presentation Walkthrough
• WGU C219 Task 1 (Investor Presentation): What a Perfect Score Actually Requires

References

• Nielsen, J. Usability Testing 101, Nielsen Norman Group. Foundational explanation of usability testing methodology, participant selection, and the think-aloud method referenced in the guerrilla testing section above.
• Nielsen, J. Guerrilla HCI: Using Discount Usability Engineering to Penetrate the Intimidation Barrier, Nielsen Norman Group. The original source for the “guerrilla” usability testing terminology used throughout this guide.
• Guide to Prototyping in Figma, Figma Help Center. Official documentation for hotspots, connections, and flows referenced in the Figma section above.
• Connect Your Prototype, Figma Help Center. Official documentation on building interactive connections between frames.
• r/WGU (Reddit). Community discussion of student experiences with D479; useful for gauging common sticking points, but represents student opinion and experience, not official WGU policy or rubric language.