1

In an enterprise application's bit editor function, we want our users to be able to import configuration files.

The files are supposed to only contain binary content - "0" and "1"s - but I initially had the error message read "Content of file must be binary", but the pushback was that the users may mistake that to mean that it must be a .bin file.

Could I have some assistance in better messaging on this?

Thank you!

1
  • 1
    I'm confused. Unless you are using some really esoteric hardware, every file on your system is binary. That's how computers store information. – T.E.D. Aug 15 '17 at 20:41
4

Ben Rowe has some good thoughts on error messages. Specifically, he states that they must have what he calls "The 4 H's:"

  • Human
  • Helpful
  • Humorous
  • Humble

Let's take a moment to think about how these guidelines might help your specific error messages.

1. Human

The number one rule is to make sure your error messages sound like they’ve been written for humans.

The scariest word in your error message is also the one that the debate hinges on: binary. This is a distinctly non-human word, as it's almost universally associated with computer language and coding. It's the definition of jargon, and we'll want to make sure our error message is jargon-free. We'll need to get rid of "binary" in our error message.

2. Helpful

OK, so your error message is readable. But is it helpful?

Too often, we get stuck in the trap of writing error messages that are descriptive of the technical problem, but give no guidance on how that problem might be fixed. It neither explains clearly what went wrong, nor how the user can recover-- two crucial aspects of proper error message writing. We'll want to provide a better error description and recovery directions in our final message.

3. Humorous

A short sprinkling of humour is often a great way to diffuse the frustration of an error. Keeping your tone light-hearted can help to keep the user on-side—especially if this suits the tone of your brand.

I'm personally of the opinion that many brands don't get the value of humor-- especially in enterprise-level products for business environments. Whether at work or play, we all enjoy a little humor.

Still, many of the boss types will be resistant to adding a laugh to your message. We'll keep things straight laced for now, but consider if having a laugh may be valuable for your UX.

4. Humble

Perhaps your user is at fault. Maybe your instructions just weren’t clear enough. You know what? It doesn’t really matter.

What does matter is how you deal with the situation.

It’s always better to assume that your site or app is at fault, not your user. You must never imply that the user made a mistake. Always be humble.

In short, say you're sorry-- and mean it.

Our Re-Written Error Message

We've identified a few things that will help us write a better error message:

  • Remove the technical jargon "binary" from our error message.
  • Provide a human-readable description of the error encountered.
  • Provide recovery instructions.
  • Apologize for the issue.

So what might an error message like that look like? Here's an example:

Sorry, but it appears the configuration file contains characters other than 1's and 0's.

To resolve the issue:

  • Please check that the configuration file provided contains only 1's and 0's.
  • If the problem continues, please contact our Support team at 1-800-xxxx.

Your final error message will have other considerations to take into account, such as placement, real estate, and size restraints, when you write it. At the very least, however, it should hold to these basic principles.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.