H5.10.2quiet hours with urgency bypassdesignresearch

Quiet hours must still let high-urgency items through

Aliases: quiet hours bypass · send-side silence · overnight exception

What it is

Product quiet hours (night, meetings, a user-set quiet clock) hold deferrable sends by default, but high urgency must pierce: an account sign-in, a code about to die, physical security. The window is send-policy quiet, not a zeroing of the consequence matrix. If quiet is a slab, people either dare not turn it on, or turn it off forever after a true miss, and the policy exists only as a name.

This is not the same layer as user-initiated focus. Focus holes are objects the user named (stars, their own alarms). Quiet-hour holes are tiers the product scored on consequence × latency. Sender-declared "urgent" does not automatically pierce.

Why it happens

The value of quiet is predictable non-ringing. People accept "no pitches or likes in this window" only if irreversible loss can still get in. With no pierce, quiet is an information vacuum and risk shifts onto the user. If pierce is too wide, quiet decays into ordinary daytime. Width should be clamped by the consequence matrix: only types high on both axes take sound; the rest flush after the window.

Pierce has to be recognizable on the card, or people will think quiet is broken and not use it next time. What to recognize is why this rang at night, not another line of campaign copy.

Studying it

Set a quiet window, inject low- and high-urgency arrivals, and compare pierce versus total block: days the window stays on, missed high-consequence items, whether low urgency still sounds.

Independent variables: pierce rule (total block / consequence tier / sender-declared urgent), window length, whether pierce names a reason. Dependent variables: window retention, high-consequence misses, low-urgency arrivals inside the window, disable because "a promo woke me."

Labs struggle to manufacture a real miss. In logs, after the first miss during quiet, does that user still enable the window. Pierce count is not success—pierce should be rare; success is the window still used and high-consequence still received.

Where it stops holding

If someone sets quiet to "including security, don't," the product should confirm rather than silently refuse, though legally required alerts may still sit outside that choice. When traveling, the window must follow the local clock or pierce happens on the wrong night. Meeting quiet bound to a calendar should still pierce by consequence, not because the event is titled "urgent" and a promo sneaks in.

Applying it

  • Quiet hours should suppress marketing, social, and achievements by default; security and time-critical transactions pierce by the consequence matrix, with sound or at least a highlighted shade item.
  • Sender flags must not be the sole pierce condition.
  • Mark pierced cards as "quiet-hours exception" with a reason.
  • Verify with one quiet night, one promo, and one unfamiliar sign-in. The promo should not sound; the sign-in should arrive. If both are silent or both ring, the policy is either dead or holed on the wrong axis.

Related

  • Within the group: H5.10.1 Caps should be per type, not one shared budget · H5.10.3 Queue pending items into one send window instead of dripping them · H5.10.4 The cap's reset period must be visible
  • Adjacent: H5.03 Do not disturb and focus · H5.01 Urgency grading · H5.07 Push frequency
  • Search terms: quiet hours · urgency bypass · send-side silence

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/H5.10.2