A message telling the user of a website or application that something has gone wrong or (just as important) right seems like a simple thing. But it’s a product of what-ifs, a tangent of application flow, a piece that often doesn’t get much love when a user interface is built and developed. It is a simple thing, but it is a small thing, easily lost.

There are many challenges to writing a good user message for an application. One is making sure it carries an appropriate tone and fits the proprietor’s consistent voice. Assuming your team or employer is together enough to have a consistent voice, then you need to make sure the text is in the hands of someone who is aware of it; or, conversely, make sure someone aware of voice and tone is aware of the need for the text.

Especially for smaller operations, messages can easily plummet into the gap between knowledge of the need for the message and knowledge of how the message should be phrased.

“You have forgotten your password”

Whether they wind up being written by a speeding developer, or by a tin-eared bureaucrat, messages that fail often fail because the message creator forgets that the user is a person. When confronted by the need for a message, consider: is that text you’re about to write something that you’d ever really say to someone? The all-too-real example in the accompanying image sure isn’t.

“You have forgotten your password.” You think the poor sap who found his way to this password reset page really needs to be reminded of that? The needlessly long message doesn’t get much less roboty from there. It could be so much simpler and straightforward:

“To reset your password, provide your name, birthdate, and work e-mail address. Once the information has been verified, a new password will be e-mailed to you.”

Lay off the terminology and get real

The good news is, at companies that have a strong, deliberate voice, the guidelines defining it probably can only result in this kind of talk. An example is the “Microsoft Windows tone,” which calls out common problems with text in software (of which Microsoft itself has been plenty guilty):

  • Overuse of computer terminology and jargon
  • Inconsistent use of terminology
  • Impenetrable, often unintentionally patronizing messages

To combat these pitfalls, say these guidelines, be user-focused, use real-world language, and be positive. All sound recommendations.

If all else fails, whether because of limited resources, rushed development, or evolving internal standards, should the creation of a message to a user winds up in your bucket, remember who it’s for. Imagine expressing the message to her yourself, and how you’d keep it clear and simple. Then write that down.