H2.10.4queue new-feature hints when budget is spentdesign

When the budget is spent, new-feature hints wait in queue

Aliases: launch hint queue · waitlist coaching · no forced insert

What it is

After slots are gone, automatic hints for a newly shipped feature should enter a queue and wait for the next allowance, not jump into the current session because “it’s new.” Forced insert puts the release calendar above channel health, the most common organizational excuse for over-firing. Queuing does not hide the feature: the entry stays as visible as it should be; teaching speaks when a slot exists. This is policy at budget exhaustion, not which of two ready hints displaces the other at runtime.

Why it happens

Shipping creates an internal deadline, and deadlines override dose rules already on paper. The insert is always framed as an exception: “just this once,” “a core feature.” Once exceptions exist, every launch is this once, and the budget is a fiction. Queuing turns the exception into waiting: the feature is already discoverable in the UI; the hint is an optional accelerator. While it waits, the channel recovers, and the next speaking slot is read more than another shot at the fatigue point. The queue also needs expiry: if three weeks pass without a slot and the entry has already been used, cancel the hint rather than let debt dump on one day. Another form of insert is widening the audience (shouting “new” at people who already use it)—that is not a queue, it is using coverage to escape the cap.

Where it stops holding

A notice that a safety fix must be seen at once (“old share links are dead”) is not a new-feature promo; it belongs on the error/change channel and may interrupt. A time-boxed capability that is meaningless after the window should have slots reserved before ship, not inserted after exhaustion. A user who opens “see what’s new” is opening the queue themselves and does not spend the automatic cap. Hints that sit at the tail forever and never win a slot should be deleted or turned into silent copy at the entry, so the queue does not become a junkyard.

Applying it

  • When the cap is spent, new automatic feature hints only join the queue; they do not fire in the current session. Ship day is not a cut permit.
  • The queue dequeues by the existing priority; people who already mastered or discovered the feature are cancelled out.
  • Give queue items a time to live; on expiry without playback, convert to silent copy by the entry—do not dump them together on one day.
  • Verify in a launch week whether users whose budget is already full still receive that feature’s automatic hint. If they do, it was an insert. Then check that the queue later dequeues in order, not as a dump.

Related

  • Within the group: H2.10.1 Shared hint budgets need a single priority order across teams · H2.10.2 High-value hints should displace low-value ones, not stack on them · H2.10.3 Hint fatigue can be read from ignore and dismiss rates
  • Adjacent: H2.05 Feature Discovery · H2.03 Progressive onboarding · H5.10 Push frequency and quiet hours
  • Search terms: hint queue · launch insert · budget exhaustion

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/H2.10.4