Account creation user experience

This is documentation for the editor engagement experiments team's work on the account creation process.

Background and rationale
The goal of the editor engagement experiments team is to gather data about how to attract and retain new Wikipedia editors. While improvements to the account creation process are not strictly experiments – we are not testing a hypothesis – they are nonetheless necessary precursors for any attempts to run experiments that require new contributors creating an account. If people interested in contributing have a frustrating experience during registration, then any attempts to encourage them to become Wikipedians may fail even if we provide better editing tools. In short, a substandard signup process is a confounding factor in many, if not most, of the potential experiments to increase engagement, and will likely lower conversion rates overall.

Testing strategy and results
With the above rationale in mind, we A/B tested three iterations on designs for new account creation user experience on English Wikipedia, in October and November 2012. The results of these three tests were promising, with each one producing small but statistically significant increases in the number of new registrations. We also conducted remote user testing, and the videos, text answers, and conclusions are available.

To help us contextualize these results and make a final product decision, we set targets for launch to help us decide whether the more ambitious parts of the new interface, like the client-side validation and associated API, would be built out as a part of MediaWiki core. The requirements for a new account creation user experience that follow are a result of the testing results to date and how they reconcile with the targets we set previously.

User experience
The following describes what users we're focusing on and what their experience should be.

Personas
In User experience,normally the preferences of the end users are given more priority than client’s preferences and what would is best is thought from end user’s perspective.Throughout the designing process,this fact is reminded to the client as well as the design team.However, due to the unpredictable behavior of the end users and the way they tend to actually use the product  in real time,some important changes are required to be implemented after the launch of the website or the product.

To make things easier it is ideal to involve the users in making decisions right from the start of the process.Incorporating personas in the process is the best way to make the task easier.Persona can be considered as archetypal representation of the user base.There are many other factors like scenarios,use case and card sorting which are used by user experience designers.The idea behind this type of involvement of personas was initiated by Alan cooper and incorporated this concept into user experience design philosophy.From that period the concept of personas are used by ux designers to improve the end user’s experience.To make more clear ,personas can be considered as the representation of customers of the client.They are not real people but are just characters created by designers for remembering the kind of end users.The better the personas are created ,the better it will connect with needs and behavior of the end user ‘s. Creation of personas helps in tracking different type of users and their behaviors and response to specific situation while using the product.Personas also help the designer’s to manage the end users disappointments and goals before launching the application.

We've created four personas to represent the kinds of people creating accounts that we want to help. In addition, established editors (esp. sysops) who want to prevent accounts that violate community policy are a stakeholder in this process, if not a persona for those actually registering.

Current account creation experience


In addition to a CAPTCHA and fields for username, password, email, the MediaWiki messages that are currently part of the Create Account page include:


 * Fancycaptcha-createaccount (which on en.wiki also includes extensive descriptions of the policies and practices around account creation)
 * Prefs-help-email, which describes the optional email field
 * Prefs-help-email-others, also describes the optional email field
 * Signupend, links to Help:Logging in
 * Language links. Many Wikipedias include the option to view the form in another language. Which languages are present differ from project to project.

Note that many Wikipedias use MediaWiki messages to add warnings, disclaimers, and help text to augment the account creation process.

Proposed account creation experience

 * See also: Related bugs or additional feature requests that we have deferred for now are available in a public EtherPad.



Our redesign of the registration page (Special:UserLogin/signup) aims to ease the signup process through the following changes.


 * making the fields and labels larger, and increasing the size of the submit button
 * more clearly indicating what is required and what is optional
 * making the copy, including error messages, more concise and clear (e.g. simply calling the page "Create an account" rather than "Log in / create account" )
 * removing the excess instructional text that has accrued over the years
 * judicious use of color to call out important elements, in line with currently proposed guidelines
 * suggesting to users the core purpose and benefits of having an account on a MediaWiki project. (While we previously tested a literal list of benefits, this cannot be easily localized across projects, and thus we're focusing on using statistics about the community and project as a form of social proof to persuade people.)
 * letting users refresh the CAPTCHA, to reduce the annoyance of an unreadable test image
 * specifying font family. The default norm in MediaWiki core is to not specify any font family beyond sans serif, and to let skins specify fonts. In the new interface, we specifying consistent use of more legible fonts available to the widest possible number of users, while retaining sans serif fallbacks for the minority who do not have the relevant fonts. Specifying these font families in this way means that they will only appear for those systems which already can display them, and merely applies them more consistently to these forms (for example: making sure inputs, errors, and field descriptions all use the same font family). We've opted to specify these font families to one part of the MediaWiki core UI, with the styles available to all forms going forward, but only applied where appropriate, so that we may move related forms to this style where warranted in the future to ensure long term consistency.
 * removal of the "Remember me" checkbox on the form, to reduce unnecessary choices. We assume that the user wants to be remembered for their first login session, but do not set a cookie for long term persistence of the session.

Login
To ensure a unified user experience, we will also be completing a simple redesign of the login page. (Requirements and designs are at the preceding link.)

Technical documentation
and  in MediaWiki currently use QuickTemplate to generate their HTML forms. We will be building off this current system to first get our UI enhancements to function as desired. Separately, we will be supporting patches already in progress to convert to the HTMLForm class.

In addition to the direct user experience requirements listed above, we will be supporting tracking of campaigns associated with users, when appended to the account creation URL as. This campaign support will not yet include presentation of custom landing pages or generating MediaWiki tags for users who signup as part of a campaign, though these and other features may be considered for the future.

Also key to note is that we will be rolling out the first version of the new account creation experience in core as a hidden option, which can be revealed via appending a URL parameter such as. This will allow us to test the interface in production.


 * See also: engineering notes and Testing