In the context of a web app, which makes for a better User Experience: using copy that states the facts as simply as possible or copy that speaks in casual language, yet could end up being more wordy?

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

Example 1

  • Short and Simple: OPEN

  • Casual: OPEN your document

Example 2

  • Short and Simple: Error: Unable to send. TRY AGAIN

  • Casual: Oops! We were unable to send your message. Would you like to TRY AGAIN?

Example 3

  • Short and Simple: CANCEL, SAVE, CLOSE

  • Casual: Would you like to SAVE this first or CLOSE without saving? Nevermind, take me BACK.

I gave 3 examples, but there are others. Short and simple is nice and to the point, but casual language can help users understand and gain clarity with the small penalty of possibly being more wordy.

Followup Questions:

  1. Is casual text better most of the time?

  2. When should you use one way over the other?

  3. Are there any studies that have been conducted on this subject?

  • 1
    A side issue that shouldn't be ignored is reading speed, which can be as high as 1200 words per minute or as slow as 50. And, there isn't always a correlation with intelligence.
    – Bevan
    Commented Apr 26, 2011 at 19:05
  • 1
    I'm not sure I'd call those 'casual' as much as 'context centric'. Which is always better IMHO.
    – DA01
    Commented Apr 28, 2011 at 15:11

7 Answers 7


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.

  • Is there any case where casual language can be used for a broad general audience?
    – jonshariat
    Commented Apr 26, 2011 at 19:51
  • 2
    Most definatley! I'm in favor of a casual language in applications where context admits it. When I design, I try as hard as I can to use a less strict language. So an application which have a broader audience, still could use a casual language. It could even be a competitive advantage. If you have two different online bookstores, one with casual and one with formal language - the average user (which does not exist, btw) would probably have a better experience from natural language. Better experience = more sales! It takes more effort, but it's worth it. Commented Apr 26, 2011 at 20:07
  • Awesome, do you also by any chance know of a study on the subject you could link me to?
    – jonshariat
    Commented Apr 26, 2011 at 20:09
  • 1
    Unfortunately not... I've tried different search strings on Google Scholar using combinations of informal, formal, casual, natural, language and "user experience" but found nothing useful. But I'm pretty confident it has been studied - I just don't know where to find it... Commented Apr 26, 2011 at 20:21
  • I think the difficult thing is: to be as clear when wording informally. Mailchimp communicates very informally, but sometimes at expense of the facts behind it.
    – giraff
    Commented Aug 15, 2011 at 19:19

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:


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.

  • But if the dialoge is casual, they are much more inclined to read it because of its tone is similar to their interactions online.
    – jonshariat
    Commented Apr 26, 2011 at 21:27
  • 3
    @jonshariat: Joel wasn't kidding when he wrote "In fact, users don't read anything." Re-read the Juno "Confirm Exit" part. The tone doesn't matter when users don't even read your single line of text.
    – MSalters
    Commented Apr 28, 2011 at 14:55
  • @MSalters Thanks for the clarification. I still feel that it istn true. Users have to read SOMETHING to make a choice right? They read Cancel and OK. When it comes to the user having to make a choice, they read. THoughts?
    – jonshariat
    Commented Apr 28, 2011 at 16:08
  • 2
    @jonshariat: We all wish that would be true. But users that see "Cancel" will hit cancel (or the escape button), unless they expect that dialog - and when they do expect the dialog, they don't read it either.
    – MSalters
    Commented Apr 29, 2011 at 7:01

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,


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.


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!

  • 3
    A prime example of this is on the captcha page for posting on UX Exchange. Instead of saying "please type what you see in the image below..." it instead says "Hello fellow robot" and the button says "I'm a human being!" rather than Enter. Brilliant! Commented Apr 29, 2011 at 15:33

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.

  • 1
    Instead of "Cancel and continue editing.", why not just "continue editing?" It's the choice for people who end up accidentily in that dialog, and by saying "cancel" you make them think "Cancel what?".
    – MSalters
    Commented Apr 28, 2011 at 14:58
  • @MSalters good point. "Cancel" isn't needed.
    – bendur
    Commented Apr 28, 2011 at 15:04

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:


  • 2
    Scott, you've not really given us an answer to the question, you've deferred the answer off to somewhere else. Can you provide some summary information about that link and leave the link as the citation? If that link goes down then this answer would not be of any use anymore.
    – JonW
    Commented Mar 12, 2013 at 15:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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