Picture someone on their phone, trying to book a physio appointment. They tap "Book now". Nothing happens. They tap again, a little harder, the way we all do. Then they give up and book somewhere else.
The clinic never hears about it. Its analytics records one visit and one bounce. The page loaded, the server answered in a fraction of a second, and no error was raised anywhere. As far as every monitor is concerned, it was a perfectly ordinary Tuesday.
At Spectra we spend our days thinking about moments like that one: the gap between what a website is supposed to do and what a customer actually experiences. So we set out to measure how wide that gap really is, and how many teams would ever know it exists.
What we looked at
Two very different groups of websites.
The first was 100 small business websites: shops, booking sites, restaurants and service businesses across the United States, the United Kingdom, Canada, Australia and India, on phones, tablets and laptops. These are businesses where a single lost customer is a real cost, and where nobody has a team watching the website full time.
The second was 2,000 busy websites, popular but not household names. Among them were 166 web apps, the kind of product people sign in to use every day, run by teams that ship constantly and care a great deal about conversion.
Two groups, one question: when something on the screen stops working, does anybody find out?
Seven broken buttons, seven ways to lose a customer
On seven of the hundred business websites, a customer would have pressed something important and got nothing back.
a button or link customers couldn't useeverything worked
Here they are, without the names:
- A physiotherapy clinic. On phones, a reviews popup landed directly on top of the cookie banner's "Reject All" and "Accept" buttons. Every new visitor met a banner they physically could not close.
- A roofing company. The small Google reviews badge sat over the floating contact button on phones. That button is how the business wins jobs.
- A florist. On tablets, the opening hours box overlapped the contact form's "Submit" button. A customer could type an entire enquiry and never send it.
- A bakery. On ordinary laptop screens, the header wrapped onto two lines and covered its own menu, so clicking "Shop" did nothing at all. On a wider monitor, it works perfectly, which is exactly why it is so easy to miss.
- A yoga studio. An invisible strip of the header covered the phone number on the contact page. Tap to call, and nothing happens.
- An interior designer. Some of the site's own styling had gone missing, so the homepage slider collapsed into a thin strip and the "Book a free consultation" button disappeared behind the next section.
- A candle shop. The Instagram and Facebook links sat beneath an invisible layer on phones.
None of these sites was down. None of them raised an error. Open any of them on the "right" screen and they look completely fine.
The anatomy of an invisible failure
Look closely at those seven and a pattern appears. Almost every broken interface we see falls into one of four families.
1. Something floats on top
Chat bubbles, review badges, WhatsApp buttons, cookie banners, sticky promotional bars. Each one is added for a good reason, usually by a different person or a different vendor, and each one is designed in isolation. Put three of them on the same small screen and sooner or later one lands on top of the button that matters. This was the single most common cause of failure we saw.
2. Something wraps
A menu that fits on one line at 1440 pixels wraps onto two at 1280. A longer product name, a translated label, an extra link in the header, and the layout quietly reflows over its own controls. Nothing is technically broken. The page is simply arranged so that a customer's click lands on the wrong thing.
3. Something goes missing
A styling file fails to load, a font is swapped, a script from a third party times out. The page still renders, but not the way it was designed, and the parts that held everything in place are gone. These failures are the hardest to reason about, because the page your team sees and the page your customer sees are genuinely different pages.
4. Something only fails on one screen
This is the thread that runs through all of the above. The bakery's menu breaks at 1280 pixels and works at 1440. The florist's form works on a phone and breaks on a tablet. Modern websites are rendered across thousands of combinations of device, browser and screen size, and no team can personally test them all.
Why every tool you already have stays silent
Most teams are not careless about quality. They have uptime monitoring, error tracking, analytics and a QA process. The trouble is that each of those was built to answer a different question.
| What you have | What it tells you | What it never sees |
|---|---|---|
| Uptime monitoring | Your site is reachable | A button that loads but can't be pressed |
| Error tracking | Your code threw an exception | A layout fault, which throws nothing |
| Analytics | Visits, bounces and conversions | Why a visitor bounced |
| QA and testing | It worked on the devices you tested | The devices you didn't |
| Customer support | What customers tell you | Everyone who left without telling you |
Every row is useful. Every row has the same blind spot: the customer's actual screen.
3 in 4 busy web apps wouldn't know either
You might expect larger, busier products to be watching more closely. Mostly, they aren't.
Three in four run nothing on their home page that would show them what a visitor went through. Of those that pay for session recording, most use Hotjar: 14 of the 18.
The status page paradox
This is the finding that stayed with me. One in seven of these web apps publishes a public status page, yet runs no recording and no error tracking on its home page.
These are serious teams. They monitor their servers carefully and publish the results for their customers to see, which is exactly right. But a status page stays green while a signup button fails on every iPhone. Servers can be perfectly healthy while revenue is not, and the only people who know are the visitors who could not get in.
Recording is not the same as seeing
Even the one in five that do record sessions face a quieter problem. A recording product captures thousands of visits a week, and somebody has to watch them to find the one where a button failed. In practice nobody has the time. Recordings get opened after a customer complains, if they are opened at all.
What a team actually needs is not more footage. It needs a tap on the shoulder that says: this button, on this page, stopped working for real visitors on these devices, starting with Thursday's release. Here is the visit. Go and fix it.
That is a fundamentally different capability, and it is the one most of the web is still missing.
What the best teams do differently
The teams we admire most treat the interface the way great infrastructure teams treat their servers. A few habits stand out:
- They measure the customer's screen, not just the server. A page is not "up" if its most important button cannot be pressed.
- They watch every visit, not a sample. Interface faults are often confined to one device or one screen size. A sample of a few percent will miss exactly the visits that matter.
- They tie every fault to a release. When something breaks, the first question is always "what changed?", and they can answer it in seconds rather than in a meeting.
- They measure time to notice. Not just time to fix. The fix is usually minutes. The expensive part is everything before someone realises.
- They let support see what the customer saw. "It doesn't work" becomes a recording, not a back and forth.
A one-hour audit you can run today
You can do a meaningful version of this yourself, this afternoon:
- Open your three most important pages on a real phone. Usually home, pricing or booking, and signup or checkout. Tap every button that matters.
- Do the same on a tablet, and in a laptop window around 1280 pixels wide. That is where most layout faults hide.
- Accept and reject your own cookie banner on each device. It is the first thing every new visitor touches.
- Look hard at anything that floats: chat, reviews, WhatsApp, sticky bars. Make sure none of it covers anything important at any size.
- Repeat after your next release, and the one after that. Pages that worked last week break all the time.
It works. It is also exhausting, it covers a handful of devices out of thousands, and it has to be done again every time anything changes. Which is precisely why we built Spectra.
Where Spectra comes in
Spectra is interface intelligence for the web, and it gives you something no report ever has: your website, through the eyes of every single visitor.
It lives inside every visit, on every phone, tablet and laptop your customers actually use, and checks that the things they try to press really respond. Its capture engine works in under a millisecond per update, so your visitors never feel it. When something breaks, Spectra tells you the moment it happens, shows you the visit, and names the release that caused it, and it is 99% sure before it ever blames an update.
Once you have seen your site this way, you will wonder how you ever ran it blind. The teams that see these problems first are the ones that keep the customers.