Error microcopy that never blames the user
You entered an invalid date and Invalid input are both common and both wrong. How to write errors that tell the truth about what happened and what to do next.
An error message has three jobs: say what happened, say whether it is the user's problem or yours, and say what happens next. Most errors do the first badly and skip the other two.
Attribution
You entered an invalid date assigns blame to someone who was trying to book something. That date is outside the booking window describes the constraint. Both are true; only one is useful. Where the failure is genuinely yours, say so plainly: we could not save that, the connection dropped.
Recovery
Every error needs a next step, and try again is only a next step when retrying is likely to work. If it is not, say what would work: a different card, wait and retry, contact support with this reference. If the user cannot fix it, do not imply they can.
What to leave out
Error codes in user-facing copy, unless the user is going to quote them to support. Something went wrong with no qualifier. Excessive apology — one is acknowledgement, three is panic. And jokes: the second time a user sees the joke, it is the second time the thing failed.
EmptyKit's blame lint catches the constructions that put the user in the subject position of a failure they did not cause.