How to Test Your Website With Real Users Before Launch: A 90-Minute Usability Test

You can test a website with real users before launch in about ninety minutes, with five people who are not your colleagues, three realistic tasks, and a simple rule: watch what they do, do not lead them, and fix the blockers first. That is the direct answer. You do not need a laboratory, specialist software, or a large panel. You need people who resemble your customers, tasks written in their language, a quiet room or video call, and a notes sheet that records where each person hesitated, got stuck, or gave up. Five short sessions of about fifteen minutes each, plus a brief review afterwards, will surface the problems that actually stop customers — confusing labels, hidden prices, forms that ask too much — while there is still time to fix them before strangers judge the site in public.

This kind of testing is different from a technical launch checklist. A checklist verifies that pages load, links work, forms submit, and the site looks right on different devices. Those checks are essential, and they are not what this guide covers. User testing verifies something a checklist cannot: whether a stranger can understand the site, find what they need, and complete a task without help. A site can pass every technical check and still fail its visitors, because the menu uses the company's words instead of the customer's, because the booking button is below a wall of text, or because the form asks a question nobody understands. Only watching a real person try — and struggle — reveals those failures. That is why user testing belongs before launch, not after complaints arrive.

Why five testers are enough to start

Five testers will not find every problem on a large site, and nobody should claim otherwise. What five testers reliably do is find the most severe problems, and find them repeatedly. If three out of five people cannot find your prices, you do not need fifty people to confirm that prices are hard to find. You need to fix the prices page. If one person out of five stumbles on a minor label, note it and fix it if the fix is cheap, but do not let a single observation derail the launch. The value of a small round is speed: you can recruit, test, review, and fix within days, then run a second small round to check the fixes, rather than spending weeks organising a large study that delays launch and produces a report nobody acts on.

Choose testers who resemble your customers in the ways that matter for the tasks, not testers who resemble you. For a local trades site, that means homeowners in the area, of varied ages and confidence with technology, not web designers, marketers, or colleagues who already know the business. For a clinic site, it means patients or carers, not staff. For a shop, it means people who buy similar products online. Exclude close colleagues and anyone who helped build the site, because they already know where everything is and cannot un-know it. They will glide through tasks that baffle a stranger, and their smooth performance will give false confidence. A friend of a customer, a neighbour, or a past customer who is willing to help for a small thank-you is usually a better tester than an expert.

Recruiting is simpler than most owners expect. Ask past customers, local community groups, or friends of friends, and explain clearly what you are asking: fifteen minutes, no preparation, no right or wrong answers, and you are testing the website, not them. Offer a small thank-you — a voucher, a discount, or simply genuine thanks — and be clear about whether the session is in person or remote, and whether it will be recorded. Avoid paying in a way that makes testers feel they must praise the site. The most useful sentence you can say at the start of a session is: "If something is confusing, that is our fault, not yours, and telling us is exactly what helps." Testers who believe that sentence will be honest. Testers who feel judged will be polite, and politeness hides problems.

Plan the ninety minutes

A ninety-minute round has a simple shape. Allow about fifteen minutes per tester, with a short break between sessions to finish notes, plus thirty minutes at the end to review findings together and agree the fix order. Five sessions at fifteen minutes make seventy-five minutes of testing, but in practice you need buffer time: a tester arrives late, a video call needs reconnecting, a task runs long because the problem it reveals is interesting. Plan for two hours of calendar time for a ninety-minute testing block, and do not schedule testers back to back without breathing room. Rushing between sessions produces thin notes and missed observations, which defeats the purpose.

Block	Time	What happens
Welcome and consent	2 minutes	Explain the purpose, recording, and right to stop
Warm-up task	2 minutes	An easy task, such as finding the business name or opening hours
Main tasks	9 minutes	Three realistic tasks: find, enquire, buy or book
Closing questions	2 minutes	What was hardest, what would you do next, what is missing
Notes and reset	Between sessions	Finish notes before the next tester starts
Team review	30 minutes after all sessions	Agree blockers, fixes, and retest tasks

Keep the session structure identical for every tester, so that differences in performance reflect the site, not a different briefing. Use the same tasks, the same wording, and the same level of help — which should be as close to none as possible. If a tester asks "Am I doing this right?", the honest answer is "There is no right way; just do what you would normally do." If a tester is completely stuck for a long time, it is kinder to move on than to let them struggle in silence, but record that the task failed and where it failed. A failed task is data, not embarrassment, and it is the most valuable data a session produces.

Write task scripts in the customer's language

Tasks must be written as realistic goals, not as instructions that give away the answer. "Find the price of a boiler service" is a poor task if the menu item is literally called Prices, because it tests reading rather than finding. Better tasks describe a situation: "Your boiler has stopped working on a cold evening. Find out whether this business can help tonight, and how you would contact them." "You are comparing two clinics for teeth whitening. Find the price, what is included, and how to book." "You want to buy a gift for a friend who likes handmade soap. Find a suitable product and get as far as checkout, without paying." These tasks force testers to navigate, interpret, and decide, which is exactly what real visitors do.

Cover three kinds of task in every round, because they stress different parts of the site. A find task tests navigation and labelling: can the tester locate information? An enquire task tests contact routes: can the tester ask a question or request a quote without confusion? A buy or book task tests the transaction: can the tester complete the form, understand the cost, and reach a clear confirmation? If your site has no online purchase, replace the buy task with a booking or enquiry task that still requires completing a form. Write the tasks down verbatim and read them aloud or show them on screen, so every tester receives the same wording. Do not improvise new tasks mid-round based on what a previous tester said, because that breaks comparability and tempts you to steer the session toward confirming an opinion you already hold.

Observe without leading

Observing well is harder than it sounds, because the instinct to help is strong. When a tester hesitates, the facilitator wants to point, explain, or rescue them. Resist that instinct. Your job is to watch, listen, and ask neutral questions: "What are you thinking?", "What did you expect to happen there?", "What would you do next?" Do not say "Did you see the menu at the top?" or "Try clicking Prices", because a hint destroys the evidence. If the tester needed a hint, the site needed a clearer route, and that is precisely what you are there to learn. Note the exact moment of hesitation, the words the tester used, and what they tried before giving up. Those details tell the designer what to change; a general note such as "tester struggled" does not.

Watch for behaviour, not just opinions. Testers will often say a site is "fine" or "easy" out of politeness, even after visibly struggling. Trust what they did over what they said afterwards. Did they scroll past the button twice? Did they tap the wrong menu item, go back, and try again? Did they abandon a form halfway through? Did they read a price and still ask what it included? Each of those behaviours points to a specific fix: a button that needs moving, a label that needs renaming, a form field that needs explaining, a price page that needs more detail. At the end of the session, ask what was hardest, what felt missing, and what they would do next if they really needed this service. Those closing questions often surface the one problem the tasks did not expose.

Score simply, then fix blockers first

You do not need a complex scoring system. For each tester and each task, record one of four outcomes: completed easily, completed with difficulty, completed with help, or failed. Also record the time taken in broad terms, the point of difficulty, and any exact words the tester used. That is enough to prioritise. A task that three or more testers failed, or completed only with difficulty, is a blocker and must be fixed before launch if it affects enquiries, bookings, or purchases. A task that one tester struggled with may be a minor fix or a tester-specific issue; fix it if the fix is cheap and harmless, and retest it in the next round rather than treating it as a launch blocker on its own.

Task	Tester 1	Tester 2	Tester 3	Tester 4	Tester 5	Priority
Find a price	Easy	Difficult	Failed	Difficult	Failed	Blocker — fix before launch
Send an enquiry	Easy	Easy	Difficult	Easy	Easy	Minor — clarify one form field
Book or buy	Difficult	Failed	Difficult	Failed	Difficult	Blocker — fix before launch

The table above is a blank scoring pattern with illustrative outcomes, not results from a real study. Use it as a template: replace the illustrative entries with your own testers' outcomes, and let the pattern across testers, not any single result, set the priority. Fix blockers first, then the difficulties that affect many testers, then the minor issues. Resist the temptation to fix cosmetic preferences — a colour, a photo, a headline style — before fixing a task that customers cannot complete. A beautiful site that cannot be booked is a failed site, while a plain site that books easily is a working business tool. Polish can follow once the core tasks work.

Fixing order also means fixing one thing at a time where the fix affects the task route. If prices were hard to find because the label was vague and the page was buried, renaming the label and moving the page are related fixes that can be done together, but test them together as one change in the retest. If you change the navigation, the form, and the homepage headline all at once, and the retest improves, you will not know which change helped — which matters when the next site reuses your lessons. Keep a short log: problem observed, fix made, retest result. That log becomes the evidence that launch is justified, and it protects the fixes from being quietly undone by later edits.

Retest, then decide about launch

Retesting does not require another five testers if the fixes are small and specific. Two or three fresh testers — people who did not take part in the first round — running the same tasks will usually confirm whether a blocker is fixed or merely moved. Fresh testers matter because previous testers have learned the site and can no longer judge it as strangers. If the retest still shows failures on a core task, fix again and retest again. This loop is short and cheap when the site is small, and it is far cheaper than launching with a known blocker and losing enquiries while you investigate complaints. Launch when core tasks — find, enquire, buy or book — can be completed by strangers without help, even if minor polish remains. Perfection is not the launch criterion. Completing core tasks unaided is.

Record the decision honestly. If a known blocker remains at launch for a business reason — for example, a booking system that will not be ready for two weeks — say so in the launch notes, provide a workaround such as a phone number prominently displayed, and set a date to retest. Launching with a known, documented workaround is a business decision. Launching while pretending a blocker does not exist is a gamble with customers. The testing notes, the fix log, and the retest results together make that decision defensible, because they show what was found, what was fixed, and what remains. Keep those notes with the site's launch record; they are as much a part of the build as the pages themselves.

Remote versus in-person, and what to record

In-person sessions make observation easiest: you can see hesitation, watch where a finger hovers, and notice when a tester looks away from the screen. They require a room, a device, and travel time, which limits who can take part. Remote sessions, over video call with screen sharing, remove travel and widen the pool of testers, including customers in other towns. They require a little more care: test the call and screen sharing beforehand, ask the tester to share their screen rather than watching your screen, and accept that you will miss some body language. For most small business sites, remote testing is perfectly adequate, because the evidence that matters — clicks, hesitations, wrong turns, abandoned forms — is visible on screen. Choose the format that gets you real customers fastest, not the format that looks most professional.

Recording helps, provided you handle it properly. A screen recording with audio lets the team review moments they missed and quote exact tester words when arguing for a fix. Always ask permission before recording, explain what will be recorded and who will see it, and offer a no-recording option without penalty. Store recordings securely, delete them when the fixes are complete unless you have a reason to keep them, and never share a tester's personal details or full name in a report. For most small rounds, careful notes are sufficient and recordings are a bonus. Do not let the absence of recording software delay testing. A notebook, a timer, and five honest strangers will teach you more than a perfect recording setup that never gets used.

Consent and notes template

Consent does not need legalistic language for an informal test, but it does need to be explicit. Before the session, tell the tester what will happen, how long it will take, whether it will be recorded, and that they can stop at any time without giving a reason. Ask them to confirm they are happy to proceed, and note that confirmation with the date. If the tester is a past customer, make clear that their answers will not affect any future service or price. If you offer a thank-you voucher, say so upfront, so the tester does not feel it depends on praise. Keep personal details to a minimum: a first name or initials, a broad description such as "homeowner, uses a phone for browsing", and the session notes are enough. There is no need to collect addresses, phone numbers, or other details the test does not require.

Use one notes sheet per tester, with the same headings every time: tester description, task, outcome, time, point of difficulty, exact words used, and suggested fix. Fill it in during the session, not from memory afterwards, because details fade fast and the next session overwrites them. At the end of the round, transfer the outcomes into the scoring table above and look for patterns across testers, not just striking single stories. A single tester who loved a feature is encouraging, but three testers who failed the same task are a launch decision. That discipline — same tasks, same notes, patterns over anecdotes — is what turns casual feedback into reliable pre-launch evidence.

Frequently Asked Questions

How many testers do I really need before launch?

Five is a practical starting round for a small business site. It reliably surfaces severe problems. If your site is large or serves very different audiences, run a second round with testers from the other audience rather than expanding the first round indefinitely.

Can I test a site that is not fully finished?

Yes, provided the core tasks are testable. Testers can judge navigation, wording, and forms on a near-complete site. Do not test a site with placeholder text on key pages and expect useful feedback on those pages, because testers will react to the placeholders, not the finished content.

Should I pay testers?

A small thank-you is good practice and widens participation. Keep it modest and unconditional, so testers feel free to be critical. Genuine thanks and a clear explanation of how their feedback helped also matter, and cost nothing.

What if a tester cannot complete any task?

Record each failure, thank them, and move on. Multiple failures across testers point to a structural problem, not a tester problem. A session where nothing works is still a successful test, because it prevented a public launch failure.

Is remote testing as good as in-person testing?

For most small business sites, yes. Screen sharing shows clicks, hesitations, and wrong turns clearly. In-person sessions add body language and are easier to observe, but remote sessions reach more real customers with less travel and scheduling effort.

How do I handle a tester who praises everything?

Trust behaviour over praise. Note what they actually did, where they hesitated, and how long tasks took, even if their closing comments were positive. Ask what was hardest and what they would change, which often draws out the honest criticism politeness hides.