Simplified facts or casual talk, which makes a better UX?

Question

Which makes for a better User Experience: using copy that states the facts as simply as possible, or copy that speaks in casual language. (Context: a Web App )

Here are 3 examples as the answer may be different depending on the situation:

Example 1:

• Facts: OPEN

• Casual: OPEN your document

Example 2:

• Facts: Error: Unable to send. TRY AGAIN

• Casual: Ops, we were unable to send your message. Would you like to TRY AGAIN

Example 3:

• Facts: CANCEL, SAVE, CLOSE

• Casual: Would you like to SAVE this first? or do you want to just CLOSE it with out saving? Never mind, take me BACK.

I gave 3 examples, but there are other cases. Facts are nice and to the point, but casual language can help users understand and gain clarity but adds more text.

1. Is casual text better most of the time?

2. When should you use one over the other.

3. Do you know a link to a study on this subject?

Answer 1

It depends on the application itself. Is it in a formal context the language and instructions should be formal. Most users would not trust a Bank or Government who said: "Dude, you didn't get your social security number right. Please enter a correct one". It's an extreme case, I know. On the other hand, some user would maybe like the favourite online T-shirt store to use casual and less formal language on instructions.

It also depends on the intended user. If it's everyone one should be careful on instructions and error messages, but if the intended user is narrowed down to poker playing young men up to 30, it would be much easier. Then one should use the language they use in daily life. Context and Intended user is what determines which kind of language to use.

Answer 2

I wouldn't say that either is better for user experience. It all depends on the type of application you are creating.

For professional services, I use professional language. If a law firm has a client-facing billing site for their clients, they would not want their clients to see "Oops, we can't find a time sheet for that date!" It sounds very unprofessional.

On the other hand, it is appropriate to use casual and fun language on sites that are meant to be casual and fun. Twitter is just a simple web application used by an extremely diverse crowd during their free time. Casual language works great there.

That said, I think it also depends on the specific context of the message/function/action. People can easily scan for a button called "Save" or "Cancel," and users know what these buttons mean. There's not always a need to make these actions more casual, as it may just create clutter and make the buttons less readily identifiable.

Answer 3

The problem with some of the casual language examples is how the number of words increases, which is generally a 'bad thing'.

Here's Joel Spolsky from 2000 on the topic:

http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html

In fact, users don't read anything.

This may sound a little harsh, but you'll see, when you do usability tests, that there are quite a few users who simply do not read words that you put on the screen. If you pop up an error box of any sort, they simply will not read it. This may be disconcerting to you as a programmer, because you imagine yourself as conducting a dialog with the user. Hey, user! You can't open that file, we don't support that file format!

Still, experience shows that the more words you put on that dialog box, the fewer people will actually read it.

Answer 4

How Big is Your Bucket?

While both Benny and Baa are right, the question is really about "the size of the bucket," not "what's in it." In other words, how much text versus what that text is.

I believe in terse answers (labels), it leaves the UI uncluttered. With a diverse audience, however, there will always be people that need a little more information to understand what's next or what a certain button will do.

I Use Both

I actually use both - a "Fact" on the UI (e.g., Save, Close, Cancel), with a more descriptive hover text ("Click SAVE to save your data and close this form.", "Click CLOSE to close this form without saving your data.", "Click CANCEL to close this dialog box and return to this form. NOTE: Your data is not saved at this point.).

Wait for it... Wait for it...

An important thing about hover text to consider - increase the delay on the hover text so it only pops up if the user really wants it. Otherwise, it's a pain, especially to those who don't need it! How many times have you cursed an application because the hover text covers an important part of the UI? (...ooor maybe that's just a curse I'm burdened with!)

ADA Compliance

By the way, since this is somewhat related. I hope we're all using ADA Compliant design concepts. Using a more verbose "Alt tag" will help the visually impaired (and other physically challenged individuals) "see" the application better.

Here is a checklist that is supposed to be used by designers of government websites. It's a good measuring stick to how user accessible your website or application is.

Best regards,

Answer 5

Casual talk can leave a lasting impression, especially if the tone of the site allows you to be clever and witty with your words. I love it when sites like MailChimp and others find clever ways of saying things. It really helps to build a positive relationship with the user and can often make them chuckle. We have all seen the same old same old simplified stuff, lets make it interesting and keep 'em coming back!

Answer 6

Like the others have pointed out, your voice should depend on your site's audience.

However, your question really seems to be asking how descriptive you should be with your take action language.

"CANCEL | SAVE | CLOSE" is not too helpful. What's the difference between cancel and close? Does close just close this dialog box?

Far more helpful would be something like "Save and close | Close without saving | Cancel and continue editing."

Also, "We were unable to send your message. Would you like to TRY AGAIN?" is far more user-friendly than "Error. Unable to Send. TRY AGAIN?"

It's always a better user experience to put take action and error handling language into context.

Answer 7

Benny Skogberg answered questions 1 and 2 very well.

To answer your third question, Aarron Walter (Director of User Experience at MailChimp) has written a book on the topic:

http://aarronwalter.com/2011/10/19/designing-for-emotion/