Built it. They came. They didn't find it.

These two things are related but not the same, and conflating them leads to the wrong fix.

Adoption is the percentage of users who use a feature. Discoverability is whether users can find the feature at all. Low adoption might mean the feature isn't valuable. Low discoverability means users never got the chance to decide.

Teams that see low adoption often conclude the feature needs better in-app promotion or marketing. Sometimes the real problem is simpler: the feature is buried, unlabeled, or looks like something else. Fix the discoverability first — then ask whether adoption is still low.

Most discoverability problems come from one of three places:

• Depth without signposting: The feature exists but sits three clicks into a settings menu with no indication it's there. Power users find it eventually; everyone else doesn't.
• Weak affordances: The interactive element doesn't look interactive — no hover state, no clear call to action, no visual cue that something can be done.
• [Progressive Disclosure](/glossary/progressive-disclosure) gone wrong: Hiding advanced features to simplify the UI is a valid pattern. But if the disclosure mechanism is unclear, users conclude the feature doesn't exist.

There's also a fourth cause that's harder to fix: features designed in isolation that don't connect logically to the parts of the product where users already spend time.

When discoverability is genuinely the problem, a few patterns work consistently:

• Contextual tooltips: Appears at the right moment, in context, once. Not a tour, not a modal — a nudge when a user is close to the relevant action.
• Feature spotlights: A brief highlight after a deploy to surface a new or changed capability, tied to the user's actual workflow rather than a generic "here's what's new" banner.
• Empty state prompts: Empty States are prime real estate for surfacing features users haven't tried yet — moments when users have nothing to lose by exploring.
• In-product search: When navigation fails, search is the escape valve. Products with strong in-product search consistently show higher feature discovery rates.

The simplest test: give users a task that requires a specific feature, without mentioning the feature exists. Watch where they go. If fewer than 80% find it within a reasonable time without assistance, you have a discoverability problem.

Tree Testing is useful for navigational features. For feature panels and settings, Usability Testing sessions with a think-aloud protocol surface the gaps faster than any analytics tool.

Analytics can hint at the problem — low interaction with a specific element, long time-on-page without action — but they can't tell you why users didn't click. Observation fills that gap.

Not everything should be discoverable at first glance. A product that tries to surface everything to everyone ends up as a cluttered interface that's impossible to navigate. The real challenge is making the right things discoverable to the right users at the right time.

Progressive Disclosure and role-based access are both legitimate tools for managing this tradeoff. The test isn't "can all users find this feature easily?" — it's "can the users who need this feature find it before they give up or raise a support ticket?" That reframe shifts the design question from coverage to targeting.