The Alert You Never Saw Was a Design Decision

A quieter interface can still be a worse product

Digital products have spent years getting good at demanding attention. New messages, recent activity, special offers and status changes can all arrive through the same notification channel. A designer may see a crowded inbox and conclude that fewer alerts would make the experience better.

GOODSCOOL JOURNAL / FIG. 01

Read full figure transcript

FIELD STUDY / 01 GOODScool · ORIGINAL TEACHING EXAMPLE A quiet assistant still makes choices A / VISIBLE SUMMARY ASSISTANT / TODAY All caught up 2 low-priority items grouped Only the digest is visible. The interface is quiet. The filtering rule is not inspectable. B / INSPECTABLE QUIET ASSISTANT / ROUTING HISTORY Decision deferred 10:42 Possible account-access problem Route: review at next checkpoint · Reason: rule-based grouping · User option: inspect Makes the decision and recovery route visible. Illustrative two-state notification comparison. Suppressed or deferred information is a product decision that may need a review path. These are fictional UI states; no production notification engine or model accuracy is represented.

Often, fewer interruptions would help. In a 2008 controlled study of interrupted work, Gloria Mark, Daniela Gudith and Ulrich Klocke found that participants completed interrupted tasks faster without a measured drop in quality, but experienced greater stress, frustration, time pressure and effort. That finding is more nuanced than a claim that every interruption simply makes people less productive. Its practical lesson is that interruption has a human cost that raw task-completion time may miss. Mark and colleagues, CHI 2008.

But the opposite cost matters, too. Imagine a system that prevents nearly every interruption by holding back a security warning or an urgent accessibility-related request. A beautifully calm dashboard can conceal a serious failure.

There are two mistakes to design against:

• False escalation: the system interrupts someone for something that could have waited.
• False reassurance: the system decides something can wait when the delay matters.

Neither can be eliminated merely by asking an AI model to be “more selective.” The team has to define what counts as consequential, for whom, and under what circumstances. A missed deadline and an unimportant promotion are not interchangeable just because both arrived as text.

We already design different kinds of interruption

This is not an entirely new field invented by generative AI. Apple's Human Interface Guidelines for notifications distinguish passive, active, time-sensitive and critical interruption levels, and explicitly caution developers not to exaggerate urgency. These are platform-defined delivery categories, not GoodScool's proposed framework.

Apple also documents Reduce Interruptions Focus, which uses Apple Intelligence to prioritize notifications that may need immediate attention while silencing less important ones. It remains configurable by the user, and availability varies by device, language and region. The documentation establishes the feature's intended behavior, not its real-world error rate or a guarantee that it always identifies the right alert.

The important shift is not the existence of a smarter notification. It is that more products can now interpret messy content before deciding how to present it. A conventional rule can treat a particular event as urgent. An AI system might infer urgency from a message, document or pattern across multiple sources. That flexibility is useful; it also introduces classification error and makes the reasoning harder to inspect.

A message can be new without being urgent. It can be urgent without containing dramatic language. It can be important to one person and irrelevant to another. Designing the screen that displays the alert is only the final step. The harder decisions happen before anything appears.

The missing interface is the decision trail

Suppose your assistant says, “Nothing needs attention.” What does that statement mean?

It might mean nothing arrived. Or that several things arrived but were categorized as routine. Or that the system could not retrieve one of its sources. Or that an item looked borderline but fell below the configured threshold. Those states may look identical in a clean interface, yet they deserve different levels of trust.

GOODSCOOL JOURNAL / FIG. 02

Read full figure transcript

FIELD STUDY / 02 GOODScool · ORIGINAL TEACHING EXAMPLE The decision trail needs five fields WHAT Account-access warning ROUTE Checkpoint review WHY Matched a configured grouping rule WHEN 10:42 · example timestamp RECOURSE Inspect event · change rule · report incorrect routing A proposed review record, not an observed AI decision. Keep the rationale and recovery choice visible in the actual product.

Silence is not evidence that everything is fine. For an AI product, silence needs a definition: what was checked, what was not checked, what was delayed and whether the result is complete enough to act on.

A useful design pattern is a reviewable decision trail. Not a wall of technical logs, and not a reassuring explanation invented after the fact. Give people a plain-language record of material choices: the item, its destination, the rule or reason that governed it, when it will reappear and how to correct the decision. Where sensitive information is involved, access and retention must respect privacy and security requirements.

Google's People + AI Research guidance emphasizes appropriate user control, calibrated trust, feedback and support when AI systems make mistakes. The NIST AI Risk Management Framework similarly calls for documented processes for human oversight and for identifying the possible impacts of AI systems. Neither source proves that one particular notification design is best. Both support a more defensible principle: users and operators need ways to understand and contest consequential automated decisions.

Give each signal a route, not just a rank

Ranking alerts from most important to least important is a useful start, but a list still leaves the central interaction unanswered: when should each item reach a person?

For a product team, we propose an attention-routing card with four possible destinations. This is an original teaching framework, not an industry standard or a tested algorithm.

These routes are not substitutes for legally required notices, emergency-warning rules or established platform permissions. In high-risk domains, escalation policies require domain expertise and independent validation.

GOODSCOOL JOURNAL / FIG. 03

Read full figure transcript

FIG. 01 / EXPLAINER ILLUSTRATIVE / ORIGINAL GOODScool ARTWORK Figure 1. A proposed routing model: the assistant considers the consequence of delay, uncertainty and the user's context before deciding how to present a signal. This diagram represents a design framework, not measured model performance.

The card forces a product team to consider three things that a generic “priority score” can obscure.

First, the consequence of waiting. If a transaction has failed and the customer needs to complete a time-sensitive purchase, delay may matter. If a weekly report is ready, the information can likely wait. Do not use message sentiment alone as a proxy for business or user impact.

Second, the evidence and uncertainty. A single ambiguous complaint may warrant review rather than an automatic high-severity incident. Multiple independent signals can change the assessment. If the potential harm is severe and the classification is uncertain, quiet suppression may be the wrong default; an appropriately qualified escalation or human review may be safer.

Third, the person's context and choices. Someone in a focus session may want a digest. The same person awaiting an account-security decision may prefer an immediate alert. User preferences matter, but they do not absolve a service of duties it has already promised or is legally required to fulfill.

The best route is a product decision under uncertainty. It cannot be inferred from how polished the summary sounds.

A useful counterargument: sometimes more information is exactly what users need

A team designing for restraint can become paternalistic. It may decide to hide messages “for your own good,” remove detail to create a tidy inbox or rank information according to its own commercial goals. What feels like assistance to the product may feel like lost control to the person using it.

A growth team may want an agent to surface a promotion. A customer may have asked to hear only about delivery problems. A manager may prefer more operational detail than an automated digest provides. An investigator may need a full record rather than a summary. These goals conflict, and interface minimalism does not settle the dispute.

This is why less attention demanded cannot be the only success metric. A system can reduce notifications by becoming less helpful. It can increase apparent efficiency by moving work into hidden queues. Or it can earn trust by handling genuinely low-stakes noise while leaving consequential choices accessible.

What should the team measure instead? In a real pilot, evaluate interruptions users considered unnecessary and important items users found too late. Review time-to-action for genuinely urgent cases, corrections to routing decisions, opt-outs, and whether people can find the originals behind a summary. Pair event data with interviews or usability sessions. Do not treat a dramatic reduction in alerts as a win without examining what disappeared.

The 20-minute design review that catches the missing alert

You can apply the routing card to a product before adding an AI agent. Choose one notification or automated summary your team already plans to ship. Bring a designer, PM and someone who understands the consequences of missing the information.

Write down the user job the alert serves. Then review three imagined cases: a harmless update, an ambiguous item and a consequential exception. For each, specify the default route, the cost of an incorrect route, what the user can inspect, and who is authorized to change the rule.

Finally, test a situation where the system goes quiet for the wrong reason: a disconnected data source, a misclassification, a stale summary or a user preference that no longer fits. What will the interface say? Who will notice? How does the person get the original message back?

The exercise is deliberately small. It does not replace incident testing or an AI-risk assessment. It does reveal whether the team has designed a decision policy or merely a prettier container for model output.

A good assistant must know how to be quiet—and how to explain its quiet

Return to the fictional online store. The problem was not simply that the AI sent too few alerts. It was that a consequential classification became invisible. The team had no reason to question the quiet until the business outcome made it impossible to ignore.

A better product might have escalated the checkout signal, shown uncertainty to a responsible operator, or exposed a reviewable queue for ambiguous payment issues. Which approach works would depend on evidence, operational constraints and testing. The design responsibility is to make that choice explicit and recoverable.

AI can read far more material than one person can. That does not give it an automatic right to decide what a person will never see. The quality of an AI assistant is visible not only in what it brings forward, but in how safely a human can question what it left behind.