Sending the right message with form validation

Error messages. Those little things everyone hates to see. As designers, we like to design the best possible experience for getting users through the task at hand. But it’s our job to put as much consideration into error states as we do the success flow.

Any error messages we show to users should provide helpful feedback. Users should know exactly what to do to fix the problem. Messaging needs to be clear and concise. A friendly, conversational tone helps keep users calm and lessens the friction. In this sense, the copy is the product in validation notices.

I’ve been spending my time improving login and signup on Recently I took an inventory of all the errors and notices. It was an eye-opening experience for me. I had to consciously think about the wide array of scenarios that might happen while filling out these forms. Who knew so many things could go wrong?

Let’s look at some examples.

Invalid Email Address


Use a working email address, so you can receive our messages.

This message is both straightforward and friendly. A nice nudge toward entering a valid email address. The user knows exactly how to fix the error and we explain why a working email address is necessary.

Telling them they will receive “our” messages is also a great way to humanize the service. It reinforces the idea that there are real people behind

Username Taken


Sorry, that username already exists! If this is you log in now.

A taken username is one of the most discouraging errors to receive. Rather than being cold, we apologize for the inconvenience. But this is also a great example of improving the overall experience with a validation error.

Perhaps they forgot they signed up. With a simple click on the link they can log in.

Password Doesn’t Meet Requirements


Your password is too easy to guess: you can improve it by adding additional uppercase letters, lowercase letters, or numbers.

We have requirements for passwords on to keep our users as secure as possible. Most errors about password requirements I’ve seen are given as convoluted orders. “You must include at least one uppercase letter, three numbers, and a special character.”

Instead of barking orders at our users who are just trying to sign up, we take the opportunity to educate them. The required types of characters are framed in a way as to suggest how to improve a weak password. Maybe this will even help a few people create stronger passwords elsewhere.

Username Doesn’t Exist


We don’t seem to have an account with that name. Double-check the spelling and try again!

If someone enters a username that doesn’t exist in our database, we take a gentle approach. We don’t tell them flat out they are wrong. The error is on our side. We don’t have an account with that name. Not you got it wrong.

Then we recommend the next step to fix the error. We could assume the user knows they should check the spelling, but sometimes it’s better to explicitly state what to do.

Next time you need to write error messages, think about how to minimize the burden on the user. Are you taking a friendly tone or does it come off as harsh? How can you turn an error into a suggestion? Does the user have enough information to fix it?

We spend hours writing and tweaking copy for these errors. Our copy often goes through as many iterations as the actual design. It’s baked in to the design process. Give error messages the attention they need. Provide friendly, helpful feedback. Your users will love you more for it.

This post was originally published on the Automattic design blog.

Leave a comment

Your email address will not be published. Required fields are marked *