Onboarding new Wikipedians

Work by the editor engagement experiments team to get new registered Wikipedians to quickly become productive members of the community. Getting people up to speed in an organization or community is often called "onboarding". It is a term borrowed from human resources departments, but is now a common piece of the user experience design parlance.

Rationale
As a follow-up to our work improving the account creation user experience, we have decided to focus on increasing the number of registered accounts that contribute and reach their fifth edit. There is more on that at our prioritization notes and Quarterly Product Plan.

User experience
Our two goals for onboarding are:


 * 1) Help editors accomplish their immediate objective, if they have one.
 * 2) For users without a task in mind, get them to contribute something useful right away.

In order to accomplish these two things, we need to understand who is registering, what kind of editing task might they want to complete, and how best can we help them do that? We've created four personas for users as a start, and will use these framing questions as we experiment with new interfaces for onboarding.

Other onboarding tactics might involve helping users develop social connections or find help, or alternatively, get users to complete tasks such as profile completion prior to making any kind of substantive contribution to the encyclopedia. While it is standard for other applications to encourage people to fill out things like profiles or complete a checklist of tasks before using their product, the Wikipedia way is to encourage people to focus on contributing content. The current behavior pattern of successful new Wikipedians matches this; of registered users who do complete an edit, the majority do so within an hour of registration.

Current (MediaWiki default)
In the MediaWiki default, there is little to no direction given to new registered users immediately after they join, other than a link to user preferences, other projects, and the internal referrer that brought the user to account creation.

For the people who already know what they want to accomplish as editors, at least in the immediate future, this lack of onboarding is not necessarily an obstacle. However, we know that the majority of accounts registered never attempt or complete an edit.



Proposed
The following workflow is a summary of the current approach we're taking, with more detail about each major step -- landing page, task, and the experience post-task completion -- detailed below.

Pre-onboarding
 * 1) The user arrives at Wikipedia, either through one of the main portals (wikipedia.org, Main Page) or a specific article.
 * 2) The user visits the account creation page.

Onboarding
 * 1) The user successfully creates account, is redirected to a landing page including...
 * 2) * a welcome message (new welcomecreation message),
 * 3) * a prominent link to return their internal referrer,
 * 4) * a list of tasks to try,
 * 5) The user either goes back to reading/editing their referring page, departs, or chooses to accept one the tasks presented to them.
 * 6) If the user accepts a task, they are given a guided tour of how to complete it the first time. This tour will educate them about...
 * 7) * how to accomplish the task
 * 8) * how to edit the page
 * 9) * how to save their edit
 * 10) When users complete a task, they are show where to find more to do, including how to return to such a task list at their leisure.

Landing page
Our goal for this landing page is to get users to accept a first editing task, with the secondary goal of supporting those who just want to get back to the task they already have in mind. The spectrum on which we can play with the contents of this landing page is to either optimize a single task, or increase the diversity of task types and articles available.

Our first iteration provided a list of tasks to entice new editors focuses on delivering articles of a single type of task -- basic copyediting -- in a list updated on an hourly basis. The tasks delivered as part of our onboarding process are real Wikipedia articles, as opposed to test cases or simulations. This has two advantages: it avoids creating a shock when users who have "made an edit" encounter the realities of wikitext on real tasks, and it counts as real edit. One disadvantage to this choice is that we are exposing these articles to vandalism or other malefactors.

Future work and alternative ideas

 * As an alternative to the landinge page approach, we could redirect users to their internal referrer, then provide relevant calls to action, such as in a modal. Whether we return users to their referrer automatically or not, that workflow may merit additions: for instance, work on the article creation workflow and helping users who want to contribute to pages that are semi-protected.
 * Future versions will ideally detect when a user is referred by an edit window, and skip onboarding in favor of returning them to editing. (The flow above would deal with this use case as well.)
 * The current design of the onboarding page has the primary goal of encouraging the user to complete an edit. Depending on the funnel analysis, it may be necessary to reduce the number of choices directed at new users by providing only a single task at a time. (See mockups below)
 * For either multiple or single task flows, it may help users choose an article if there is a refresh or skip action.

Task page (i.e. article)
Our goal when users have accepted a task is to help them complete it. Though we are not completely controlling the user experience with a simulated task, we can provide extra help to users on the articles they choose to interact with as part of the onboarding process. To do this, we are experimenting with a simple guided tour of the edit interface, using the following steps...


 * See also: user tests of this tour, including upcoming usability enhancements

Post-onboarding
Currently this flow emphasizes helping users complete a first edit. We might consider this the most basic form of onboarding completion, but in reality it is simply getting users over the hurdle of making that first contribution, learning to navigate the editor interface, etc. Users are not considered active contributors until they reach their fifth edit milestone.

Currently, we will use two methods to help users go beyond their first edit:


 * 1) The guided tour described above has a final step, where after completing an edit, users are notified that "Getting Started" is updated with more to do regularly.
 * 2) We will be experimenting with giving new users a persistent link to the Getting Started interface. In the place previously occupied by MoodBar, will be giving a "Get started with editing link" and an indicator that this feature is new. See mockup below. This link will expire after one week, and will only be visible to users who register after its launch.
 * 3) We will be working to build relevant on-site and email notifications to draw back users who edited, and activate those who did not.



Technical documentation
We will deliver this new onboarding experience through a combination of:


 * Extension:GettingStarted: presents the landing page with tasks and other calls to action for new editors immediately after registration
 * Extension:GuidedTour: which provides the guides to how to complete a task, if a user accepts one
 * Extension:E3Experiments and Extension:EventLogging: instrumentation and data collection

Subpage /Engineering has some technical notes.

Experimental design and data collection
See: Research:Onboarding new Wikipedians

User testing
We've conducted three remote user tests to date. See /user testing for conclusions and videos.''