Usability testing for beginners: how to test your design

Step 1

Decide what exactly you're testing

As Nielsen Norman Group defines it, in a usability test a facilitator gives a participant tasks and watches how they complete them, while the participant comments on what they do. So start with the goal, not the participants: which scenario in your design matters most and where you're least sure. For a study project, pick 2–3 key scenarios: sign-up, finding a product, placing an order.

• •write down what counts as success: the person got to the end alone, without hints;
• •check that the prototype covers these scenarios end to end and doesn't break halfway;
• •you can test even a paper sketch or a clickable Figma prototype: you don't need a finished product.

💡 Test as early as you can. Fixing a screen in a prototype is far cheaper than after development.

Step 2

Find participants

Participants should be similar to your real users in experience, needs or situation. If the design is for people renting a home, invite those who recently looked for a flat. How many people do you need? In a 2000 article, Jakob Nielsen recommends running several small qualitative tests with about five participants each, fixing what you find and testing again, rather than spending everything on one big test. A later NN/g article clarifies that this rule applies to qualitative tests, and quantitative studies need more people.

• •don't invite fellow designers or anyone who has seen the mockup: they know the "right" way;
• •if your users are very different (say, buyers and sellers), test each group separately;
• •agree on the format: in person or an online call with screen sharing.

Step 3

Write the tasks and the session script

A task is a realistic situation with a goal, not an instruction. NN/g advises writing tasks that prompt action and don't reveal how to use the interface. The GOV.UK Service Manual adds that a good task has a clear goal, is believable to the participant and doesn't give away "the answer".

• •weak: "Tap 'Cart' and place the order" — you've already named the button;
• •better: "You want to order pizza tonight for three friends, with a budget of up to 600 hryvnias. Place the order";
• •prepare an introduction: who you are, that you're testing the design, not the person, and that they can't get it wrong;
• •plan a few questions for the end: what was hardest, what surprised them.

💡 Run the script yourself and with one other person before the first real session. An unclear wording is better found in rehearsal.

Step 4

Run the session and don't help

Ask the participant to think aloud: to say what they see, what they're looking for and what they expect. NN/g calls thinking aloud one of the simplest and most useful methods in UX. Your job is to observe, not to rescue. If the person gets stuck, don't show them where to tap: ask "What are you looking for right now?" or "What did you expect?". Ask permission to record the screen and voice, and if you can, invite someone to take notes.

• •according to GOV.UK, a session usually takes 30 to 60 minutes, depending on the number and complexity of tasks;
• •note where the person stops, goes back, makes a mistake or says "ah, there it is";
• •write down exact phrases: "I thought it was a link" says more than "it was unclear";
• •at the end, thank them and explain how you'll use the results.

Step 5

Collect the problems, fix them and test again

After all the sessions, list each problem separately: what happened, on which screen, for how many participants. Then rate severity: does the problem stop someone from finishing the task, or only slow them down? Fix the most serious first. Nielsen's key idea is iteration: after the fixes, run another small test to make sure they work and didn't create new problems.

• •keep observations ("three people didn't find the filter") separate from solutions ("move the filter up");
• •don't fix everything at once: start with what blocks the task;
• •for the case study, keep the "before" and "after" and participants' quotes;
• •be honest about limits: how many people, who they were, what you didn't test.

💡 Show your problem list and fixes in the community. Other designers will point out where a fix treats the symptom, not the cause.