How to Get Honest Website Feedback Before You Launch

The most useful website feedback comes from about 5 people who look like your real visitors, each asked to do one real task while you stay quiet. Run an audit first and use its report as your test plan, so each tester checks something specific. Then trust the problems that repeat.

After weeks of building, you read your own headline and see everything you meant, so asking outside eyes to look feels risky. Here is a small plan, in the order we would run it.

What should an audit clear out before you ask anyone?

Start here, so no tester spends a session on something you could find alone. The report comes from an AI scoring a fixed rubric, so no person reads your site. You get a score out of 100, a Verdict label, and for each of the six product dimensions a What works note, Slop tells, and Top fixes ranked by impact.

An audit checks for signals, and people tell you what they make of them, so use the report as a test plan, not a verdict.

How do you turn an audit report into a test agenda?

Open the report before you recruit anyone. 3 of its fields turn straight into things for testers to confirm or kill. (Our guide on reading an audit report goes deeper.)

• Not confirmed lists what the audit tried but could not verify. Hand these to a person first. Give a tester a task that passes through each one, and write down what happens.
• Top fixes, ranked by impact are bets about what hurts most. Build a path that touches the first fix in each dimension. If 2 or more testers hit the problem, it stays near the top. If nobody does, move it down your list, not off it, because 5 people can find problems but cannot prove a page is fine.
• Slop tells are predictions. Each one says where the report expects a visitor to notice work that looks generated or careless. Copy each onto a card as a plain sentence, and after the round mark it confirmed, contradicted, or not seen.

Keep a fourth pile for anything testers hit that the report never mentioned. That pile is the reason to run a people round.

Who should you ask for website feedback?

Ask people who could really use what you are making. For one kind of visitor, a good mix is 3 people who match your real visitor, 1 who knows nothing about your topic, and 1 who will use a phone, not a laptop.

If your site serves clearly different groups, test people from each. Nielsen Norman Group (NN/g), a research firm that studies how people use websites, suggests 3 to 4 per group when you have 2 groups, and 3 per group when you have more (NN/g, published 18 March 2000, page updated 2 February 2024, read 5 October 2026).

Start with anyone who has already talked to you about the problem, or a community you belong to.

What should each tester do?

Give every tester the same one main task, so you can count repeats: "Sign up for a shift," "find the price and start checkout," or "book a call." Then give each of the 5 testers one extra prompt, a different one each. Every prompt tests a different dimension of the rubric, so the round covers 5 dimensions.

Craft and Design Integrity gets no prompt on purpose. Testers volunteer taste comments unasked, and those are the easiest to park. Its Slop tells still go on your prediction card.

One catch: an extra prompt asked of one person is a single reading. Treat it as strong only when it matches a card or a second tester says the same thing unprompted.

Which questions get you flattery instead of facts?

"Do you like it?" and "Would you use this?" invite a polite yes, and they ask people to predict their behavior, which is not the same as watching it. Your own words can steer people too. NN/g's page on thinking aloud says prompts and clarifying questions are usually necessary, but from an untrained facilitator they can very easily change user behavior. The same page says that unless you blatantly bias users by putting words into their mouths, you will still get reasonably good findings, even from a poorly run study (NN/g, published 15 January 2012, page updated 31 January 2024, read 5 October 2026).

So keep your questions neutral, and say less:

• Instead of "Isn't the pricing easy to find?" try "Where would you look for the price?"
• Instead of "Is it clear?" try "What is this page asking you to do?"

How do you run a 5-person round?

Run it one person at a time. A video call works.

1. Fix the obvious breaks first. Run the audit and write your prediction cards. Then click every button yourself (our guide on testing a vibe-coded app without being a developer shows how).
2. Send the live link, and ask each tester to use their own device.
3. Ask them to think aloud. That means saying what they see, what they expect, and what confuses them as they go. NN/g notes this does not come naturally, so expect to nudge.
4. Stay quiet. Do not explain or defend the site. If they ask "what does this do?", answer "what would you guess?" If they go silent, ask "what are you thinking?"
5. Write down what they do, not only what they say: every pause, wrong click, and question.
6. Finish with 3 questions: What was this for? What almost stopped you? What would you change first?

Keep each session to 15 to 20 minutes, and tell testers that up front.

Why 5 people and not 50?

NN/g's article says the best results come from testing no more than 5 users and running as many small tests as you can afford. It puts the typical share of problems a single user finds at 31%, averaged across the projects its authors studied, and says that after the fifth user you mostly see the same things again. It prefers 3 studies with 5 users each to 1 study with 15, so you can fix what you find and check the fixes worked.

5 people are good for finding problems, not for measuring them. If 3 of 5 get lost on the same screen, fix it. That does not tell you how many future visitors will get lost, and the same page points to 20 users for studies that need numbers.

How do you read mixed feedback?

Sort it with these rules:

• Behavior beats opinion. What people did matters more than what they said.
• Repeats come first. The same snag from several people goes to the top.
• Broken is broken. A button that fails for one person is still a fix.
• One-off taste can wait. See if anyone else says it.
• Problems are useful, fixes are optional. People spot where it hurts and are weak at prescribing the cure.

Hypothetical example: 5 people try a made-up volunteer sign-up site for a community garden. Their task: sign up for a Saturday morning shift. Its made-up report had flagged some of what they hit and missed the rest.

The first row outranks the rest: 3 people could not answer a basic question about the page, and the report had called it, so that prediction is confirmed. The date picker gets fixed even though only 1 person hit it, and it shows why the people round is worth running: the report never saw it.

Is it worth asking an online crowd to roast your website?

Some founders post a link and ask a community to "roast my website." The replies are fast and blunt, but the people replying may not be your visitors and are not doing a task, so you get taste more than behavior. Run the round instead, or after it.

What do you do with the feedback once you have it?

Make 3 piles: breaks, repeated confusion, and everything else. Fix the first 2. Park the third.

Then change only a few things and run another round with 3 to 5 new faces. NN/g's article warns that a redesign can fix one problem and introduce another, so the second round is worth it. If you changed a lot, run the audit again first.

When people can say what your site is for and finish the one task you gave them, you are in a good place to launch. Our guide on when a vibe-coded MVP is good enough can help with that call. A kind "I would use this" is not a purchase.