How to Find UX Issues Before Users Complain: Near Misses

Open your analytics on the step that matters most to you, the signup form or the first screen after it, and pull last week's visitors who completed it. Look at how long each of them spent on that step. Find the median, then count the people who took more than twice as long and still finished. Twice is an arbitrary line, so pick any line you like; the count matters more than where you draw it.

Every one of those people nearly didn't make it, and none of them wrote in. If you searched for how to find UX issues before users complain, that number is where I would start, and I suspect most teams have never pulled it.

Finding UX issues before users complain means catching the problems on a page from the visitors who struggled and carried on, or struggled and left quietly, instead of waiting for the few who are annoyed enough to write a ticket. It is a question about where your evidence comes from, more than about which tool produces it.

Support tickets as an early warning, and why they arrive last

On 1 December 1974, TWA Flight 514 was descending through cloud towards Washington Dulles when it flew into a ridge near Mount Weather, Virginia, killing all 92 people aboard. The National Transportation Safety Board's report (AAR-75-16) turned up something worse than one bad descent. About six weeks earlier, another airline's crew had made the same early descent on the same approach and realised it only after landing. Their airline's own anonymous reporting programme caught it and warned its own pilots, and nothing reached other airlines. NASA's account of the reporting system that followed names that airline as United; the NTSB report does not name it.

The response was a reporting system that sat outside the regulator. The FAA launched a voluntary reporting programme in April 1975 and, under an agreement that August, handed the receiving and analysis of reports to NASA. The Aviation Safety Reporting System began taking reports in April 1976, run by NASA and funded by the FAA, so that a pilot's report goes to a third party with no power to punish them. It is confidential and voluntary. Under FAA Advisory Circular 00-46F, a pilot who files with NASA within ten days of an inadvertent violation gets no civil penalty or suspension, as long as there was no accident or crime and no violation in the previous five years. What it collects is near misses: the altitude deviation that got caught in time, the clearance that was misheard and then queried.

The two kinds of evidence teach different things. A crash investigation needs a wreck, and from it investigators can reconstruct one event in extraordinary detail after the price has been paid. A near-miss report needs only someone willing to write down what nearly happened. My reading is that near misses happen far more often than crashes and tend to share their causes, so the reports surface a hazard while it is still cheap to remove. The NTSB came close to saying so about Flight 514: it called it "most unfortunate" that the earlier incident had not gone through "uninhibited reporting and subsequent investigation which might have resulted in broad and timely dissemination of the safety message".

Most product teams run this the other way round. Support tickets, churn reasons and NPS comments get treated as the early-warning system, the place where UX issues first show up, when in the aviation picture they belong with the wreck. By the time a visitor is annoyed enough to write in, the same cause has already turned away the people who were never going to write anything, and I would bet those people outnumber the writers by a margin no ticket queue can show you.

A product manager asked this exact question on r/ProductManagement on 4 June 2026: "How do you guys figure out UX issues in your product before users start complaining?" The highest-voted reply said it more neatly than I can: "Support tickets became more of a validation source than a discovery source." A ticket tends to confirm something you already half-suspected, weeks after the discovery was there to be made.

UX issues users never report: the report nobody writes

A hesitation on your page is a near miss. A visitor reaches the pricing table, scrolls back up to the feature list, comes down again, sits for a while, and signs up anyway. Your analytics already records some of that as events: a long dwell, a back-and-forth scroll, a field focused and abandoned, perhaps a rage-click flag. Those events tell you where the hesitation happened and that it happened.

They cannot tell you why, and this is where the aviation comparison does most of its work. The part of an ASRS report that makes it useful is the narrative, the section where the pilot writes in their own words what they were doing and where it nearly went wrong. A tally of altitude deviations would show an analyst where trouble clusters. The narrative is what gives them the root cause, say a chart that was easy to misread or a phrase that sounded like a clearance, and with it something to change.

The equivalent document for your page would be the visitor writing down what they were looking for at the moment they paused, and nobody writes it. You have the incident log, with timestamps and scroll depths, and no report attached to any line of it, which is how a team can know precisely where users drop off and still argue for a month about what to fix.

Someone on r/GrowthHacking put the gap plainly on 2 August 2026: "Session recordings show what people do; they don't tell you what evidence they were still looking for." That is the missing narrative box, described by a person who had watched enough replays to notice it was missing. The longer argument about recordings is that motion data cannot carry intent. The near-miss framing adds something less comfortable: the visitors who hesitated and stayed are invisible even to a team that reads every ticket, because by the time they finished they had no reason to write.

Catch UX problems early: count the near misses, then read the page

The method has two halves, and the first is counting. These are the near-miss counts I would pull from tools you probably already own:

• Long time on a single step followed by completion, the count from the top of this piece. It is the cheapest to get, since almost every analytics setup records time on page or time between events.
• A form field focused, left, and returned to.
• A back navigation away from the step and a return within the same session, which usually means the visitor went to find something the step did not tell them and came back with it.

Each of these is a proxy. None of them proves a visitor was confused, and the section after this one is about how they mislead.

The second half answers the question you came with. Once you know which step, and which part of the page, the near misses cluster on, read that part as a first-time visitor and write down what they needed to know at that moment. Then check whether the page tells them. At a near-miss cluster this usually comes down to a handful of questions: whether the next step is obvious, whether it feels safe to carry on, whether the value is clear before the page asks for something, and whether the worries a newcomer would have are answered anywhere nearby. My claim, which I could be wrong about on any given page, is that one of them is doing most of the damage wherever hesitation bunches up.

One founder on r/GrowthHacking, writing on 7 July 2026, described filing his own near-miss reports by hand: "I literally screen-recorded my whole funnel as if I were a first-time buyer, pausing at every "huh?" moment and fixing those friction points one by one before touching traffic or pricing again."

The nearest I have come to seeing one first-hand was on an infrastructure-monitoring product built by a managed service provider, which I was brought in to redesign. It had not come up in the customer interviews. Watching the company's own sales engineers try to demo the product is what showed it: they could not reliably find the features they were there to show. If the people who knew the product best got lost in it, its customers were very likely getting lost in the same places. The fix was a navigation organised around the questions engineers ask when something breaks.

The part of the analogy that does not hold

ASRS works because pilots have a reason to file. A report filed in time earns limited protection from penalty, and the pilot was there, so they can say what they were thinking. Your visitors have no reason to file anything, and I doubt most of them could tell you afterwards why they paused even if you asked. So the report has to be reconstructed by someone reading the page. A reconstruction is an inference, where a pilot's narrative is testimony, and we can be wrong about why a visitor stopped on a field. When we are, the change we make may weaken something the page was quietly doing well.

The counts over-count, too. A long pause is sometimes careful reading by a buyer who was always going to sign, the kind who reads the whole security page because procurement will ask about it later. A back navigation can be someone checking the price one more time before saying yes. Treat a jump in any of these counts as a reason to look, and check that it is real before you react, because a week-on-week change in a small count is often ordinary wobble that looks like a signal. I do not have a clean way to tell the careful reader from the stuck one using behaviour alone, and I am not convinced anyone does.

What you can check before the next complaint arrives

Go back to the count from the opening and pick the one step where last week's stalled-then-finished number was highest. Write down, in a sentence, what a visitor needs to know at that moment to carry on without stopping. Then open the page as someone who has never seen it and look for that sentence, or anything doing its job. If it is missing, you have found a piece of conversion friction that nobody was ever going to report.

Your ticket queue covers the visitors annoyed enough to write, and your funnel report covers the ones who left. The count from the opening gets you the ones who hesitated and stayed. Take the visitors who hesitated on your page this week and said nothing: for how many of them could you say what they were looking for?