04 / NOTIFICATION DESIGN
Send a reason
to return.
Connect transactional messages to a specific destination and a durable record of the exchange.
Define what the message changes
A notification earns its place when it helps someone understand a meaningful event or take a useful action. A new document, a clarification request, and a completed review have different implications. Sending the same generic “there is an update” message for all three removes that distinction.
Notification planning starts with an event and a recipient. It then asks what the person needs to know outside the portal, which details are appropriate for that channel, and what they should see after opening the link. The email and destination are one experience.
Land at the relevant context
A link should lead to the item that caused the message, rather than requiring the client to search a dashboard. If authentication interrupts the journey, the intended destination should be preserved when the system can do so safely. An expired or withdrawn item needs a meaningful explanation.
The destination should still make sense when opened later. A response may already have been received or the document may have been superseded. In those situations, show the current context and the earlier event together instead of inviting an action that is no longer useful.
Separate delivery from business progress
An email being queued is not the same as a client reading a request. A message being delivered is not evidence that the requested work has been completed. The interface and staff view should use language that reflects the information the system actually has.
Projects can define which events warrant an immediate message and which belong in a summary or only in the portal history. Preferences should be understandable, and essential service communications need an explicitly agreed policy. Avoid treating every recorded event as a reason to interrupt someone.
Design the fallback as part of the flow
A wrong address, an undeliverable message, or an expired invitation should have an owner and a recovery path. The team may need a visible exception list or a manual follow-up step. Retrying silently without a limit can hide the underlying problem.
Possible scope includes event definitions, message content, destination behavior, delivery integration, and test examples. Email delivery requires an actual provider and appropriate domain setup; a visual template alone cannot guarantee receipt. The project should state who operates that provider and monitors failures.