Leave data in form after submission?

Question

I've got a form in my web application that a user would use to send messages to another user of the system. So for example, a manager might want to send a message to all of their direct reports about something. It's a simple form; there isn't any list of previously sent messages or anything else. There's a link on another page, takes you to this form, you send the message, that's all.

Okay, after a message is sent via this form, we're going to reload the same page with a success message at the top ("Good work you sent the message successfully!" something like that). The question is - should the data remain in the form after it's submitted?

One reason why you might potentially want to do this is if you wanted to send a similar-but-not-the-same message to two different people. On the other hand, maybe leaving the data in the form would make it seem like there was an error on the page if users ignored the success message.

What do you think?

Answer 1

On the other hand, maybe leaving the data in the form would make it seem like there was an error on the page if users ignored the success message.

This matches the results of user tests I've performed.

Users do not trust applications; they know that they are flaky and prone to failures. That means they need to be strongly convinced that submission is successful. So much so, in fact, that presenting the user the same view before and after an action seems to make a significant minority of users think that it has failed.

Think about it cognitively. I enter my message. I hit the save button. There's a message and everything's still in the fields. My heuristics tell me that there's some sort of form error. Even if the message says that everything's okay, that could be an error too! So I hit save again (spamming my recipients), just to see if that works. It still seems broken so I... send the message as an email (a third time!).

As a rule, when it's important that an action not be repeated unnecessarily, you need to strongly communicate that submission has worked, the current state of the interface (pre or post submission) and not provide opportunities for mistaken repeats (this includes double-clicks on the first submission).

One reason why you might potentially want to do this is if you wanted to send a similar-but-not-the-same message to two different people.

Possibly, but you should investigate whether this is really needed, and if it is, whether this is actually the solution, or something like a templating or mail-merge system is required.

Answer 2

Well, this probably isn't the answer you want... but I think adding a simple message history would solve your problem and provide a much better overall UX.

I can't thing of an asynchronous messaging system without at least a simple history or inbox/outbox. What happens if the receiver accidentally closes the message before reading it, or if they forget what it said two minutes later? What if the sender needs to send it to multiple people, but forgets if she included everyone after clicking send? It doesn't sound very forgiving of user error. Even synchronous chat-style messaging systems show recent messages.

Building something simple is admirable, but building something too simple can be worse than not building it at all. Ryan Singer does a good job of explaining why in this article on minimum viable products.

Answer 3

I would not show the form at all after a message has been sent. I would direct the user to the "messages" section of the application and display the success message, or I would hide the form and show the message along with a link to "send a new message".

The user's mental model for messaging is going to be based on how all other message systems work. When you send an email, you are not left with the compose email window open with your full email in it. When you send a text message, your composition UI does not stay up.

You should only display the form if the current step the user is on is composing a message.

If your use case requires creating message templates that can be opened, modified, and sent to one or more people, then you should create a user interface that supports that.

Let your user's goals and needs drive your UI, not the other way around.

Answer 4

I'd add a simple "remember this message" checkbox below the form, so that the user can choose what she prefers.

You can choose whether the default state should be checked or not based on actual tests with the end users.