A coach mark interrupts the current task, so their number must be strictly capped
Aliases: coach mark · feature spotlight · first-run bubble
What it is
A coach mark is a teaching layer the system places on the UI of its own accord, spotlighting a control and attaching a sentence. It is not a tooltip the user asked for. It is an interruption inserted into the current task: someone is already doing their work, and the bubble requires that sentence to be seen first. Because it interrupts, count is a budget, not a backlog of new features. The more you spend, the less each sentence is read, and the one step that actually needed teaching is dismissed with the rest.
Why it happens
Attention in a running task is already allocated to a goal. A coach mark uses a scrim and a spotlight to pull that attention onto a control the product wants to promote; working memory has to put down the step in progress to read a sentence that may not be needed now. The cost adds per interruption: the first still feels new, the third starts to feel like an obstacle, the sixth trains a policy of “dismiss this kind of layer on sight.” The budget is not aesthetic restraint. It is protection so the later, actually useful interruptions are not habit-exempted. Coach marks occupy a surface similar to a modal, often without must-respond content, so their licence to interrupt is weaker than a modal’s, and they have even less claim to queue. Teaching the one action needed for the task at hand, in this session, is more likely to be finished than introducing five new features.
Studying it
Split new users into groups that see 1, 3, or 7 coach marks. The main task is what they came to do; the marks teach side features. Record reading time, skip rate, main-task completion, and how many marks are recalled. Independent variables: count, whether a mark blocks the main path. Dependent variables: effective reads (dwell past a readable duration), the index at which habitual dismiss appears. Recalled count usually does not rise linearly with count; it caps at a small budget.
Where it stops holding
An empty account, first open, with no task of its own, can tolerate a slightly wider budget, still short. In a training mode the user is explicitly in class, interruption becomes curriculum, and count is set by the lesson. Error recovery (“that step failed, look here”) is in-task help, not a feature advert, and should not spend the same budget — nor should it become a chain of bubbles. Returning users are already habit-trained; new-feature marks will be read at a much lower rate than for new users, so the budget should be harsher.
Applying it
- Hard-cap coach marks per release. Spend them only on a step that would fail the current task if untaught.
- Do not turn the new-feature list into a first-run queue of bubbles.
- If empty state or inline copy can teach it, do not promote it to an interruption.
- How to check: count how many marks are dismissed inside a readable duration. If from mark N onward almost all are dismissed, keep the budget below N and delete the ones that were never finished.