Usability testing without users or traffic

Analytics and A/B tests need visitors. Usability studies need participants. Early products have neither, which is exactly when the biggest problems are easiest and cheapest to fix. The answer is not to wait. It is to use methods that do not need traffic, and to know their limits.

• Methods that work before you have a single visitor.
• Where simulated visitors fit in, and what they cannot do.
• What these methods miss that only real users show you.
• A simple order of operations for a pre-launch check.

Self review with a checklist. Go through the page as a stranger would: what is this, who is it for, why should I believe it, what happens when I click. It is free and catches a lot, but you already know the answers, which makes the gaps hard to see.

Hallway testing. Ask a few people outside the team to complete a task while you watch in silence. It is cheap and real, but friends and colleagues are rarely your target customers, and they are polite.

Expert or heuristic review. A designer or researcher checks the product against established usability principles. It is good at catching interaction problems, but it reflects one expert's judgment rather than your audience's needs.

Simulated users. Tools like Mimiq let simulated customers from your audience use your live site to do a task, react to a page, or review screenshots of a flow. They are fast and can be repeated after every change, but they are simulations, and they share the limits described below.

Audience variety without recruiting. A web page test shows your page to 25 simulated people in about 90 seconds, and the report breaks results out by role, age, gender, and country, so you can see how different groups react to the same screen.

Someone attempting the task. In a flow, each simulated person opens your live site in their own real browser and tries a task, such as signing up, for up to 40 steps. The report shows how far each one got, where they stopped, and why, in their own words. If the site is not live yet, screenshots of up to four steps can be reviewed as one flow instead.

Repeatability. Because a run takes minutes, you can fix one thing and run the next version on the same saved audience, so the same people see both. That loop is hard to afford with human sessions at the earliest stage.

Real behavior and real numbers. Everyone in a Mimiq report is simulated, and it predicts direction, not the size of a change. On 1,000 real headline A/B tests held out from its development, Mimiq's forecast picked the headline more readers clicked 76% of the time; the best rule of thumb, picking the headline written first, got 61%. Mimiq's forecast has held up on headlines. In pre-registered tests on emails, text messages and ads, it was no better than chance at ranking small wording changes, and on real web page tests it did not beat the simplest guess. A flow shows where people can get stuck, not how many real visitors will finish. That is useful for choosing what to fix and no substitute for measuring.

Real people doing the task. Simulated people can attempt the task in a real browser, but they bring no real data, no real deadline, and none of your customers' habits, and they cannot log in to an existing account. Whether your customers get through your checkout with their own cards and their own mistakes still needs real people trying.

Accessibility with assistive technology, physical context, and lived experience. Whether a screen reader user can complete your checkout, or how your app feels on a crowded train, needs real people.

Specialist audiences. If your users are clinicians, engineers in a niche field, or procurement teams, simulated reasoning gets generic. A few real conversations are worth more.

Testing with the wrong people. Colleagues and friends know too much. Whoever you use, human or simulated, should match the customer you are trying to win.

Asking for opinions instead of watching behavior. 'Do you like it?' produces politeness. 'Find out how much this costs' produces evidence.

Treating any single method as proof. Each method misses something. The point is to stack cheap methods so the expensive ones test a stronger version.