A shop notice appears at a moment when somebody is trying to do something. They may be applying a voucher, changing a quantity or choosing delivery. The message should help them complete that task rather than interrupt it with an unexplained warning.
I review a notice as a small piece of interface: what triggered it, what it says, where it appears and what the shopper can do next. Styling matters, but useful wording and a sensible recovery route matter first.
Name the condition precisely
“This code cannot be applied” leaves a shopper guessing. If the system knows the reason, explain it: the code has expired, the basket does not contain an eligible item or the minimum spend has not been reached. Do not claim a precise cause when the system only knows the request failed.
I also separate warnings from ordinary information. A reminder about an optional benefit should not look like a failed payment. If every message uses the same urgent treatment, the genuinely important ones have to compete with routine promotions.
For each notice, I write a plain sentence describing the shopper’s current state. Then I add the smallest useful action: change the quantity, choose another delivery option, remove the code or contact the shop. The action should be possible from where the message appears.
Put the explanation near the decision
A message at the top of a long page can be easy to miss after a control changes near the bottom. I check where the shopper is looking when the notice appears, especially on a phone. They should not need to search the whole page to discover why a button did not do what they expected.
At the same time, repeating the same warning beside every field creates noise. A general explanation can sit in a clear summary, while a specific field problem belongs with that field. The two should agree and avoid making the person correct the same apparent problem twice.
I do not depend only on colour or an icon to communicate meaning. The text needs to identify the issue. During implementation, I also check that dynamic notices are exposed appropriately to assistive technology; a visually obvious update can otherwise be silent to somebody navigating differently.
Keep the shopper’s work intact
A rejected voucher should not empty the basket. A delivery calculation problem should not erase the address that was just entered. I test what survives the error, including selected options and quantities, because recovery becomes much harder when unrelated choices disappear.
Stale messages need attention too. Once the shopper fixes the condition, the warning should stop describing the old basket. A notice that remains after successful correction teaches people to ignore the interface.
For uncertain payment or order states, wording needs particular care. Do not invite a fresh payment merely because the browser failed to show a confirmation. The system should establish the order state and offer the appropriate recovery route.
Keep a notice inventory
I make a short list of common notices and deliberately trigger them on a test shop: invalid voucher, unavailable quantity, missing delivery choice and an ordinary successful update. Each gets a check for wording, placement and recovery.
Ask somebody unfamiliar with the shop to explain the next step after reading each message. If they need you to translate it, improve the notice. The result should be a shop that remains understandable when something goes wrong, with the same care given to recovery as to the normal purchase journey.