E023 Product Design carries the banner number ITIM 6610 and is worth 3 competency units. The course puts you in the seat of the person who has to turn a business problem into a technical solution: designing that solution, creating a low fidelity prototype of it, and conducting limited user testing through feasibility and usability studies. E023 and ITIM 6610 name the same requirement. It sits between product strategy and product launch, and its particular demand is that you show your design decisions were tested rather than merely reasoned.
Low fidelity is a method, not a shortcut
Students often treat the low fidelity prototype as a lesser version of a real product, and produce something that looks polished because polish feels like effort. The method points the other way. A rough prototype is deliberately rough so that testers criticize the concept instead of the color scheme, and so that you are willing to throw it away when the testing says you should. A prototype that took forty hours will not be abandoned no matter what the users say, and that is exactly the failure the technique exists to prevent.
Feasibility and usability are two separate questions and the course keeps them separate. Feasibility asks whether the solution can be built and operated with the resources, skills, systems and constraints available. Usability asks whether the people it is for can accomplish their task with it. A design can be entirely feasible and unusable, or delightful and impossible to deliver, and a submission that answers only one of those questions has answered half the course.
The business problem stays visible throughout. Every design decision in this course should be traceable to something the organization needs, and the trace is what an evaluator is looking for. A feature that exists because it is interesting, with no line back to the problem, is the most common thing removed from a strong draft.
Limited testing means limited, and that is fine. A small number of participants, a defined task, an observation protocol and honest reporting of what happened produces real findings. What does not produce findings is asking testers whether they liked it, because people are polite and preference is not performance.
Work at WGU is judged Competent or Not Competent, there are no letter grades and no ordinary grade point average, and the 3 competency units here fall inside a six month term billed at a flat rate.
Turning scored aspects into a design and testing report
If your version of E023 is assessed by a performance assessment, the aspects your evaluator scores tell you what the report must contain and roughly in what proportion. WGU requires a score of 2 in every aspect for a task to pass, and aspects are judged independently, so a beautiful prototype narrative will not carry a thin feasibility aspect.
Set the budget before drafting. Suppose the rubric holds four scored aspects against a target near 1,600 words, a realistic length when a prototype and test artifacts carry part of the evidence. Reserve 120 words to restate the business problem and 100 for the close, leaving 1,380 words. The one aspect that asks you to present and justify the design itself takes 480 words, because it needs the decision, the alternative you rejected and the reason. The three remaining aspects, typically prototype description, test method with results, and the changes those results produced, take 300 each, which is 900. Adding 480 to 900 gives 1,380 exactly.
Where a prototype or test artifact carries information, reference it in the prose rather than describing it in full. Prose that narrates a diagram wastes words the aspects need elsewhere. Prose that says what the artifact shows and what decision it drove is doing the work.
Protect budget for the changes section. The aspect most often underwritten is the one asking what the testing changed, and it is the aspect that proves the method was real. Testing that produced no changes at all is a finding too, but it needs an explanation rather than a silence.
Shape for a design and usability report
E023 deliverables usually present a designed solution alongside evidence that it was tested. These proportions fit that report.
| Section | What belongs there | Share |
|---|---|---|
| Business problem | The problem in one paragraph, with what it costs the organization today. | 9 percent |
| Design decisions | The solution, the alternatives considered, and why each decision went the way it did. | 24 percent |
| Prototype | What was built, at what fidelity, and which parts were deliberately left unresolved. | 14 percent |
| Feasibility study | Technical, operational and resource feasibility, each assessed against a stated constraint. | 18 percent |
| Usability testing | Participants, tasks, protocol, and what was observed rather than what was said. | 17 percent |
| Findings and changes | What the testing revealed and exactly what changed in the design because of it. | 13 percent |
| Close | What remains untested and what the next round would examine. | 5 percent |
Reporting testing so it reads as real
The credibility of a design report rests almost entirely on how the testing is reported. Give the number of participants and how they relate to the intended users. Give the tasks you asked them to attempt, in the words you used. Give the protocol: whether you intervened, whether you timed anything, what you recorded. Those details are short and they are the difference between a study and a story.
Report observations before interpretations, and keep them typographically separate if you can. What a participant did is data. Why you think they did it is analysis. Merging the two makes it impossible for a reader to disagree with your reading while still accepting your evidence, which is precisely what a good report allows.
Include the failures. A participant who could not complete a task, a step that confused everyone, a feature nobody used: these are the findings with value, and reports that contain only successes read as marketing. Evaluators at graduate level know that real testing is unflattering.
For design principles, heuristics and method, cite the published sources your course materials point to rather than restating them from memory, and use the citation style your task specifies. Where you assert that a design choice follows a recognized principle, name the principle and cite it, because that is what turns a preference into a justification.
What earns Competent, and what comes back
Competent work shows a chain: problem, design decision, prototype, test, change. Each link is visible and each one refers to the one before it. It treats feasibility and usability as distinct questions with distinct evidence, and it reports at least one thing that went wrong.
Returns have recognizable causes. The prototype is described but never tested. Testing is described but the participants are hypothetical. Feasibility is asserted in a sentence with no constraint named against it. The design section presents one option as though no alternative existed. Or the report ends without saying what the testing changed, which leaves the evaluator unable to score the aspect that matters most.
Before submitting, try this: cover the design section and read only the testing and findings. If a reader could reconstruct roughly what you designed from the testing alone, the two halves are genuinely connected. If not, the testing was probably written to fit a design that was already final.
A performance assessment at WGU may be revised and resubmitted with no penalty to the grade, so hand it in as soon as each aspect carries a real answer. Where a section of this course also uses an objective assessment, that exam is proctored, and our boundary does not bend: preparation beforehand, with concept drills, method practice and a straight read of your preassessment result. We do not sit assessments, we play no role while one is in progress, and portal credentials are never requested from you or held by us.
Prototype finished, testing thin?
Send the E023 rubric and your design. We build the test protocol, the reporting structure and the findings section that proves the method was real.
Six mistakes that cost time in E023
- Over building the prototype. High fidelity attracts feedback about appearance and makes you defend a design you should be testing.
- Collapsing feasibility into usability. They ask different questions, need different evidence, and are usually scored separately.
- Asking testers for opinions. Give them a task and watch. Preference is easy to give and tells you almost nothing about performance.
- Presenting a single option. A design decision needs a rejected alternative behind it, otherwise no decision has been shown.
- Reporting only successes. A study where nothing went wrong reads as a study that did not happen.
- No change trail. Say exactly what the testing altered. Testing that changes nothing, with no explanation, undercuts the whole report.
Three questions students ask about E023
Do I need design software to build the prototype?
Who can I recruit for usability testing?
Is E023 the same course as ITIM 6610?
Where E023 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.