User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
I'm wondering about the use of "successful" in confirmation messages after a form has been submitted ("The form has been successfully submitted." or "The mailbox has been successfully set up"). To me it seems too verbose. Is it not enough just saying the the form has been submitted? And if an error occur, I can be more specific.
When we use "successful" all the time, to me it almost sounds like we are expecting an error and are so proud that it actually worked.
What do you think?
I agree. Successful is a long word and The form has been successfully submitted is a bland and formal way of confirming something happened.
However, the idea that a form has been successfully submitted is more reassuring than if it had just been submitted without any other status. It indicates that not only was it sent, but it was also received somewhere. Or at least that's one interpretation of success.
What is success?
The problem is that what is successful in the mind of the developer at the time of writing may not match up with the user's idea of success at the time of completing the form. Does success mean it was sent or that it was received or that it made it's way into a database or does it misleadingly mean nothing at all. Is the success a state of guaranteeing a response or some other action.
That's really why the word successful is wrong - it doesn't explain what success means - despite the sense of optimism conveyed.
Does it work for repetitive situations?
If the user is going to see the confirmation message frequently, the phrase The form has been successfully submitted is going to get pretty boring pretty quickly. Much better to keep it short and sweet. If you can make it work for repetitive situations - it'll work for one off use-cases too.
Keep tone and voice relevant
It's important to keep the copy sensitive to the context of the surrounding tone and voice as well. For example, Thanks for that, job's a gooden might not work on a high stakes financial institution website.
Keep it real
Probably whatever copy you put after a form gets submitted is always going to feel like its a message that gets put up automatically, whether there was any real element of success or not. It may be better to give some brief animated indication that behind the scenes something is working and then to indicate the success graphically with one or two words of confirmation or thanks, and if relevant some expectation of what happens next (although if done right, the user should already have been given some indication of what to expect in terms of action and timing.).
So, thanking the user might be a better way of implicitly indicating the success of submitting a form:
And finally - don't block the user
But that's not all - those messages are not good enough on their own. It's wrong after submitting the form to be given a message (successful or otherwise) that essentially terminates the user's activity on the site. User's should always be guided on a progressive path, meaning that they don't have to backtrack or start navigating again.
So as important as the positive feedback is, it's equally important to give users options of where to go next now that the 'form' task has been completed. This takes away the weight and responsibility that would otherwise be forced upon a simple message.
Giving the user the next steps prevents them from focusing on the message too much, and they won't hang around wondering about what success means, or about whether it really got received. Instead, with your help, they'll be thinking about what else they might want to do.
One good method to do this kind of a thing without interrupting the user is to just give a waiting circle while the form is being submitted. Once successfully completed, replace it with a green tick mark. And show it for just two seconds.
And as Roger said, don't block the user. Put this at a corner
I often just use a general "Action successful", assuming that the user knows what he/she just did (create, delete).
I think it's good to use it at all, because it shows the user that something happened. Of course, this depends on how the software is written, and I often tend to just do nothing if parameters (data) are missing (as opposed to returning an error when the parameters had been invalid).
