Quality & Research

    Device myopia: testing only the hardware you own

    One device tells you about one device. Testing only your own flagship hardware quietly excludes the customers least like your team.

    Device myopia is the assumption that if something works on your device, it works everywhere. Teams test on the newest, largest, most convenient hardware and miss the variation that defines real use: screen sizes, OS versions, accessibility settings. The excluded customers are a market, and they leave without complaining.

    Device myopia is the assumption that if something works on your device, it works everywhere. Teams test on the latest iPhone or flagship Android, on the largest screen in the office, in default settings. Reality is messier: dozens of screen sizes in active use, multiple OS versions still deployed, accessibility settings like large text and reduced motion switched on, and interaction patterns that vary across hardware generations. Testing only the convenient slice systematically excludes large portions of the market, usually the portions least like the people building the product. And the bias is invisible from inside the team, because everything works on their machines.

    Why it matters to the business

    The excluded cohort is a market, not an edge case. The Return on Disability Group sizes the disability market at 1.85 billion people who, with friends and family, control over $13 trillion in disposable income, and many of them run exactly the non-default configurations teams never test. The losses are silent: the UK's Click-Away Pound survey found 69% of disabled online consumers simply click away from hard-to-use sites and only 8% ever complain, while 86% have paid more on a site that works for them. And broken is the default state of the web. WebAIM's 2025 audit found accessibility failures on 94.8% of the top million home pages, which makes competence here a genuine differentiator.

    How to use it

    • Name the exact devices in your test pool and publish the list; if the team cannot name them, it is not testing.
    • Build the pool from customer analytics: top devices by revenue, the oldest supported OS, the smallest viewport with material traffic.
    • Include at least one device over two years old and one mid-range Android in every release test.
    • Test with accessibility settings on, including large text, high contrast, reduced motion, and a screen reader, following Microsoft's inclusive design principle: solve for one, extend to many.
    • Refresh the matrix quarterly as your traffic mix shifts.

    Where teams get it wrong

    They wait for complaints that never come. Excluded customers do not file tickets; they leave, and the team reads the silence as proof the product works. Meanwhile the test pool drifts toward whatever hardware the team personally upgraded to, and the gap between the office and the market widens every year.

    Ask your team

    • Can we name the five devices we test on, and what share of revenue do they represent?
    • When did anyone last use our product with large text or a screen reader?
    • How does conversion on devices older than two years compare with new ones?

    If a team can't name the devices it tests on, it isn't testing. It's hoping.

    Apply this

    Reading about device myopia: testing only the hardware you own is one thing. Seeing where it applies in your journey is the useful part.

    Related signals