Skip to content
Glasspage.studio

Our site looks fine on a designer's laptop but wrong on the sales team's screens. What are we missing?

Your design was validated on one screen. Four things usually break on the others: grey text tuned to a calibrated panel, full-height heroes on short laptops, hairline font weights, and colour picked in a dark room. Most are a day of token edits, not a redesign.

By Ethan Hibble

The design was checked on one screen, not on your audience's screens

A designer works on a 14 or 16 inch retina laptop, at full brightness, in a dimmed room, with the browser in full screen. That is the best display in your company. Your sales team is on a 1366x768 office monitor from 2016, under fluorescent light, with a bookmarks bar and two toolbars eating the top of the window. Your prospects are on phones in car parks.

So the site is not wrong. It was tuned for a panel that renders light grey text crisply, shows subtle colour differences accurately, and gives 900 pixels of vertical space. Take any of those away and specific, predictable things break.

In the site reviews we run at the start of a redesign, the same four defects come up again and again. Each one has a symptom the sales team can describe, a reason the designer never saw it, and a fix measured in hours.

Grey text that vanishes on a cheap monitor

Symptom: someone says the small text “looks faded” or “washed out”, and they cannot read your captions, form hints or footer links.

Cause: the text colour is a light grey on white. On a retina display in a dark room, #999 on #fff looks like readable soft grey. That pair is a contrast ratio of about 2.8 to 1, well under the 4.5 to 1 that WCAG asks for body text. A good panel flatters it. A budget TN monitor viewed slightly off-centre crushes the light end of the range and the text drops close to the background. Screen brightness at 40 percent, which is where a lot of office machines sit, does the same thing.

Why the designer never saw it: their display makes the illegal choice look fine. Contrast is the one design property you genuinely cannot judge by eye across screens. You have to measure it.

Fix: raise the grey. #767676 on white clears 4.5 to 1. #595959 clears 7 to 1 and survives a dim panel. If your greys live in design tokens, this is one value changed in one file and every caption on the site moves with it. In practice we usually find two or three offending greys, not twenty.

A hero sized to the viewport that pushes the button off a short laptop

Symptom: sales say the button is “below the fold” or “you have to scroll before you see anything”, while the designer’s screenshot shows the button clearly.

Cause: the hero section is set to 100vh, or given generous fixed padding, so it fills whatever screen it lands on. On a 16 inch retina laptop that leaves roughly 850 pixels of usable height and everything fits. A 1366x768 monitor gives you about 600 pixels once you subtract the browser tabs, address bar and bookmarks bar. A Windows laptop with a taskbar and a scaling setting of 125 percent gives less. Two hundred and fifty pixels is exactly one headline plus one button.

Why the designer never saw it: they never opened the page at that size. Figma frames default to widths, not heights, so vertical space is the dimension nobody tests.

Fix: stop tying hero height to viewport height. Set the height from the content plus a fixed maximum, and check the page at 1366x768 with browser chrome included. If the primary action does not fit, cut the eyebrow line or the subheading rather than shrinking the type.

Hairline font weights that disappear off retina

Symptom: headings look “thin”, “spidery” or “broken” on some machines and fine on others.

Cause: a 300 or 200 weight of a geometric sans, set large, looks elegant at retina density where a stroke is drawn with four physical pixels. On a standard 1x monitor the same stroke gets one pixel and some anti-aliasing, so it becomes patchy grey rather than a clean line. Windows renders type differently from macOS, which widens the gap again. Light weights at small sizes are worse still, because the stroke and the letterform both lose definition at once.

Why the designer never saw it: they own a retina screen and probably a Mac, which is the single most forgiving combination for thin type.

Fix: keep light weights for display sizes above roughly 40px, and use 400 or 500 for anything smaller. Nothing else in the layout needs to move. Changing a font-weight token is not a redesign.

Colour picked in a dark room that glares in a sunlit office

Symptom: “the site is blinding” from one person and “I can’t see anything on my phone outside” from another.

Cause: two opposite versions of the same mistake. Large fields of pure #fff, chosen because they look clean at 30 percent brightness in a dark room, become a lamp on a bright monitor at full brightness. Meanwhile a glossy phone screen outdoors loses most of its effective contrast to reflection, so mid-tone brand colours behind white text stop being readable. A brand teal that measures 3.5 to 1 against white is legible indoors and invisible at a bus stop.

Why the designer never saw it: room lighting is the variable nobody records. A colour approved at 9pm in a dark room is a different colour at 10am next to a window.

Fix: soften the largest light surfaces slightly, and hold your text-on-colour combinations to at least 4.5 to 1 so outdoor viewing has margin to lose. Test your brand colour as a background for white text before you commit to it, not after.

The ten-minute check, on the laptop you already have

You do not need a monitor cupboard to find these. Run these four in order, cheapest and highest-yield first, and note what breaks.

Anything that fails is a note you can send straight to whoever built the site. Say “the grey caption text measures 2.8 to 1 and needs to clear 4.5”, not “it looks a bit light”.

  1. Resize your browser window to 1366 by 768 including the browser chrome, using your dev tools device toolbar with a custom size. Count what is above the fold. If the primary button is not there, that is the fix with the highest commercial value.
  2. Turn your screen brightness down to 40 percent and re-read the smallest grey text on the page. Captions, form hints, footer links, disabled states. If you squint, it fails.
  3. Take a screenshot and convert it to greyscale. This strips hue out and shows you contrast as the screen actually delivers it. Anything that merges into its background merges for a portion of your audience too.
  4. Open the site on your phone outdoors in daylight, at whatever brightness the phone chooses. Try to complete the main action. This is the harshest test and the one closest to how prospects actually meet you.

When this is a token edit and when it is a real problem

Most of what this article describes is a day of work or less. Greys, font weights and hero heights are values, and if the site was built on a design system those values live in one place and change everywhere at once. We fix this class of defect during a build without it touching scope.

It becomes a bigger job in two cases. First, if the values are hardcoded across dozens of components, so there are forty places to change instead of four. Second, if your brand’s core colour cannot reach 4.5 to 1 against white text at any usable size, which is a brand decision rather than a web one.

If your site only looks wrong on other people’s screens, do not commission a redesign for it. Get the numbers from the four checks above, hand them over, and see how much survives. Whatever is left is the honest argument for doing more.

Frequently asked questions (FAQ)

Should we buy a cheap monitor to test on?

A second-hand 1366x768 laptop or monitor is a useful thing for a marketing team to own, and it costs less than an hour of design time. But it is not required to find these defects. Resizing your browser to 1366x768 catches the layout problems, and dropping brightness to 40 percent catches most of the contrast problems. Buy the hardware only if you keep shipping pages that break on it.

Is this the developer's fault or the designer's?

Usually the designer's, and usually not through carelessness. Contrast ratios and non-retina type rendering are decided in the design file, and a designer working on one good display has no signal that anything is wrong. A developer building the design faithfully will reproduce the defect exactly. The fix is a measurement step, not blame: check contrast with a tool and check layout at 1366x768 before either party signs off.

Does an accessibility audit catch all of this?

It catches the contrast failures, because those are measurable against WCAG. It will not flag a full-height hero that pushes your call to action off a short laptop screen, or a 200-weight heading that goes patchy on Windows. Those are usability and craft problems that pass every automated check. You find them by opening the page at the size and brightness your audience uses.

Related articles