Notification preferences that reduce noise

Separate action requests from informational updates and give people useful control over delivery.

Person setting a phone aside beside a notification preferences panel.

A notification should earn the interruption it creates. When every small change generates a message, people learn to ignore the channel, including the events that require action. Design notifications around the recipient's responsibility and the urgency of the next step. A useful preference screen then gives people control over optional information without hiding the communications needed to operate the service.

Classify the reason for each message

Imagine a Bendigo design agency using a project portal. A request to approve artwork needs an action, a comment on an archived project may be informational and a weekly summary can combine several low-urgency changes. List the events currently producing messages and identify the intended recipient and response. Avoid notifying everyone attached to a project simply because that is easy to implement. If a message asks someone to act, include the relevant record, the requested decision and any agreed timing, with a link that leads directly to the task.

Offer understandable preference controls

Use categories that match a person's experience, such as approval requests or project updates, rather than internal event names. W3C's forms guidance supports clear labels, grouped controls and understandable feedback; apply those principles to the preference screen. Explain which settings are optional and any messages that follow a different rule, according to the business's confirmed requirements. Show where notifications will be delivered. If changing a preference affects several connected tools, communicate the scope instead of implying that one switch governs every communication the business sends.

Design digests and reminders deliberately

A digest can reduce interruption, but only if its timing suits the work and its contents remain actionable. An approval due before lunch should not first appear in tomorrow's summary. Reminders should stop when the task is completed or reassigned, and should not multiply indefinitely because a status failed to update. Define how repeated related events are grouped. Keep a useful in-application record so someone who misses an email can still find outstanding work. The notification is a route to the task; it should not be the only place the task exists.

Review a realistic week of events

Create a fictional week's activity and preview the messages one staff member would receive. Remove duplicates, combine low-value updates and check that urgent tasks remain visible. Your notification catalogue should record:

  • The event, recipient and intended action or awareness.
  • The delivery channel, timing and available preference.
  • The condition that stops reminders or removes an item from a digest.
  • Where the underlying task remains accessible if the message is missed.

Further reading

Discuss your software project with 110s

Related Insight