Manual do-not-disturb windows compensate for limited automatic boundary detection

What it is

For a system to pick a good moment to interrupt on its own, it first has to reliably tell whether the user is currently at a task boundary — and that is not something it currently does well. Activity spanning multiple apps and devices is hard to fully sense, and a task's own hierarchical structure isn't always recoverable from external signals like app switches or click sequences. A do-not-disturb (DND) window sidesteps that inference problem: instead of having the system guess where the boundary is, the user simply blocks out a stretch of time and declares "nothing in this window counts as a suitable moment to interrupt." This is not an upgraded form of boundary detection — it is a substitute for use when detection isn't good enough.

Why it happens

Automatic boundary detection is an inference: the input signals are noisy, the task structure itself can be opaque, and the probability of getting it wrong is never zero. A DND window turns "when not to interrupt" from a problem requiring continuous inference into a problem the user declares once, which the system only needs to check against a clock — the judgment collapses from "understand what the user is doing" down to "look up a schedule." The tradeoff is precision: a declared window is a coarse block of time that does not track the user's actual task rhythm. Inside the window, the user may already have finished their current work and be sitting at a genuine boundary, yet the DND setting still blocks everything anyway; the moment the window ends, the system resumes normal delivery even if the user is still deep inside some task. Trading precision for reliability is the core mechanism here.

Studying it

Studies comparing automatic boundary detection against manual DND settings typically measure interruption appropriateness under both conditions — judged either by a third party or by users' own after-the-fact rating of whether that moment was really a good time to be interrupted — while also collecting trust in each mechanism and actual adoption rates.

Common independent variable: automatic detection / manual window / a combination of both. Common dependent variables: the proportion of interruptions that land on a genuine boundary (accuracy), users' trust rating of the system's judgment, and real feature adoption and retention.

Methodological caveat: how much users trust automatic detection shapes whether they're willing to hand the decision to the system at all — even when detection's objective accuracy is decent, users may still lean on a manual window simply because it's something they control. Studies here need to measure "how accurate is it" and "how much do users trust it" separately, since the two often move independently.

Where it stops holding

• A DND window is a coarse temporal block, not a fine-grained fix on task boundaries; it solves the problem of the system guessing badly at where the boundary is, not the problem of making boundary judgment more accurate.
• If a user's actual work rhythm diverges sharply from the pre-set window — irregular schedules, tasks that shift on short notice — the manual window itself goes stale and needs ongoing upkeep, and that upkeep has a real cost.
• This entry does not cover how automatic detection technology itself might be improved; it only addresses why and where a manual window exists as a substitute.

Applying it

• In situations where reliable boundary detection isn't achievable, offer a simple, user-controlled DND window as the baseline feature — don't wait for automatic detection to be good enough before shipping any interruption management at all.
• Design manual windows and automatic detection to complement rather than exclude each other: if the system detects a high-confidence genuine boundary inside a DND window, it can surface a batch of already-accumulated low-urgency information at that real boundary without violating the do-not-disturb intent, rather than holding everything until the window simply ends.
• Log the mismatch between a user's set window and their actual activity pattern, and use that data to suggest default windows that better fit their rhythm, instead of leaving users to hand-tune from a blank slate.
• Verification: compare the same users under a plain manual-window setting versus "manual window plus boundary-aware surfacing," measuring interruption complaints and perceived delivery delay both inside and outside the window, to confirm that adding boundary awareness actually improves the experience rather than just adding complexity.

Related

• Same group: A5.14.1 Breakpoints come in coarse and fine grain, and the subtask boundary is only one coarser level · A5.14.2 Fine boundaries occur earlier but protect less · A5.14.3 Batching notifications to the next boundary costs less overall than immediate delivery
• Adjacent: A5.08 Interruption cost and task resumption
• Search terms: do not disturb · manual override · opportune moment for interruption · interruptibility prediction