There is a class of UX problems that product teams cannot see from the inside. They use the product every day. They wrote the copy. They know where the export button is. The users who do not finish onboarding, the customers who give up at the third step of checkout, the mobile visitors who bounce at 74% — those people leave silently. The team builds the next feature.
This is a list of five UX problems that are almost always invisible from inside the team, and almost always visible from outside it. Each comes with a diagnostic you can run this week.
Sign 1 — A drop-off cliff in your funnel that you have stopped noticing
Every product has a funnel: visit → sign-up → activation → first value → retention. Every funnel has one or two steps where users drop off harder than they should. If you have been working on the product for more than six months, you have stopped seeing the cliff because the team has adapted around it (“the form is long but it’s necessary,” “the verification email is unavoidable”).
The diagnostic: pull your analytics for the last 30 days. Calculate the conversion rate between each step. Find the step where the rate drops more than 35% from the previous step. That is your cliff. If multiple steps qualify, take the earliest one — earlier cliffs cost more in absolute terms.
The fix: not “redesign the page.” Watch five new users actually go through that step (session recordings if you have them; usability tests if you do not). The fix becomes obvious within the third recording — users hesitate or stop in a place the team did not predict. Then redesign the page.
Sign 2 — Your support inbox keeps answering the same question
If your customer support team is answering the same question more than twelve times a month, your UX is not communicating something it needs to. Common offenders: where the export button is, how to change a billing address, how to cancel (often the most-asked support question, and the most-resented one when it cannot be found).
The diagnostic: ask your support lead for the top five most-asked questions of the last 30 days. Count the tickets per question. Any question with more than 12 tickets monthly is a UX problem disguised as a support problem.
The fix: NOT a help article. A help article is a confession that the UI failed to communicate. Find the screen where the user is at the moment they ask the question, and fix the screen — by adding the missing affordance, by improving the labelling, by changing the flow. Help articles are a downstream symptom; the screen is the cause.
Sign 3 — New users take more than five minutes to reach first value
“Time to first value” is the time between sign-up and the moment the user does the thing they signed up to do — sent the first message, completed the first export, ran the first report, made the first transaction. Below five minutes, products feel snappy. Above five minutes, products feel unfinished. Above fifteen, products feel like work.
The diagnostic: sign up to your own product as a brand-new user (incognito window, real email, no prior context). Time yourself from sign-up to first value. Be honest. If you are over five minutes, your onboarding is broken — even if your activation metrics look fine, because users who survive a broken onboarding are not representative of users who quit during it.
The fix: compress the onboarding aggressively. Defer settings and configuration until after first value. Default everything reasonable. Replace “wizard with 8 steps” with “a single screen that gets the user to the thing they came for, then offers configuration after.” Stripe famously gets first transaction-test in under 60 seconds. Linear gets first ticket in under 90. Both did this deliberately.
Sign 4 — Mobile bounce rate is double desktop
For most product categories in 2026, more than half the traffic is mobile. If your mobile bounce rate is much higher than your desktop bounce rate (more than 20 percentage points spread), the mobile experience is failing in a way the desktop one is not.
The diagnostic: compare bounce rate by device in your analytics for the last 30 days. If mobile is significantly worse than desktop, you have a mobile UX problem regardless of how good the desktop experience is. If they are roughly equal, your problem (if any) is universal, not device-specific.
The fix: mobile-first redesign, not “mobile responsive.” Responsive design treats mobile as a constraint to fit the desktop layout into. Mobile-first treats mobile as the primary surface and desktop as the secondary expansion. The two approaches produce visibly different products. If your bounce gap is large, you almost certainly have a responsive-from-desktop product, and the fix is structural.
Sign 5 — The “obvious bug” that is actually a flow problem
Users report things like “checkout is broken” or “the export button doesn’t work” or “the dashboard is wrong.” Engineering investigates, finds no bug, marks the ticket as “user error” or “by design.” The user does not respond. The pattern repeats.
These reports are almost never actual bugs. They are flow problems disguised as bugs because the user does not have the vocabulary to describe the flow problem. “Checkout is broken” usually means “the shipping step is unclear, I cannot tell what to do next, I assume something is broken.” The technology is fine; the UX is not.
The diagnostic: ask your support team to flag any “bug report” that engineering closed as not-a-bug. Look at the top five. Each is almost certainly a UX problem — and the team has been ignoring it because it does not fit the technical mental model.
The fix: stop closing these tickets as not-a-bug. Reclassify them as UX-issue. The fix is not in the codebase; it is in the design.
How to run these diagnostics this week
None of these signs require an expensive UX audit. They require analytics access, the support inbox, and a willingness to watch five real users try to use the product. The diagnostics in total take roughly one working day — typically less than the team is currently spending on the symptom each week.
If you find more than two of the five signs in your product, you have a UX problem you cannot see, and it is costing more than you think. The fix is not necessarily a redesign — it is usually a series of focused changes to specific screens and flows. Diagnosis is dramatically cheaper than action; do it first.
The single-line version
Most UX problems are invisible to the team that built the product, and obvious to a designer who looks at the data and watches five real users. The cost of the diagnosis is small; the cost of ignoring the signs is large and silent.
Common questions
How do I know if my product has a UX problem?
Run five quick diagnostics: (1) Check your funnel for a drop-off step where conversion drops more than 35% from the previous step. (2) Ask your support team for the top five most-asked questions — any question asked more than 12 times a month is a UX problem disguised as a support problem. (3) Sign up to your own product as a brand-new user and time how long it takes to reach first value — if it’s over five minutes, onboarding is broken. (4) Check mobile bounce vs desktop — a gap of more than 20 percentage points means mobile UX is failing. (5) Look at “bug reports” closed as not-a-bug by engineering — most are flow problems, not bugs. Two or more signs and you have a UX problem worth investigating.
What’s a good time-to-first-value for a SaaS product?
Under five minutes for the user to reach the first thing the product was hired to do. Below five minutes feels snappy. Five to fifteen feels like work but is acceptable for complex products. Over fifteen minutes feels unfinished and is a strong predictor of churn. The fastest products products optimise aggressively: Stripe gets users to a test transaction in under sixty seconds; Linear creates a first ticket in under ninety seconds. The way to get there is not faster screens — it is fewer screens. Defer everything you can to after first value: settings, configuration, team invites, customisation. Get the user to the thing first, then offer the configuration.
What’s the difference between a UX audit and a redesign?
A UX audit identifies problems and prioritises them; it does not fix them. A redesign builds the fix. The audit is typically 1–2 weeks and produces a written report covering funnel drop-offs, accessibility issues, content design gaps, and the prioritised fix list. The redesign is typically 4–12 weeks depending on scope. The mistake teams make is jumping to the redesign without the audit — you fix the most visible problems and miss the high-impact ones, then run out of redesign budget before reaching the real issues. Audit first, redesign second, always.
How often should we run usability testing?
Light-touch usability testing — five users watching five tasks — should happen for every significant new feature before it ships. That is one session per quarter for most product teams, more if you ship faster. Heavier-weight testing — full moderated sessions with persona-matched participants, recorded and synthesised — is appropriate twice a year for SaaS, four times a year for consumer products with high churn risk. Never running usability testing is a credible answer only if (a) you have such strong qualitative signal from support and sales that you do not need it, or (b) you are pre-product-market-fit and iterating too fast to test. Both are rare.
Can I diagnose UX problems without a UX designer on the team?
Yes, partially. The five diagnostics in this article can be run by a founder, a product manager, or a customer-success lead — they require analytics access, the support inbox, and the willingness to sign up to your own product as a new user. What you cannot easily do without a designer is interpret WHY users behave the way the data shows — that requires pattern-recognition trained on hundreds of products. So: diagnose yourself, then commission a 1–2 week UX audit to interpret what the data means and produce the prioritised fix list. The audit is the most cost-effective UX investment a non-designer-led team can make.
Run the diagnostic. Then commission an audit if you find something.
We run two-week UX audits that interpret the data and produce a prioritised fix list — cheaper than redesigning the wrong thing.