Prototype test finds 5 bugs—players quit at the 3rd

A prototype test turns up five bugs. Three sessions later, half the testers have gone quiet. The obvious read is that the bugs drove them off—but the timing doesn't quite fit. Most of them hit the third bug, logged it, and kept going for a while before they stopped. So what actually ended the session: the defect itself, or the moment the user stopped believing the product was on their side?

There's a useful distinction buried in that question, and it sits right where website development meets behavioural psychology. A bug is a technical event. Quitting is a decision. They're related, but not the way most teams assume.

The third bug isn't three times worse than the first

If you plot abandonment against bug count, you'd expect a straight line. Instead you tend to get a cliff. The first bug is absorbed—users mentally file it under "prototype, fair enough." The second gets a sigh. The third triggers something closer to a verdict.

This is loss aversion doing quiet work in the background. Kahneman and Tversky's framing was about how losses loom larger than equivalent gains, and the same asymmetry shows up in product experience. A user who has invested two minutes navigating your flow has built up a small psychological account of progress. Each bug doesn't just cost them a click—it threatens the accumulated value of everything they've already done. By the third interruption, the question shifts from "can I finish this task?" to "was starting this task a mistake?"

That's a different kind of failure. You're no longer debugging a feature; you're managing a user's sense of whether they backed the right horse.

The practical upshot: bug count is the wrong metric for prioritisation. Bug sequence matters more. A single defect placed early in a critical path can do more damage than four scattered through secondary screens.

What variable reinforcement teaches us about tolerance

There's a well-documented pattern in behavioural psychology called variable-ratio reinforcement—the principle that unpredictable rewards produce more persistent behaviour than predictable ones. It's usually cited in the context of habit formation, but it has a less-discussed mirror image: unpredictable penalties erode persistence faster than consistent ones.

Here's the concrete example worth holding onto. In usability testing, teams often see users tolerate a known limitation far more readily than an intermittent one. If a form is simply missing a field, users adapt. If a form sometimes saves and sometimes doesn't, they stop trusting the whole system—even though the average experience is better.

That's the third bug in a nutshell. Users aren't tallying failures; they're building a model of how reliable the product is. Three interruptions is often enough to flip that model from "mostly works" to "unpredictable." Once that flip happens, subsequent successes don't restore confidence at the same rate. The asymmetry runs both ways.

For anyone building business websites, this has a direct implication for how you run prototype tests. Don't just log bugs—log the user's stated confidence at each stage. A tester who says "okay, that's annoying but fine" after bug two and "I'm not sure this is going to work" after bug three has just handed you the most valuable data point in the session.

Decision-making under uncertainty is the real test

A prototype test is, from the user's side, a small exercise in decision-making under uncertainty. They don't know if the next screen will load, if their input will persist, if the flow will complete. Every bug raises the perceived variance of the whole experience.

Research on risk perception suggests people don't evaluate uncertainty in the abstract—they evaluate it relative to what they expected. A user who expected a rough prototype has a high tolerance. A user who expected a polished demo has almost none. Same bugs, different outcome.

This is why the "third bug" phenomenon is so inconsistent across test cohorts. It's not a fixed threshold. It's a threshold relative to expectation, and expectation is set before the session even begins. If your recruitment message said "early prototype, expect rough edges," you'll get different abandonment data than if it said "we'd love your feedback on our new site."

Worth auditing your own test scripts for this. The framing you use in the first thirty seconds may be doing more to determine your completion rate than anything you fix afterwards.

Why competitive play changes the calculus

There's a reason the third-bug cliff shows up more sharply in some contexts than others. When users are in a competitive or comparative frame—testing your site against a competitor, or working toward a visible goal like completing a purchase—their tolerance for interruption drops. The mental stakes are higher, so the loss aversion kicks in sooner.

This is well-documented in game design research, where players in competitive modes abandon sessions faster after repeated failures than players in exploratory modes. The mechanism isn't frustration per se; it's the perceived cost of continuing relative to the perceived cost of stopping. Competition raises the first and lowers the second.

Translate that to a business website. A user comparing three suppliers is in a competitive frame. A user browsing your blog is not. The same three bugs will produce very different abandonment rates depending on which frame they're in—and most prototype tests don't control for this at all.

If your test cohort is a mix of high-intent and low-intent users, your bug-abandonment data is probably averaging two very different curves. Segment before you conclude anything.

What to do with the finding

The instinct after a test like this is to fix all five bugs and retest. That's fine, but it misses the more useful move: instrument the sequence. Log where in the flow each bug lands, what the user said immediately before and after, and whether their stated confidence shifted.

Then prioritise by position, not severity. A low-severity bug early in the primary path will usually cost you more sessions than a high-severity bug buried in a settings screen. The third-bug effect isn't really about the third bug—it's about the moment the user's mental model of reliability tips over. Your job is to find that tipping point in your own product and push it as far downstream as you can.

The forward-looking question worth sitting with: if you can't eliminate bugs from a prototype, can you redesign the sequence so the ones you have land where users are most resilient? That's a design problem, not a QA problem—and it's the one most teams skip.