Usability Testing: How to Run Your First Test

TL;DR: What You Will Learn

• Usability testing means watching real users attempt real tasks, then fixing what trips them up.
• You can run a meaningful test with around five participants on almost any budget.
• Clear goals and neutral task scripts matter more than expensive equipment.
• Moderating well means shutting up, observing, and resisting the urge to help.
• Findings are only valuable if you prioritise them and act on them.

Let us get you running your first test.

What Usability Testing Really Means

At its core, usability testing is simple: you watch real people try to complete real tasks using your product, then note exactly where they hesitate, get confused, or give up.

That is it. No focus groups debating opinions, no guessing. Just observation of behaviour as it happens.

Picture a local fashion SME selling on Shopee. Their analytics show a high cart abandonment rate, but the numbers stop there. They know people are leaving. They do not know why.

Usability testing fills that gap. You sit five shoppers down, ask them to buy a dress, and watch. Maybe the promo code field is buried, or the shipping cost only appears at the final step and spooks them. Now you have a fix, not a mystery.

Usability Testing vs Other Research Methods

The trap most Singapore teams fall into is assuming their existing data already answers the “why”. It rarely does.

Analytics, A/B tests, and surveys are powerful, but they measure different things. Analytics tells you a page has a 70 percent drop-off. A/B testing tells you which of two designs performs better. Surveys tell you what people say they think, which is often different from what they actually do.

Usability testing is the only one that shows you the moment of friction in real time. It answers the “why” the others cannot.

If you are still fuzzy on where usability sits within design work, it helps to understand the difference between UI and UX first, because usability testing evaluates the whole experience, not just how a screen looks.

This is not a niche practice, either. Even PDPA-compliant government service portals here are usability tested before wider rollout, precisely because a confusing form on a public service costs everyone time.

Moderated vs Unmoderated Tests

There are two main flavours, and you will choose between them constantly.

In a moderated test, you are present, either in the same room or on a video call, asking the participant to think aloud and probing when something interesting happens. It is richer but slower.

In an unmoderated test, participants complete tasks on their own using a tool that records their screen and voice. It is faster and cheaper to scale, but you cannot ask follow-up questions.

For your first test, I always recommend a moderated test. Being in the room teaches you to spot friction in a way no recording replays quite match.

What Good Looks Like: The Five-User Rule

Here is the reassuring part. You do not need dozens of participants to get useful results.

Usability expert Jakob Nielsen of the Nielsen Norman Group established this guideline, arguing that testing with around five users per round surfaces roughly 85 percent of a design’s usability problems. Beyond that, you start seeing the same issues repeat.

This isn’t a rule of thumb pulled from thin air. Nielsen and Tom Landauer derived it from a mathematical model built on data from dozens of real usability studies, based on the observation that each additional user is increasingly likely to repeat a problem someone before them already hit. It’s worth knowing this is a guideline for qualitative, problem-spotting tests, not for quantitative studies measuring exact completion rates, which need larger samples.

Nielsen himself has since pushed back on how flatly people quote his own guideline. In a 2000 exchange in Interactions magazine, he clarified that his real recommendation was 3 to 4 users per round; the extra buffer up to five was there mainly to cover no-shows, not because five is some magic threshold. That nuance matters: the number isn’t sacred; the iterate-and-retest habit is.

So five thoughtful sessions, done properly, beat a huge survey nobody acts on. That is the whole promise of usability testing, and the rest of this guide shows you how to run one.

Why Usability Testing Is Worth Your Time and Budget

Let me be blunt about something I see all the time: teams pour money into a shiny new website, launch it, then quietly panic when the conversions never arrive.

Usability testing is the cheapest insurance you can buy against that outcome, and it costs a fraction of what a redesign does.

The Real Cost of Skipping It

Imagine a Singapore SME, say a mid-sized homeware retailer, that secures an Enterprise Singapore Productivity Solutions Grant (PSG) to fund a website revamp.

The grant covers a big slice of the build, which is a genuine win. But a grant funds the build, not the outcome, and a broken checkout flow will still bleed sales the day you go live.

Here is the part most people underestimate: catching a usability problem before launch is generally far cheaper than fixing it afterward. This echoes long-standing findings in software engineering economics, often traced to IBM’s Systems Sciences Institute research and echoed by voices like Barry Boehm, showing that the cost of correcting a defect climbs sharply the later it’s discovered in a project.

These figures trace back to studies of software defect costs from the 1970s and 80s, along with Boehm’s own later work; the specific multipliers cited (sometimes 10x, 100x, or more between design and post-release) vary widely by study and have been challenged by some researchers as outdated for modern, iterative development. The exact multiplier is debated, but the direction isn’t.

A change caught on a wireframe is a redraw. A change caught after launch means developer time, re-testing, another QA pass, and possibly rebuilding a flow customers have already learned to dislike.

Meanwhile, you are still paying for ads that send traffic into a funnel that leaks. Every dollar of that ad spend on a confusing product page is money you are actively wasting.

Small Test, Protected Investment

A short usability test, even five people watching real users try to complete one task, protects that entire PSG investment before it hardens into code.

I have watched a single test session surface a problem that would have quietly killed a form completion rate for months. Nobody on the team had noticed because they built it, so they already knew where to click.

The payoff shows up in two places that lean local teams feel immediately:

• Higher conversion rates, because people can actually find and buy what you sell.
• Lower support load, because customers stop emailing to ask how the site works.

For a small team where one person handles support, marketing, and operations, cutting the “how do I check out” emails is a real relief, not a nice-to-have.

A Skill That Compounds

There is a career angle here too, which ties back to why I encourage practitioners to learn this properly.

Running your own tests is the entry point into serious UX work, and demand for people who can do it well is reflected in the UX designer salary figures in Singapore.

So do not let budget be your excuse. A basic test needs a laptop, a few willing participants, and a couple of hours, and the return on catching one broken flow makes the maths absurdly in your favour.

Planning Your First Usability Test

Every good test starts long before you sit a participant down. Usability testing succeeds or fails on the planning you do upfront, and skipping this step is the most common mistake I see beginners make.

Let me walk you through the planning I do before any session, using a running example: a local F&B startup rolling out QR-code ordering across its outlets. Before they commit to that rollout, they want to know if customers can actually order without a staff member hovering nearby.

Defining Your Research Question

Start with one question: what decision will this test inform? If you cannot name the decision, you are not ready to test yet.

For our F&B startup, the decision is clear. Do we launch this QR-code ordering flow across all outlets, or do we fix it first? That framing keeps the test focused on real usability problems, not vague opinions about colours or logos.

Write your objective as a single sentence. Something like: “We want to find out whether first-time diners can scan, browse the menu, and complete an order in under two minutes without help.”

That sentence becomes your north star. Every task you design, and every question you ask, should ladder up to it.

Picking What to Test: Prototype, Live Site, or Competitor

Next, decide what participants will actually interact with. You have three common options, and the right one depends on how far along your product is.

• A prototype works when you are still designing and want to catch problems cheaply. If you are building screens in Figma, brushing up on Figma design basics every beginner should master will help you make a clickable flow that feels real enough to test.
• A live site or app works when the product already exists, and you want to find friction in the real thing.
• A competitor’s product works when you want to learn from something people already use, before you build your own version.

For the QR-code flow, I would test a clickable prototype first. It is far cheaper to change a Figma screen than to reprint table stickers across ten outlets.

Choosing Your Method And Setting

Now decide moderated or unmoderated. Moderated means you or a facilitator guides the session live, in person or over a call, and can ask “why did you do that?” in the moment. Unmoderated means participants complete tasks on their own using a tool that records their screen.

For a first test, I usually recommend moderated. You will learn more from watching someone hesitate over the menu than from a bare completion metric, and you can probe confusion as it happens.

Keep your setting simple. A quiet room, a laptop or phone with the prototype, and a way to record the screen is enough to begin.

Finally, write a short test plan, so everyone agrees on scope before you start. One page is plenty, and it stops stakeholders from expecting the test to answer questions it was never designed for.

One more thing to note in your plan: collect only the personal data you genuinely need. Recording someone’s screen and first name is usually enough, and keeping data collection minimal keeps you PDPA-friendly from the very first test.

Recruiting the Right Participants

The single biggest mistake I see first-timers make is grabbing whoever is sitting next to them. Your colleague knows your product too well, and their feedback will quietly mislead you.

For usability testing, the people you recruit matter far more than the number of them.

How Many Users You Really Need

For qualitative testing, the answer is reassuringly small. Nielsen’s five-user rule holds that five participants will surface the majority of usability problems in a given design.

The reason is that early users trip over the same big issues, so a sixth or seventh person mostly repeats what you have already learned. Five well-matched users beat twenty random ones every time.

If you have distinct user groups, say first-time buyers and repeat customers, run five from each rather than lumping them together.

Finding People Who Match Your Real Audience

Your goal is to recruit people who behave like your actual users, not people who are simply easy to reach. If you are testing a heartland optical shop’s online booking flow, you want residents who genuinely shop in that neighbourhood, not fellow designers.

A short screener survey does the heavy lifting here. Ask a few behavioural questions such as how often someone books appointments online, or whether they have bought from a similar business in the last three months, then invite only those who fit.

In Singapore, a few low-cost channels work well for a first test:

• Community Facebook groups tied to a specific estate like Tampines or Bishan
• A heartland retailer’s loyalty or mailing list, with the owner’s blessing
• Guerrilla testing at a café or a co-working spot such as one of the buildings at JTC LaunchPad @ one-north

When you collect names, emails, or phone numbers, PDPA applies. Tell participants clearly what you will use their details for, how long you will keep them, and get their explicit consent before storing anything.

Incentives and Avoiding Skewed Samples

Offer a fair thank-you for people’s time. A small NTUC or GrabFood voucher, or a token cash amount, signals respect and lifts your show-up rate, even for informal sessions.

Friends-of-friends are a legitimate budget option when you have limited reach, as long as they genuinely match your audience and do not already know your product.

The trap to avoid is the convenience sample: recruiting only tech-savvy friends, only your own age group, or only people who already love your brand. That skews your results toward users who never struggle, hiding the very problems the test exists to find.

Start small, screen honestly, and you will get sharper insight from five strangers than from a room full of familiar faces.

Writing Tasks and a Test Script

Once you know what you want to learn, the next job is turning those objectives into tasks people can actually attempt. This is where most first-time usability testing goes wrong: the tasks accidentally tell participants what to do, so you end up testing your instructions rather than your design.

Writing Task Scenarios That Avoid Leading Users

The fix is scenario-based tasks. Instead of giving a step, you give a situation and let the person figure out the path.

Imagine you are testing a SkillsFuture course-booking page where users need to find a class and enrol. A leading task sounds like this: “Click the Courses menu, filter by date, and select the Tuesday intake.”

That reveals the answer. A good scenario task sounds like this instead: “You want to book a data analytics class that starts next Tuesday. Please go ahead and do that.”

Notice the difference. The second version uses the words a real user would use, not the labels from your interface. If your button says “Enrol” but your task says “Sign up”, you will still learn whether people connect the two.

A few rules I keep in mind when writing scenarios:

• Use the participant’s language, not your UI labels or feature names.
• Give a realistic goal and a reason, not a sequence of clicks.
• Keep each task to one clear outcome you can observe.
• Order tasks roughly from simple to more complex.

Structuring Your Moderator Script

A script keeps every session consistent so you can compare what different people did. It also stops you from ad-libbing hints when someone struggles.

Start with a short warm-up to settle nerves: “There are no wrong answers here. We are testing the design, not you.” Then ask a couple of easy background questions, such as whether they have booked a course online before.

Introduce the think-aloud method early: “As you go, please say out loud what you are thinking, what you expect, and what confuses you.” When someone goes quiet, prompt gently with neutral lines like “What are you looking at now?” or “What did you expect to happen there?”

The golden rule is to stay neutral. If they ask “Is this right?”, bounce it back with “What do you think?” rather than confirming.

Here is a mini task block you can copy and adapt:

• Warm-up: “Have you booked any training course online before?”
• Task: “You want to enrol in a Tuesday data analytics class using your SkillsFuture credit. Please find one and book it.”
• Follow-up: “How easy or hard was that? What, if anything, tripped you up?”

If you are still building the prototype you will test, a step-by-step Figma tutorial for beginners is a helpful starting point, since a step-by-step Figma tutorial for beginners walks through the basics.

Setting Success Criteria and Metrics

Before you run anyone, decide what “success” means for each task. Otherwise, you will argue about it afterwards.

For the booking task, success might be: the participant reaches the confirmation screen without help. I usually track task completion, whether they needed a nudge, and rough time on task.

Keep it simple. A pass or fail plus a one-line note on where they hesitated is enough for your first test.

Running the Session Without Bias

The first time I moderated a usability testing session, I made every mistake in the book. I explained too much, jumped in the moment the participant paused, and basically answered my own research questions for them.

Here is the truth that took me a while to accept: your job during the session is to shut up and watch. The quieter you are, the better your data.

The Moderator Mindset and Neutral Language

Start by putting the participant at ease. Remind them that you are testing the product, not them, and that there are no wrong answers. That single sentence relaxes people more than you would expect.

Then encourage thinking aloud. Ask them to narrate what they are looking at, what they expect to happen, and where they feel stuck. A simple prompt works: “Tell me what is going through your mind right now.”

When they struggle, stay silent. This is the hardest part. Watching someone hunt for a button you know is right there is uncomfortable, but every second of that struggle is exactly what you came to learn.

Never rescue and never lead. Avoid questions like “Wouldn’t you click the blue button?” Instead, ask “What would you do next?” and let the silence do its work.

Neutral language and comfortable silence are the two habits that separate useful sessions from wasted ones.

Handling Remote vs In-Person Sessions

Most of my tests these days run remotely over Zoom, and it works well for Singapore teams testing users beyond their own neighbourhood.

Picture a fintech startup testing its onboarding flow. Your participant is at home in Woodlands while you moderate from your office in the CBD. You ask them to share their screen, and you watch their cursor hesitate over the SingPass login step in real time.

Before you start recording, get explicit consent. Under the PDPA, you need the participant to agree to being recorded and to how you will use that recording, so build a short consent line into your intro script and wait for a clear yes.

For in-person sessions, sit slightly to the side rather than directly opposite the person. It feels less like an interrogation, and you can see their screen without hovering.

Recording and Note-Taking Roles

Do not try to moderate and take detailed notes at the same time. Splitting your attention means you will miss the subtle facial expression or the muttered “this is weird” that reveals the real problem.

Bring a dedicated notetaker if you can. Their only job is to capture observations against a simple template, one row per task, noting where the participant hesitated, what they said, and whether they completed it.

If you are solo, lean on your recording and keep only light notes during the session, then review the footage afterwards. Your energy in the moment should go towards listening, not scribbling.

Turning Findings Into Fixes

You have run your first test, and your notes are a mess of scribbles, screen recordings, and half-remembered moments where someone frowned at your screen. This is where usability testing either pays off or quietly dies in a folder no one opens again.

The job now is to turn raw observation into changes your team will actually ship. Let me walk you through how I do that.

Affinity Mapping and Spotting Patterns

I start by writing every single observation on its own sticky note, one problem per note. If you tested five people, you might end up with sixty or seventy notes.

Then I cluster them. Notes about the same friction point get grouped, and suddenly the patterns jump out at you.

This step matters because it protects you from chasing one-off preferences. If one user says they dislike the colour of a button, that is a preference. If four of five users walk straight past that button, that is a usability problem.

Picture a small Singapore SME selling homeware online. During testing, four of five users completed checkout without ever noticing a delivery fee tucked below the fold, then felt tricked when the total jumped at payment. That is not a preference. That is a repeated, evidenced breakdown.

Prioritising Issues by Severity and Effort

Not every problem deserves the same urgency. I rate each cluster by severity, meaning how badly it blocks or frustrates users, and by effort, meaning how hard it is to fix.

A quick way to sort is to ask three questions of each issue:

• Does it stop users from completing a core task, or just slow them down?
• How many participants hit it?
• How much design and development work does the fix need?

For that homeware SME, the hidden delivery fee is high severity and low effort. Reordering the checkout so the fee appears alongside the item price is a small change that removes a trust-killing surprise, so it goes straight to the top.

Fix the high-impact, low-effort issues first. That is how you show quick wins to a sceptical boss and earn room to tackle the harder ones later.

Writing Recommendations Stakeholders Act On

A recommendation only works if a stakeholder can act on it without asking you a dozen questions.

For each issue, I write three things: what happened, the evidence behind it, and the specific proposed change. So instead of “improve checkout”, I write “four of five users missed the delivery fee (see clips at 3:12, 5:40), so move the fee into the item summary before the payment step”.

That traceability, linking every fix back to specific user evidence, is exactly what separates a designer who ships value from one who has opinions. It is also what hiring managers look for, which is a big theme in why most UX designer job applications get rejected.

When every recommendation points back to a real user moment, your team stops debating taste and starts fixing problems. That is the bridge from insight to a shipped improvement.

Tools and Templates to Run Tests on Any Budget

Here is the good news I wish someone had told me earlier: you do not need a fancy research lab to run usability testing. The method matters far more than the money you spend, and you can start this week with tools you probably already have.

Free and Low-Cost Tools

My first tests were held over Zoom with the record button on and a spreadsheet open on my second monitor. That combination still works beautifully today.

You can ask your participant to share their screen while attempting your tasks, then rewatch the recording later to catch the moments you missed live. Google Meet does the same job if your team already runs on Google Workspace.

For the thing you are testing, a clickable Figma prototype is often all you need. If you are not sure how far a prototype can take you, this guide on what Figma is used for in real projects shows how teams turn static screens into something testable without writing a line of code.

A simple spreadsheet becomes your research database: one row per task, columns for what the user did, where they hesitated, and their exact words. That is your entire budget spent, which is to say, nothing.

When to Invest in Paid Platforms

Once you are running tests regularly, the manual admin starts to bite. That is the signal to look at paid remote testing platforms that recruit participants, record sessions, and auto-generate highlight reels for you.

I usually recommend paying only when one of these is true:

• You need to test with strangers, not colleagues, and recruiting them yourself is eating your week.
• You want unmoderated tests running overnight while you sleep.
• You are testing often enough that saved time clearly outweighs the subscription cost.

Singapore SMEs have another route worth knowing. A small e-commerce retailer I worked with used a design tool subsidised under the Productivity Solutions Grant (PSG) to build and share prototypes, then tested those prototypes with real shoppers over free video calls. They stretched a modest budget by paying for the design layer and keeping the testing layer free.

Templates You Can Reuse

The fastest way to look experienced is to stop starting from a blank page. Build three reusable templates once and clone them for every test.

Keep a test plan template covering your goal, participants, and tasks; a script template so you say the same neutral instructions each time; and a note-taking template matching your spreadsheet columns.

Save them in a shared folder your whole team can copy. After a few rounds, running a usability test feels less like a project and more like a routine, which is exactly the on-any-budget habit you are aiming for.

Conclusion

We have walked through the whole arc together: planning what to test, recruiting the right people, scripting realistic tasks, moderating without leading, and turning what you observe into fixes your team can actually ship.

Notice what was missing from that list. A big budget, a fancy lab, expensive software. None of it was the real blocker.

The real blocker is almost always the same thing I flagged at the start: we assume we know how people use our product, and those assumptions quietly cost us conversions every single day.

A small test surfaces the truth faster than any internal debate ever will. Watch five people stumble over the same checkout button, and the argument about whether it is a problem simply ends.

So here is my challenge to you. Pick one flow this week, maybe your sign-up form, your mobile navigation, or the way a customer books a service, and recruit five users. That is enough to expose the biggest issues.

You do not need permission or perfect conditions. You need a task, a screen to share, and the discipline to stay quiet and observe.

Once you have run that first test, you will want to do it properly and repeatably, with a methodology you can defend to stakeholders and a portfolio of real projects to show for it.

Ready to turn this into a real skill instead of a one-off exercise? The UX/UI Design Career Programme at Equinet Academy is built exactly for that: it takes you from foundational research methods through hands-on usability testing on live client briefs, with mentors who review your work along the way. If you want a structured path and a portfolio to show for it, enrol in the UX/UI Design Career Programme and start building that experience with real guidance behind you.

Run your first test this week, then build the skills to make it a habit.