Journal

A component can be invisible without being badly designed

2 min readVisual hierarchyResearchProduct Design

When a component is barely used, we suspect its design first: wrong label, wrong place in the hierarchy, unengaging look. Sometimes that’s true. But a component can be well drawn, well placed, perfectly understandable — and still be invisible. Visibility isn’t the same as presence, and confusing the two leads to rebuilding something that has no problem.

Here’s a concrete case, an ongoing exploration at Homair Vacances.

The symptom: a menu no one uses

On campsite pages, a menu is meant to guide users to the sections — pool area, activities, accommodation, prices. Its click rate is very low on desktop, and it goes almost unnoticed on mobile. The easy reflex: redraw it.

Rule out the first hypothesis with data

Before touching the component, you have to isolate the cause. A study of 450 users ruled out the most obvious hypothesis — disinterest: people are very interested in those sections’ content. So the problem wasn’t what we offer, nor how the menu is built.

Contentsquare pointed to the real culprit: an average scroll rate of 27%. Most visitors never scroll far enough down to see the menu. A component that 73% of people never reach doesn’t have a design problem: it has a position and visibility problem. It’s the same reflex as with booking-funnel conversion — measure before you rebuild, so you don’t fix the wrong part.

Visibility ≠ presence

An element present in the DOM, correctly styled, accessible, can be functionally absent for the user if it lives below the fold most people never cross. Visual hierarchy isn’t decided only inside the component, but in its place within the real reading flow — the one scroll maps reveal, not the one we imagine while designing.

Treat the cause, not the symptom

Once the cause is identified, the options change in nature. You don’t redraw the menu: you work on its position, its scroll anchoring, its persistence on screen. Three options are being tested on this visibility problem, before confronting them with qualitative research — because quantitative data tells you where it breaks, rarely why one precise solution will work better than another. (The full exploration: Why is our navigation menu so little used?.)

In short

  • Rarely used ≠ badly designed. A component can be good and still be invisible — check visibility before rebuilding.
  • Data isolates the cause. 450 users ruled out disinterest; a 27% average scroll rate pointed to the real cause.
  • Visual hierarchy plays out in the real flow. What matters is the position in the journey people actually make, not the one we imagine.
  • Quant for the “where”, qual for the “why”. The two complement each other; they don’t replace each other.

← Back to notes