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. A component can still be well drawn, well placed, and remain invisible. Visibility and presence are two different things, and confusing them leads to rebuilding something that has no problem.

An ongoing exploration at Homair Vacances gives a concrete case.

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 stays low on desktop, and it goes unnoticed on mobile. The easy reflex is to 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 interested in those sections’ content. So the problem lay neither in what we offer, nor in 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. When 73% of people never reach a component, the problem is its position and visibility. 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 is also decided by the component’s place within the real reading flow, the one scroll maps reveal rather than 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