Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

It is almost always a good thing to give status messages to the users. (e.g. "The customer has been added" or "The data has been saved.") But I am asking myself now if I should really always give such messages. Especially for those two cases I am not sure if it is useful give the fact that the changes are highly visible:

  • Changing the language of a website/application
  • Changing the theme/design of a website

What are your thoughts on this? Would you always give a confirmation/status message? Or are there even other situations where you would not print out any messages?

share|improve this question
2  
You wrote: " It is almost always a good thing to give status messages to the users." After reading the first few responses, do you still think so? I don't agree with your opening statement. I find About Face offers good guidance: amazon.com/About-Face-Essentials-Interaction-Design/dp/… –  JeromeR Apr 17 '10 at 1:33
    
You are right. Now from reading all the answers my opening statement is not fully correct anymore. But I am not sure if I should change now the whole question a lot. Since this would make maybe some answers invalid. But I will think of a good rewording. Btw. Thanks for the link. The book looks interesting. –  Raffael Luthiger Apr 17 '10 at 12:02
add comment

9 Answers

You should (almost) always display some feedback on changes. Even in an apparently obvious case like a theme change, it might be nice to tell the user the name of the theme they have selected, in case they selected the wrong one by mistake.

You don't need to display an explicit confirmation message. For example on many websites, when you log in they don't display a confirmation message as such; they simply display your name in the top-right corner ("Logged in as Bennett" or similar). And in Glen's example, navigating to the New Foo screen is an implicit confirmation that the Foo creation succeeded.

As others have mentioned, messages should generally be unobtrusive rather than modal. UXExchange's notifications for comments and badges are a good example. They are there, they are obvious, but the user doesn't need to take action to acknowledge them.

share|improve this answer
    
OK. In this case I have to rewrite my question a little. Because it was about "explicit confirmation messages". About your statement regarding the theme change: Does a user really decide by the name of the theme? Doesn't the user just look at the new theme and decide if it looks nice or not? Isn't in this case the "feedback" the new design/layout etc.? My question is specific to the situations where the feedback is already given in some way. If I should print out an explicit confirmation or not. The second paragraph is giving the answer I was searching for. –  Raffael Luthiger Apr 15 '10 at 16:48
    
You're right; my theme example is a bit of a stretch. That's why I said "it might be nice" rather than "you should". :) –  Bennett McElwee Apr 16 '10 at 4:06
    
I like most of your answer—you don't need to display explicit confirmation message—but it would be nice if the example ("theme name") offered a more clearcut case. –  JeromeR Apr 17 '10 at 1:30
add comment

I actually avoid confirmation messages most of the time, especially in modal form. Anything where the user has to say "OK", doesn't provide much value and they don't read the message anyway.

If you just "created a [foo]" then just navigate the user to the first screen of the new [foo] and let them start working. No need for a message.

Saving data could be a message that is not in the way, like a status message the user doesn't have to interact with.

Generally, the answer is: Don't talk to the user with stuff they already know. Just move forward with what they need next.

share|improve this answer
    
I was more talking about the monologue messages which appear on the new page the user is redirected to after something happened. A (modal) dialogue is something I try to avoid anyway. But the last sentence is the key sentence anyway. :) (At least for me.) –  Raffael Luthiger Apr 14 '10 at 19:20
add comment

Also depends who the intended users are. I work on a couple of sites with an older demographic and testing has shown several times that they prefer quite explicit affirmation of their actions.

The more unsure the user is of their own ability, the more reassurance they tend to need.

share|improve this answer
    
Interesting. I did not think of the older people. But it makes sense. Would they even prefer modal windows over the "embedded" messages? –  Raffael Luthiger Apr 16 '10 at 10:27
1  
Personally (and this isn't actually something I've tested for), I think modal windows can be frustrating. The affirmation of the action just needs to be obvious and reassuring. –  Ali Apr 19 '10 at 7:44
1  
Just thought of a good example - for a long, quite demanding insurance quote form, we introduced a tick next to fields that had been completed correctly. More of a visual affirmation than a message. –  Ali Apr 19 '10 at 7:51
    
Thank you for the comments. This clarified everything some more. –  Raffael Luthiger Apr 21 '10 at 10:56
add comment

I think as much as possible one should avoid explicit messages (users are likely to ignore them anyway once they've seen them a couple of times) and make use of contextual cues, i.e.:

  1. If the application is asynchronous then display a visual indication that the task is being executed, then remove the indicator once it is completed, or display an error if it fails.

  2. Use subtle visual cues to draw attention to whatever has changed - i.e. If the result of the task/action is that something has been added onscreen (i.e. a new user added to the table) then use a temporary fading highlight to draw attention to it, or if it has been removed then fade it out (and possibly shift something up/in to fill its place).

  3. As already suggested by Glen Lipka, if the most common use case is to perform a further action on the thing that resulted from the previous action (e.g. to edit the user's details/permissions/etc) then take the user to that screen/state/etc.

share|improve this answer
    
Regarding 2.: What if the change itself is more than "subtle" visual cue? My question was about situations where the change is highly visible (See my two examples.) Fading would not be possible if the whole theme changes. –  Raffael Luthiger Apr 16 '10 at 12:01
1  
All depends on the context of course, but to generalise, where the change is highly visible/obvious (e.g. your example of changing theme) and results directly from a user-initiated action then no further confirmation is required. However, if a chain of events was triggered (rather than a single action) then it's worth considering whether the interface should inform the user of what events took place as a result of the initiated action. –  MarcusT Apr 19 '10 at 14:00
    
Thank you for the clarification. –  Raffael Luthiger Apr 21 '10 at 10:57
add comment

In the two examples of language and theme change, the change is the confirmation. Confirmation messages help where the activity of the system is opaque or easy to miss. With a language or theme change, someone would clue in very quickly as to whether the change had happened or not, so I'd say no confirmation message for these.

Beyond that, towards a general rule, I think combining suggestions here of thinking about what's at stake and the audience for the app will guide you to a good decision in most if not all cases.

share|improve this answer
add comment

There are a few different mechanisms to communicate successful operations.

  • If the action results in a whole new screen (eg. clicking create takes you to an edit screen) then you don't need to say anything.

  • If the action keeps you on the same screen and updates a space on that screen, then use the Change Spotlight design pattern.

  • If the action results in addition or deletion of elements, also use the Self Healing Transition.

  • If the action has no or minimal effect on the visible screen, you can use a Status Blip (the little floating yellow status note that appears briefly on the top of the screen when you do something in google apps).

  • If there might be a couple of acknowledgements in a row and you want the user to see them more than fleetingly, use Notification Bars.

  • If there would be a lot of notifications, you could provide a dedicated space in the page where notifications accumulate and scroll by. Sort of like a log window.

  • Finally, if the operation results in additional information which the user will want, such as a receipt number, then it would be more acceptable to provide this confirmation in an explicit Modal Overlay.

share|improve this answer
    
Excellent. This really captures the types of decisions you need to make –  Jay Jun 21 '13 at 10:56
add comment

Yeah, it also depends on what's at stake. Actions can generally be identified as 'high stake' or 'low stake':

'High Stake' = If this doesn't work but I think it's worked, I'll be annoyed/screwed. 'Low Stake' = If this doesn't work, who cares.

I'd consider the examples you listed as low stake.

But in high stake cases in which, for example, a purchase is being made you'd definitely want to display a message although, as Glen points out, the user shouldn't necessarily be forced to interact.

share|improve this answer
    
I get the idea. but the definitions should be changed somehow. Because a user who only speaks German is screwed if he can't switch the language from English to German. Maybe the the definition should be more like: Are others affected as well if it works or not. (Actually a bad example too.) I think of a better definition. But the main point is that I am asking about specifically about confirmation messages where the action was successful. –  Raffael Luthiger Apr 14 '10 at 19:27
add comment

I would suggest yes and no. I have no proven evidence to back this up other than my own personal expierence, but if the change is easily visible, it is not neccessary to bombard the user with messages stating the obvious. However, there are exceptions to every rule. If the change is being made and the user won't be the only to one to see it, I would suggest yes, show a confirmation message. My reasoning behind this is accessability. The user may not be able to see the change themselves, however if a screen reader/text browser/etc. can display or read the confirmation message, the user knows the change was saved.

In conclusion, it depends on the situation, like anything. Best practice would be to be consistent, and always show a confirmation message, however, every situation is different. If your designing for small screens, for example.

Hope this helps.

share|improve this answer
    
Like Ali you are bringing in other things (screen reader, etc.) I was not thinking of. Thanks, this was really giving me more ideas to think about. –  Raffael Luthiger Apr 17 '10 at 12:07
add comment

Well, as per my experience with Desktop Applications (specially end user products) that are downloaded over the internet, these software are used by everyone from a Tech savvy to home users who just wants to fulfill their need. Sometimes you come across people who are not even aware of what they are actually doing or what changes they have actually made, so its always good to show them confirmation messages, warning messages and success messages. Lets say someone changes his password but never get any message in the end, he would never know his password is actually changed now and might try using the same old password next time.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.