Creating the Ultimate Signup Form

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

Read more about Yeller here

The first interaction your customers have with you is the most vital. If you throw a bad experience at them up front, how will that impact their opinion of your product?

The average signup form on a website has too many fields, and presents a bunch of bad user experience problems. This means you’re losing potential customers - they’re just going to bounce off the form and go back to Google.

Email/Password only - NO OAUTH

The first, and most important thing for user signup is that you should just offer email and password as an authentication mechanism. In all the user interviews I’ve done, mechanisms for using an external ID (like Facebook or Twitter) to authenticate just confuse people. And for technically savvy audiences, they often don’t want to give Facebook access to a third party, because they know all the privacy problems with that. Donald Stufft wrote more about this in this fire mailing list post.


Everybody who works on making signup forms better knows that there’s one golden rule that always improves the experience:

Fewer Fields == Better Experience

But what about when your service requires certain pieces of information? One common one is knowing the user’s full name, so you can greet them with a more personal feel on the site. But do your users really need to type that in? Or can you just grab it by looking up their email in an API that supports that? And, given that information, can you add a personal touch by welcoming the user properly?

Of course you need a fallback, for when you can’t find that, but adding that bit of extra flourish makes the signup process that bit better.

Pick the Right Words

A/B tests across many, many companies prove true: optimizing the button copy on your signup form is the largest impact change you can make to your website. So work at it. Here are some examples from my favorite web copy writers:




Tell the user the validation up front

One really really common mistake signup forms make is not telling the user what validations are there up front. This leaves your users guessing:

  • How long can I make my password?
  • Are there any restrictions on company name?

Samuel Hulick brings this up a whole bunch in his user onboarding teardowns, which are really useful to see how the best companies in the world handle onboarding.

Cater to YOUR customers

Lastly, make sure you pay attention to knowing your customers. Don’t just build a generic “good signup form” - signup forms don’t exist in a vacuum - they have to have users. So think about your users, and how you can make your signup form better by learning with them.

For example, for Yeller, the signup form is specifically targeted at programmers. As such, there’s two tweaks we do to make it more suitable. First, we detail the password storage mechanism, so that users know that the site pays attention to security:

Secondly, as a callout to the way validations are commonly written by programmers, Yeller details organization name restrictions as a regex at the end. This is just a small personality touch, but these kinds of details really impact the people who use your product.

Takeaways for your product:

Making your signup form much better isn’t difficult, and it’s likely one of the biggest impacts you can have on the business you work in.

Here are those tweaks again:

  • email and password only
  • delight
  • pick the right words
  • put your validations up front
  • cater to YOUR customers

Further Reading

Samuel Hulick has an excellent series of teardowns over at User Onboard. Whilst these do cover the rest of the onboarding process, they usually show the (heavily optimized) signup forms that companies like Slack and Basecamp use.

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: