Web sign up form best practices: field by field

A sign up form is a sequence, and the visitor remembers the field that said no. They type a name, then an email with a plus sign for their work account, then a password with a number and a capital letter. On submit the form says the email is invalid, and it clears the password boxes, so they type the password again. The rule that rejected the address was written for a shorter list of domains, and nothing on the page says which rule it was. A visitor who gets that message often does not retry. They close the tab and never learn why.

• The form asks for the email and password first, and everything else on the next screen.
• Every field has a visible label that stays on screen while the visitor types.
• Password rules sit beside the field and tick off as the visitor meets each one.
• Email validation accepts plus signs, long domains and newer top-level domains.
• A failed submit keeps every typed value and moves focus to the first field with an error.

On a sign up, only the fields that create the account have to be right before the visitor gets in. An email and a password are two decisions. Company size, role and team name belong on the screen after the account exists, where they tune the product instead of blocking the account. Asked on one page, the same questions ask for a decision on every line before the visitor knows what the product does. Mark the optional fields as optional in the label itself, so nobody has to guess which ones they may leave blank.

A rule that appears only after submit is a surprise, and a surprise at the end of a form reads as a trap. Wrong: one line at the top that says Invalid password after the button is pressed. Right: a list beside the password field that says at least eight characters and one number, and ticks each one off as it is met. The same goes for email. Check the address when the visitor leaves the field, not when they press the button, and name the problem in words: the address has no at sign, or it has a space in it. A plus sign or a newer top-level domain is valid, and should never produce an error.

On a phone, the browser offers to fill the form from saved details, and it sometimes fills the wrong box. A name can land in the email field when the labels are unclear, and a phone number can fill the company box. Set the autocomplete attribute on each input to the value that matches what it asks for, such as email for the address and new-password for a new password, so the browser knows the difference. The on-screen keyboard is the other problem. When it opens, it can hide the field the visitor is typing in, and the next field may sit under it. Check the form in a phone browser with the keyboard open, field by field.

Signup flow testing

A simulated visitor fills the form with a working email address and a password it makes up, then submits. The report shows each field it filled, the error text it got and the step where it stopped, with a screenshot. It cannot sign in with Google or single sign on, so a Google option is a path the test cannot finish. It also cannot read a text message, so a phone number that needs a code will stop the test at the code step. The test does not show whether the account is stored correctly in your system, because the visitor only sees what the screen says.

A form that worked in spring can fail after a new field, a consent checkbox or a chat widget is added to the page. Those can change the input, move focus or block the button while they load. After each change, fill the form on a phone and a laptop as a new visitor, and read the error text again. With paid credits, visitors can open a preview behind a site password.