Discovery depends on a visible entry, not a lesson

What it is

People use a feature first because the UI has a scannable entry: a name that matches the goal, a place on the task path, a control that looks clickable. Teaching (tours, coach marks, tips) is a patch after the entry fails, not a substitute. Discovery here means finding a capability without a special class. It is not creating the first item in an empty state, and not ticking a setup checklist. If the entry is invisible, even a good lesson only works during playback; when playback ends the feature vanishes again.

Why it happens

People search a UI by information scent: does the label sound like the job, does the control sit beside the step they are on. Enough scent, and discovery finishes in a glance, with nobody telling them. Teaching inserts scent into working memory for a moment, but working memory does not store layout; after the lesson, the UI must still speak. Betting discovery on teaching treats an episode as lasting navigation. The entry must also be present at the relevant moment: if export lives in a deep menu only when nothing is selected, scent in the relevant window is zero—the design hid the entry where it would not “get in the way.” Visible is not bigger everywhere—that dilutes scent—but aligned in name and goal in the patch of UI the task will search.

Studying it

Give a task with no tour and see whether people find the target feature in time; add an arm that watches a fifteen-second intro first.

Independent variables: whether the entry is on the current screen of the task path, whether the label uses the user’s verb, presence of teaching. Dependent variables: time to first find, abandon without finding, whether they can find it again with no prompt.

The teaching arm will look strong immediately; a later session without prompts reveals whether the entry stands alone. Eye tracking can show a scan that hits the entry and leaves because the label is wrong—scent failure, not invisibility.

Where it stops holding

A novel interaction grammar (an unseen gesture canvas) may still need one demonstration after the entry is visible; seeing is not skill. Capabilities behind permission or paywalls can have a visible entry whose discovery stops at the wall copy—that is acquisition, not discovery. Experts use shortcuts and treat the visible entry as backup; removing it from the menu in favor of shortcuts severs novice discovery. A phone cannot show every entry on one screen; discovery then depends on navigation structure, not on painting the button larger.

Applying it

• For each feature that must be discovered, name a visible entry on the critical task path: this screen or one hop, labeled with the user’s verb rather than an internal module name.
• Do not cover a buried overflow, hover-only, or off-path entry with a tour.
• Keep the entry present at the relevant moment: when an exportable object is selected, export should sit by that object, not only in settings when the selection is empty.
• Verify by turning off all automatic teaching and assigning jobs such as “get this to someone else / filter this.” If the entry is not found, change place and label before adding a bubble.

Related

• Within the group: H2.05.2 Usage data locates features that were never found · H2.05.3 Repeating the tour cannot fix a missing entry
• Adjacent: H2.02 Empty-state Guidance · G2.09 Auxiliary navigation and utility entries · H2.03 Progressive onboarding
• Search terms: discoverability · information scent · visible entry