Once sound is off, other channels must carry what was muted

What it is

Turning off a class of sound transfers responsibility for receiving it. Users who mute a category usually still want to know when something in it truly matters; the design obligation is then to route those events through another channel, or, when no route exists, to state plainly that the information will no longer be pushed.

Why it happens

Muting is an irreversible allocation of attention: once the channel is removed, events do not find their own way. If the design assumes "muted means unwanted," events that are muted yet important vanish silently until a user discovers they never arrived. Whether transfer is needed depends on consequence: low-stakes events can leave only an inspectable record, while high-stakes ones need an active substitute channel. Transfer also costs something—the visual channel clogs easily—so not every sound can simply move to the screen.

Studying it

Measure arrival and awareness after muting: mute one category, then trigger its critical and non-critical events, and record whether users learn of them, how quickly, and whether they believe notifications still occur. Measures include arrival rate, delay, and trust ratings. Distinguish user-initiated muting, which carries explicit intent, from system-default muting, where responsibility sits wholly with the design.

Where it stops holding

When users state that a piece of information is not wanted at all, a forced substitute channel becomes harassment; respecting the choice and keeping an inspectable record is correct. If no suitable channel exists, the design should state the consequence explicitly rather than dropping events quietly. Transfer rules must also agree with degradation rules for silence, so one event is not handled differently depending on the entry point.

Applying it

• For every mutable sound class, state where it goes once off: active delivery on another channel, an inspectable record only, or no further delivery.
• Communicate that destination at the moment of muting, so the decision rests on known consequences.
• Guarantee at least one substitute channel for high-stakes events and verify it still works under common user settings.
• Verification: mute a category, trigger one of its events, and check handling against the stated destination, then ask users whether they knew it happened.

Related

• Within the group: D2.11.1 Users need to control sound by category rather than all-or-nothing · D2.11.3 Category control needs its own entry point, independent of system mute
• Adjacent: D2.05.1 Critical information must move to another channel when sound is muted · D2.05.3 Degradation paths must be predefined
• Search terms: mute consequences · notification routing · channel transfer