Checklist

The sign-up form checklist: 12 checks

Every account your product gets passes through one form. Here are twelve checks to run on yours tonight, each from a standard or a platform’s own guidelines.

Get the PDF

Sources checked 30 October 2026

1. Let them in first

If your app works without an account, let people use it before they sign up.

Source: Apple, App Review Guidelines (opens in a new tab) 5.1.1(v): “If your app doesn’t include significant account-based features, let people use it without a login.” web.dev, Sign-up form best practices (opens in a new tab): “Avoid sign-in if you can.”

2. Ask only for what you need now

Every extra field is a reason to stop. Ask for the rest later, when it is needed.

Source: Apple, App Review Guidelines (opens in a new tab) 5.1.1(v): “Apps may not require users to enter personal information to function, except when directly relevant to the core functionality of the app or required by law.”

3. Labels above the field, never only inside it

A hint inside the field disappears the moment people start typing.

Source: Nielsen Norman Group, Placeholders in form fields are harmful (opens in a new tab): “Disappearing placeholder text strains users’ short-term memory.” web.dev, Sign-in form best practices (opens in a new tab): “Don’t use placeholders as input labels.” and “It’s probably best to put your labels above your inputs.”

4. The right keyboard for every field

An email field opens the email keyboard; a phone field opens the number pad.

Source: web.dev, Sign-up form best practices (opens in a new tab): “use the appropriate type attribute to provide the right keyboard on mobile”. Android Developers, Specify the input method type (opens in a new tab): “Always declare the input method for your text fields by adding the android:inputType attribute”.

5. Let the phone and the browser fill it in

Tell the form what each field is, so saved details fill in by themselves.

Source: web.dev, Sign-up form best practices (opens in a new tab): “For sign-up forms use autocomplete="new-password" for new passwords”, with autocomplete="email" for the email field and autocomplete="username" for usernames. W3C, WCAG 2.2 success criterion 1.3.5 (opens in a new tab) (level AA), so that “browsers and other user agents can suggest and ‘autofill’ the right content”.

6. Rules up front, not after

If a field has rules, show them before people type, not in the error after they submit.

Source: W3C, WCAG 2.2 success criterion 3.3.2 (opens in a new tab) (level A): “Labels or instructions are provided when content requires user input.”, most of all “if there are specific rules for correct input”. Baymard Institute, guideline 676 (opens in a new tab), names the cost: “Users may have to attempt multiple times to create a password that the site will accept, wasting valuable time and effort”.

7. Length, not symbols

Ask for a long password. Don’t force capitals, numbers or symbols, and don’t force changes on a schedule.

Source: NIST SP 800-63B-4 (opens in a new tab), section 3.1.1.2: passwords used alone need “a minimum of 15 characters in length” (eight when they are one step of a multi-factor sign-in); verifiers “SHOULD permit a maximum password length of at least 64 characters”, “SHALL NOT impose other composition rules”, “SHALL compare the prospective secret against a blocklist”, and “SHALL NOT require subscribers to change passwords periodically”.

8. Allow paste and password managers

Never block paste in a password field, and let password managers fill it.

Source: NIST SP 800-63B-4 (opens in a new tab): “SHALL allow the use of password managers and autofill functionality” and “SHOULD permit claimants to use the ‘paste’ function when entering a password”. W3C, WCAG 2.2 success criterion 3.3.8 (opens in a new tab) names “support for password entry by password managers to reduce memory need” and “copy and paste to reduce the cognitive burden of re-typing”. web.dev, Sign-up form best practices (opens in a new tab): “Allow password pasting”.

9. Let them see the password

A show password control lets people check what they typed before they submit.

Source: NIST SP 800-63B-4 (opens in a new tab): “SHOULD offer an option to display the password”. web.dev, Sign-in form best practices (opens in a new tab): “You should add a Show password toggle to enable users to check the text they’ve entered.”

10. Ask once

No “confirm your email” field. People who can see what they typed don’t need to type it twice.

Source: web.dev, Sign-up form best practices (opens in a new tab): “Don’t double up your inputs just to make sure users get their contact details right.”

11. Errors next to the field, with the fix

Say what went wrong and how to fix it, right where it happened.

Source: Nielsen Norman Group, An error messages scoring rubric (opens in a new tab): “The error should be displayed next to the associated interface element(s).” and “The error message should describe a solution that is sufficient for the user to fix the problem.” web.dev, Sign-up form best practices (opens in a new tab): “Show problems inline and explain how to fix them”.

12. One tap, one account

The button presses in, says what it is doing, and ignores a second tap. Your server ignores a duplicate too.

Source: Apple, Human Interface Guidelines, Buttons (opens in a new tab): “Always include a press state for a custom button. Without a press state, a button can feel unresponsive, making people wonder if it’s accepting their input.” Baymard Institute, People still double-click online (opens in a new tab): “disable the submit button immediately after it has been clicked” and “code your back-end to ignore identical orders”. “Do both if you want to be on the safe side.”

Two more for iOS apps

If people can create an account in your iOS app, they must be able to delete it in the app. Apple 5.1.1(v): “If your app supports account creation, you must also offer account deletion within the app.”
If your iOS app offers a third-party or social login, Apple 4.8 asks for an equivalent option that “limits data collection to the user’s name and email address” and “allows users to keep their email address private”.

Save it for your next release, and run it on your own sign-up tonight.

Sources

We opened every source on 30 October 2026.