Signal the right communication state
A message-sent cue confirms that an outgoing message was submitted. It should be quieter than an incoming alert because the sender is already focused on the action. The sound should also avoid implying delivery if the application only knows that the message was queued locally.
Good fits for this effect
Choose the trigger based on what the audience needs to understand at that moment. These are useful starting points, not rules that every project must follow:
- confirming a chat message was sent
- sending a team command or short status update
- submitting a communication from an in-game terminal
Avoid notification fatigue
Use a small, quick acknowledgement rather than an attention-grabbing alert. If the interface distinguishes queued, sent, and delivered states, avoid using the same sound for all three unless that distinction is unimportant. A repeated send cue should remain comfortable during fast conversation.
Test messages arriving close together
Send several messages rapidly and listen while reading the chat history. Check that the sound does not compete with received-message alerts, and make sure it plays at the correct state transition rather than on a failed send attempt.
Preview the preset above and adjust one parameter at a time. Keep a change only if it improves the effect in its intended context; more volume, more duration, or a more dramatic tone is not automatically better.
Frequently asked questions
Should MessageSend sound the same as MessageReceive?
Usually a quieter, less attention-demanding cue is better for sending. Incoming messages ask the user to notice something new; sent feedback mainly confirms the user’s own action.