300 m
The delivery team
Errors are the design users remember
Users do not remember the colour of the header. They remember the day the form rejected their submission with a message saying an unexpected error occurred. Error messages are interface design, and in most enterprise systems they are written last, by whoever wrote the validation rule, in the language of the database rather than the person at the keyboard.
Make error copy part of the definition of done. Every validation rule and every handled exception needs a message that says what went wrong, what the user can do about it, and who to contact if they cannot. Designers should review them. Support teams should be asked which ones generate the most calls, then those get rewritten first.
Ground
The code
Separate the message from the error
In code, keep the user message and the technical detail apart. The user gets a clear sentence and a reference number they can quote to support. The log gets the stack trace, the record Id and the raw integration response. Custom labels keep the wording reviewable and translatable without anyone touching the Apex that throws it.
try {
OrderService.getInstance().submit(orderId);
} catch (OrderService.CreditCheckException e) {
String ref = Logger.error(e, orderId);
throw new AuraHandledException(
String.format(Label.Order_Credit_Check_Failed, new List<String>{ ref })
);
}Test the messages as well as the logic. A unit test that asserts the user sees the right label and reference, rather than the raw exception text, is cheap insurance against the next refactor. It also means the words on the screen are treated like behaviour, which is exactly what they are.
