Three easy steps to stop your users hating your forms

This is a blog about the development of Yeller, The Exception Tracker with Answers

Read more about Yeller here

Form validations are one of the least fun parts of doing web development. Not only do they suck to code, but it’s relatively easy to make mistakes on them that can prevent users from doing important things like signing up to your service.

Imagine how it feels from their point of view:

  1. See a cool new thing that solves a pain for you
  2. Go to sign up, enter email, password etc, the same thing you’ve done hundreds of times
  3. Hit a load of form validation errors, restrictions about passwords, emails etc

You never wanted to frustrate your potential customers. They’re literally two clicks of the back button away from going back to google and trying one of your competitors. Shoving a load of form validations in their face isn’t going to win them over.

Imagine if your forms were literally perfect:

  • You’d save your users a tiny bit of frustration, making you different from all the other sites out there
  • You’d have spent 15 minutes of work to save your users days and weeks worth of time
  • You’d get more signups, and less clicks on the back button

So, what do you do about this? Getting forms completely right the first time can get frustrating - you can’t anticipate what kinds of data your users are going to want to put in there. Here’s what you need to do: learn from your customers, in production

1. Track every single form validation failure

The first step to sorting this thing out is to track every single validation failure your users hit in production. The best way to do this is using an error tracking service, like Yeller. We’ll aggregate form validation failures, so you can see exactly which controllers and which forms are most problematic. Integrating this with a Rails app is easy (and it should be trivial in your programming language and framework of choice):

def create
  @user = # create your user here
  @user.save!
rescue ActiveRecord::RecordInvalid => e
  report_exception_to_yeller(e, :validation_errors => @user.errors.to_h, :validation_bad_fields => @user.errors.to_h.keys)
  render 'new'
end

A good error tracking service will record each kind of form separately, letting you see exactly where the problems are. It’ll also let you answer powerful questions:

  • which fields are most common in validation failures?

  • what are the most common values when phone_number failed validation?

What next

Ok, now you’ve got all your form validation errors in one place, and you’re looking at them regularly. How do you fix them up so that they happen less often?

2. Do as much as you can to make your customer’s life as easy as possible

So there’s a dirty little secret here:

most form validation failures are the programmer’s fault

Yeah that’s right. It’s your fault that your user hit the form validation errors.

The problem?

Being overly strict about input

How many times have you entered a credit card number on a site whilst you’re trying to pay for something, only to have it rejected with:

Please don’t include dashes or spaces in your credit card number

You know the cause of that: programmer laziness. It’s trivial to remove dashes and spaces from a credit card number using a regex.

This applies all over the place as well. There are so many places where just thinking about the data you actually need can save your customers a tonne of time:

  • remove spaces and dashes from credit card numbers
  • remove spaces and dashes and brackets from phone numbers
  • allow “fuzzy” time entry, like “last friday”, “next month” and so on
  • grab the user’s timezone and location from their browser using JavaScript and geoip, don’t make them have to use dropdowns with 100 elements in them
  • remove as many form fields as you can

Ok, you’ve eliminated as many form fields as you can, and made your acceptance criteria more meaningful to humans. But there’s still some invalid data creeping in. What do you do about that?

3. Be Explicit About What Your Requirements Are

Sometimes there are form validation requirements you can’t get around. “passwords should be over 8 characters in length”, “organization name should be alphanumeric”, “subdomains have to be url safe”, and so on.

For these ones, the trick is to tell your users exactly what you want. Here are some examples:

Slack tells users exactly the rules for your subdomain names up front:

Destroy All Software tells you the exact rules on password length, so you don’t have to guess

This stops users from guessing about what they can enter, and means they don’t have to submit the form just to be told what the validation rules are.

Go out and kick butt

Great! If you’ve read this far, you’re on the road to better form validations, and a better user experience. You’ll get more users signing up, and less frustrated with your service.

References

These are the posts and things I learned from to write this post:

  • Amy Hoy’s excellent presentation about how important it is to go the extra mile for your customers.
  • User Onboard’s Slack Teardown which explicitly calls out telling your users about validations up front.

This is a blog about the development of Yeller, the Exception Tracker with Answers.

Read more about Yeller here

Looking for more about running production applications, debugging, Clojure development and distributed systems? Subscribe to our newsletter: