Personal tools

Sign Up or Registration

From Social Patterns

(Difference between revisions)
Jump to: navigation, search
Line 3: Line 3:
[[Image:Yahoo-reg1 copy.png|Yahoo! Registration Screen]]
[[Image:Yahoo-reg1 copy.png|400px|Yahoo! Registration Screen]]
<br /> Fig. 1 - registration
<br /> Fig. 1 - registration

Revision as of 01:54, 11 November 2008



A user wants to access parts of a site or application that requires creating or saving personal information. A user wants to contribute content to the site’s community and have it attributed and saved for later.


Yahoo! Registration Screen
Fig. 1 - registration

Fig. 2 - Tumblr registration

Use When

  • Use this pattern when features require leaving personal or private information and privacy and security are a concern.
  • Use this pattern when financial transactions require remembering billing, shipping and transaction information.
  • Use this pattern when a user wants to participate—leaving comments, blogging, message boards posts, posting photos, building a personal network—and this participation needs to be attributed and/or associated with the user for purposes of building community, reputation or building up a personal profile or knowledge base.


  • Collect the bare minimum of information needed that still allows your user to participate in the site. This is often an email address—used as the username login—and a password.
  • Collect other information only as necessary for a compelling experience. Ask yourself if the data I am about to collect can be collected in another part of the site at another time.
  • Provide explanations about what each piece of information requested will provide in terms of user benefits.
    • Zip code or other location information provides location relevant restaurants and stores
    • Mobile phone number allows delivery of content to phone and delivery of content from phone to a web based account.
  • Require registration at the last possible moment in the user’s process of exploring the site, such as when they want to save a video they have created.
  • After registration, deliver the user back to the task they were in before they were sidetracked. If they were coming from a tour or exploration process, put them in the most logical spot that encourages them to get started.
  • Avoid gradual engagement solutions that simply distribute the various input fields in a sign-up form across multiple pages. It’s a good possibility that this will reduce efficiency and not delight anyone. (LukeW – forms)
  • Allow the creation of a unique identifier by allowing the use of an email address, which is a unique piece of data and can be verified with the user.
  • Don’t force the user to try and create a unique name that isn’t an email address. Unless they are an early adopter on your site, the odds that the name (often their first name) they want is available gets smaller over time and will only annoy your users and at worst cause site abandonment and ill will.
  • Allow use of a non-unique nickname for reflection back to the user and communication between the system and user.

Fig. 3 - Sign up error message on Photo Bucket.

  • Clearly label what elements are required for a username and password. Are capital letters and numbers required? Are alternate characters not allowed? Minimum 6 characters or no more than 15 allowed? Say so up front and don’t wait to present this information in an error message. Jared Spool calls this designing defensively. Being clear up front as to what is expected as well as preventing interruptions will ensure a more successful sign up experience.

Fig. 4 - Yahoo!’s registration form shows green checks when sections are correctly filled out.

  • Provide feedback as the user fills out the form. Examples may include a check box as a field is filled out correctly—fully realized email address—or a password strength meter to indicate security potential of a password.

Fig. 5 - Yahoo!’s registration form provides inline error messaging when something is not right with the field entry. In this case, the user put in a future date into the field. The error message uses humor to let the user know that this entry is not acceptable.

  • Provide inline, contextual error messages that validate dates and data formation or check on username availability before the Submit button is pressed. This will allay user irritation and results in less drop-off in completions.
  • Make sure the level of security required for the password matches the level of security required for the data the user will be creating or saving. Saving a recipe is very different than paying a bill at my bank. The expectations for site security and for the type of password used are very different. Adjust accordingly.


Registration is often an interruption for users when they are in the middle of some other process. It’s a known and accepted evil when personal data or user generated content needs to be stored, but that doesn’t mean sites should take advantage of the interruption to collect a life story and firstborn.

Users will give what they believe is necessary in trade for a good experience. If more information than a unique identifier and password is needed, it is important to be very clear why that information is needed and what the value to them will be. Registration is a barter with the user and they will abandon the process and your site if the value isn’t clearly articulated or seen as high enough.

Fig 6. - Sign up form screens from and

Related Patterns

  • Sign In
  • Sign-in Continuity
  • Sign Out

As Seen On