This content originally appeared on web.dev and was authored by Sam Dutton
If users ever need to log in to your site, then good sign-up form design is critical. This is especially true for people on poor connections, on mobile, in a hurry, or under stress. Poorly designed sign-up forms get high bounce rates. Each bounce could mean a lost and disgruntled user—not just a missed sign-up opportunity.
Try it! If you would prefer to learn these best practices with a hands-on tutorial, check out the Sign-up form best practices codelab.
Here is an example of a very simple sign-up form that demonstrates all of the best practices:
Caution: This post is about form best practices.
It does not explain how to implement sign-up via a third-party identity provider (federated login) or show how to build backend services to authenticate users, store credentials, and manage accounts.
Integrating Google Sign-In into your web app explains how to add federated login to your sign-up options.
12 best practices for user account, authorization and password management outlines core back-end principles for managing user accounts.
Checklist
- Avoid sign-in if you can.
- Make it obvious how to create an account.
- Make it obvious how to access account details.
- Cut form clutter.
- Consider session length.
- Help password managers securely suggest and store passwords.
- Don't allow compromised passwords.
- Do allow password pasting.
- Never store or transmit passwords in plain text.
- Don't force password updates.
- Make it simple to change or reset passwords.
- Enable federated login.
- Make account switching simple.
- Consider offering multi-factor authentication.
- Take care with usernames.
- Test in the field as well as the lab.
- Test on a range of browsers, devices and platforms.
Avoid sign-in if you can
Before you implement a sign-up form and ask users to create an account on your site, consider whether you really need to. Wherever possible you should avoid gating features behind login.
The best sign-up form is no sign-up form!
By asking a user to create an account, you come between them and what they're trying to achieve. You're asking a favor, and asking the user to trust you with personal data. Every password and item of data you store carries privacy and security "data debt", becoming a cost and liability for your site.
If the main reason you ask users to create an account is to save information between navigations or browsing sessions, consider using client-side storage instead. For shopping sites, forcing users to create an account to make a purchase is cited as a major reason for shopping cart abandonment. You should make guest checkout the default.
Make sign-in obvious
Make it obvious how to create an account on your site, for example with a Login or Sign in button at the top right of the page. Avoid using an ambiguous icon or vague wording ("Get on board!", "Join us") and don't hide login in a navigational menu. The usability expert Steve Krug summed up this approach to website usability: Don't make me think! If you need to convince others on your web team, use analytics to show the impact of different options.
You may be wondering whether to add a button (or link) to create an account and another one for existing users to sign in. Many popular sites now simply display a single Sign in button. When the user taps or clicks on that, they also get a link to create an account if necessary. That's a common pattern now, and your users are likely to understand it, but you can use interaction analytics to monitor whether or not a single button works best.
At window sizes larger than shown here, Gmail displays a Sign in link and a Create an account button.
Make sure to link accounts for users who sign up via an identity provider such as Google and who also sign up using email and password. That's easy to do if you can access a user's email address from the profile data from the identity provider, and match the two accounts. The code below shows how to access email data for a Google Sign-in user.
// auth2 is initialized with gapi.auth2.init()
if (auth2.isSignedIn.get()) {
var profile = auth2.currentUser.get().getBasicProfile();
console.log(`Email: ${profile.getEmail()}`);
}
Once a user has signed in, make it clear how to access account details. In particular, make it obvious how to change or reset passwords.
Cut form clutter
In the sign-up flow, your job is to minimize complexity and keep the user focused. Cut the clutter. This is not the time for distractions and temptations!
On sign-up, ask for as little as possible. Collect additional user data (such as name and address) only when you need to, and when the user sees a clear benefit from providing that data. Bear in mind that every item of data you communicate and store incurs cost and liability.
Don't double up your inputs just to make sure users get their contact details right. That slows down form completion and doesn't make sense if form fields are autofilled. Instead, send a confirmation code to the user once they've entered their contact details, then continue with account creation once they respond. This is a common sign-up pattern: users are used to it.
You may want to consider password-free sign-in by sending users a code every time they sign in on a new device or browser. Sites such as Slack and Medium use a version of this.
As with federated login, this has the added benefit that you don't have to manage user passwords.
Consider session length
Whatever approach you take to user identity, you'll need to make a careful decision about session length: how long the user remains logged in, and what might cause you to log them out.
Consider whether your users are on mobile or desktop, and whether they are sharing on desktop, or sharing devices.
You can get around some of the issues of shared devices by enforcing re-authentication for sensitive features, for example when a purchase is made or an account updated. You can find out more about ways to implement re-authentication from the codelab Your First WebAuthn App.
Help password managers securely suggest and store passwords
You can help third party and built-in browser password managers suggest and store passwords, so that users don't need to choose, remember or type passwords themselves. Password managers work well in modern browsers, synchronizing accounts across devices, across native and web apps—and for new devices.
This makes it extremely important to code sign-up forms correctly, in particular to use the correct
autocomplete values. For sign-up forms use autocomplete="new-password" for new passwords, and add
correct autocomplete values to other form fields wherever possible, such as autocomplete="email"
and autocomplete="tel".
You should also use the appropriate type attribute
to provide the right keyboard on mobile and enable basic built-in validation by the browser.
You can find out more from Payment and address form best practices.
Sign-in form best practices has lots more tips on how to improve form design, layout and accessibility, and how to code forms correctly in order to take advantage of built-in browser features.
Ensure users enter secure passwords
Enabling password managers to suggest passwords is the best option, and you should encourage users to accept the strong passwords suggested by browsers and third-party browser managers.
However, many users want to enter their own passwords, so you need to implement rules for password strength. The US National Institute of Standards and Technology explains how to avoid insecure passwords.
Warning: Sign-up forms on some sites have password validation rules that don't allow the strong passwords generated by browser and third-party password managers. Make sure your site doesn't do this, since it interrupts form completion, annoys users, and requires users to make up their own passwords, which may be less secure than those generated by password managers.
Don't allow compromised passwords
Whatever rules you choose for passwords, you should never allow passwords that have been exposed in security breaches.
Once a user has entered a password, you need to check that it's not a password that's already been compromised. The site Have I Been Pwned provides an API for password checking, or you can run this as a service yourself.
Google's Password Manager also allows you to check if any of your existing passwords have been compromised.
If you do reject the password that a user proposes, tell them specifically why it was rejected. Show problems inline and explain how to fix them, as soon as the user has entered a value—not after they've submitted the sign-up form and had to wait for a response from your server.
Don't prohibit password pasting
Some sites don't allow text to be pasted into password inputs.
Disallowing password pasting annoys users, encourages passwords that are memorable (and therefore may be easier to compromise) and, according to organizations such as the UK National Cyber Security Centre, may actually reduce security. Users only become aware that pasting is disallowed after they try to paste their password, so disallowing password pasting doesn't avoid clipboard vulnerabilities.
Never store or transmit passwords in plain text
Make sure to salt and hash passwords—and don't try to invent your own hashing algorithm!
Don't force password updates
Don't force users to update their passwords arbitrarily.
Forcing password updates can be costly for IT departments, annoying to users, and doesn't have much impact on security. It's also likely to encourage people to use insecure memorable passwords, or to keep a physical record of passwords.
Rather than force password updates, you should monitor for unusual account activity and warn users. If possible you should also monitor for passwords that become compromised because of data breaches.
You should also provide your users with access to their account login history, showing them where and when a login happened.
Make it simple to change or reset passwords
Make it obvious to users where and how to update their account password. On some sites, it's surprisingly difficult.
You should, of course, also make it simple for users to reset their password if they forget it. The Open Web Application Security Project provides detailed guidance on how to handle lost passwords.
To keep your business and your users safe, it's especially important to help users change their
password if they discover that it's been compromised. To make this easier, you should add a
/.well-known/change-password URL to your
site that redirects to your password management page. This enables password managers to navigate
your users directly to the page where they can change their password for your site. This feature is
now implemented in Safari, Chrome, and is coming to other browsers. Help users change passwords
easily by adding a well-known URL for changing passwords explains how to
implement this.
You should also make it simple for users to delete their account if that's what they want.
Offer login via third-party identity providers
Many users prefer to log in to websites using an email address and password sign-up form. However, you should also enable users to log in via a third party identity provider, also known as federated login.
This approach has several advantages. For users who create an account using federated login, you don't need to ask for, communicate, or store passwords.
You may also be able to access additional verified profile information from federated login, such as an email address—which means the user doesn't have to enter that data and you don't need to do the verification yourself. Federated login can also make it much easier for users when they get a new device.
Integrating Google Sign-In into your web app explains how to add federated login to your sign-up options. Many other identity platforms are available.
"First day experience" when you get a new device is increasingly important. Users expect to log in from multiple devices including their phone, laptop, desktop, tablet, TV, or from a car. If your sign-up and sign-in forms aren't seamless, this is a moment where you risk losing users, or at least losing contact with them until they get set up again. You need to make it as quick and easy as possible for users on new devices to get up and running on your site. This is another area where federated login can help.
Make account switching simple
Many users share devices and swap between accounts using the same browser. Whether users access federated login or not, you should make account switching simple.
Consider offering multi-factor authentication
Multi-factor authentication means ensuring that users provide authentication in more than one way. For example, as well as requiring the user to set a password, you might also enforce verification using a one-time-passcode sent by email or an SMS text message, or by using an app-based one-time code, security key or fingerprint sensor. SMS OTP best practices and Enabling Strong Authentication with WebAuthn explain how to implement multi-factor authentication.
You should certainly offer (or enforce) multi-factor authentication if your site handles personal or sensitive information.
Take care with usernames
Don't insist on a username unless (or until) you need one. Enable users to sign up and sign in with only an email address (or telephone number) and password—or federated login if they prefer. Don't force them to choose and remember a username.
If your site does require usernames, don't impose unreasonable rules on them, and don't stop users from updating their username. On your backend you should generate a unique ID for every user account, not an identifier based on personal data such as username.
Also make sure to use autocomplete="username" for usernames.
Caution: As with personal names, ensure that usernames aren't restricted to characters from the Latin alphabet. Payment and address form best practices explains how and why to validate using Unicode letter matching.
Test on a range of devices, platforms, browsers and versions
Test sign-up forms on the platforms most common for your users. Form element functionality may vary, and differences in viewport size can cause layout problems. BrowserStack enables free testing for open source projects on a range of devices and browsers.
Implement analytics and Real User Monitoring
You need field data as well as lab data to understand how users experience your sign-up forms. Analytics and Real User Monitoring (RUM) provide data for the actual experience of your users, such as how long sign-up pages take to load, which UI components users interact with (or not) and how long it takes users to complete sign-up.
- Page analytics: page views, bounce rates and exits for every page in your sign-up flow.
- Interaction analytics: goal funnels and events indicate where users abandon the sign-up flow and what proportion of users click buttons, links, and other components of your sign-up pages.
- Website performance: user-centric metrics can tell you if your sign-up flow is slow to load or visually unstable.
Small changes can make a big difference to completion rates for sign-up forms. Analytics and RUM enable you to optimize and prioritize changes, and monitor your site for problems that aren't exposed by local testing.
Keep learning
- Sign-in form best practices
- Payment and address form best practices
- Create Amazing Forms
- Best Practices For Mobile Form Design
- More capable form controls
- Creating Accessible Forms
- Streamlining the Sign-up Flow Using Credential Management API
- Verify phone numbers on the web with the Web OTP API
Photo by @ecowarriorprincess on Unsplash.
This content originally appeared on web.dev and was authored by Sam Dutton
Sam Dutton | Sciencx (2020-12-09T00:00:00+00:00) Sign-up form best practices. Retrieved from https://www.scien.cx/2020/12/09/sign-up-form-best-practices/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.