Are confirmation messages for visible changes necessary?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.