Lesson 02D / UX Research
Prototyping And Usability Testing
Create lightweight prototypes, give people realistic tasks, observe what happens, and revise the interface based on evidence.
Course Role
Studio Support
Best during work sessions, critique, debugging, project planning, or final polish.
Teacher Notes / In-Class Use
Demo Live
- Run a quick test on a small prototype while students watch for hesitation, wrong clicks, and questions.
- Turn one observation into a specific design revision live.
Try In Class
- Have students test one task with one classmate using Figma or a rough browser prototype.
- Ask students to record three observations and choose two revisions.
Submit Or Check
- The task prompt should not tell the participant which UI control to use.
- Findings should describe observed behavior and lead to concrete revisions.
Watch For
- Students defending the design during the test instead of observing.
- Findings written as opinions without evidence from participant behavior.
Learning Goals
- Choose the right prototype fidelity for the question being tested.
- Write realistic usability tasks that do not lead the participant.
- Observe behavior, confusion, hesitation, and workarounds without defending the design.
- Turn findings into prioritized revisions for Figma or front-end work.
Prototype To Learn
A prototype is not valuable because it looks impressive. It is valuable because it lets you learn something before the final version is built.
For this course, prototypes can be paper sketches, Figma click-throughs, rough HTML pages, or small JavaScript interactions. The right prototype is the fastest one that can answer the current design question.
Prototype Fidelity
| Prototype Type | Best For | Risk |
|---|---|---|
| Paper or sketch | Early task flow, layout options, and conversation. | Hard to test detailed interaction or real content. |
| Low-fidelity Figma | Screen order, hierarchy, and navigation labels. | Participants may ask about unfinished visual details. |
| High-fidelity Figma | Visual direction, content, and clickable flows. | Polish can make weak structure seem more convincing. |
| HTML/CSS prototype | Responsive behavior, keyboard access, forms, and layout reality. | May take longer if the design question is still basic. |
| JavaScript prototype | Dynamic behavior, state changes, carousels, filters, and feedback. | Can distract from core usability if overbuilt too early. |
What To Test
- Can users identify what the page or screen is for?
- Can users find the primary action?
- Can users predict what will happen after clicking a control?
- Can users complete the task without verbal help?
- Can users recover from an error or empty state?
- Can users understand labels, navigation, and feedback messages?
- Does the interface still work on the device or viewport being tested?
Writing Better Tasks
A usability task should describe the participant goal, not the interface control. Do not tell them exactly what to click unless the test is about whether that control is visible.
| Leading Task | Better Task |
|---|---|
| Click the Apply button. | You found an event you want to attend. Show me how you would sign up. |
| Use the filter menu to find UX projects. | You want to see only UX projects. How would you narrow the list? |
| Open the contact page. | You want to ask the designer about freelance work. What would you do? |
| Submit this form. | You are ready to share your project for critique. Show me how you would send it. |
Moderator Script
Thanks for helping test this project. I am testing the design, not you.
Please think out loud as much as you can.
If something is confusing, say what you expected to happen.
I may stay quiet while you work so I do not accidentally guide you.
Task:
[Give one realistic task.]
Follow-up questions:
What felt clear?
Where did you hesitate?
What did you expect to happen next?
What would you change first? Observation Notes
| What To Note | Why It Matters |
|---|---|
| Hesitation | The next step may not be clear. |
| Wrong clicks | Labels, hierarchy, or affordances may be misleading. |
| Backtracking | The flow may need better wayfinding or content order. |
| Questions | The interface may not explain itself. |
| Workarounds | Users may be solving around the design instead of through it. |
| Success without confidence | The task may work but still feel uncertain. |
Turning Findings Into Revisions
A test is not finished when the participant leaves. The important work is turning observations into changes that improve the interface.
| Finding | Possible Revision |
|---|---|
| User missed the primary action | Improve hierarchy, placement, label, or contrast. |
| User clicked a card expecting details | Make the card link clear or add a visible detail link. |
| User did not understand a form error | Rewrite the error and connect it to the field. |
| User could not find filters | Move filters closer to the list or improve the label. |
| User was unsure if the action worked | Add loading, success, or confirmation feedback. |
Studio Activity: Five-Minute Test
- Choose one task from the current project.
- Create a prototype that is just realistic enough to test the task.
- Write one scenario and one task prompt.
- Test with one classmate while staying mostly quiet.
- Record three observations and one direct quote or paraphrased comment.
- Choose two revisions and make at least one before the next critique.
Submission Checklist
- The prototype matches the question being tested.
- The task describes a user goal instead of telling the participant what to click.
- Notes include observed behavior, not only opinions.
- Findings are prioritized by impact and effort.
- At least one revision is made based on the test.
- The final reflection explains what changed and why.
Checkpoint
Before moving on, make sure these feel true.
- I can choose an appropriate prototype fidelity for a design question.
- I can write usability tasks that describe user goals instead of giving instructions.
- I can observe a test, identify findings, and make revisions based on evidence.
Project Connection