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".

Background
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 the 10-edit milestone. There is more on that at our prioritization notes, but the summary is that we want to avoid trying to increase the number of registrations if it is likely it won't impact the number of those who actually become active editors. We also want to avoid simply building tools to increase the productivity or retention of existing editors of any kind, since these tend to be more difficult interaction problems.

Personas
To help guide our work related account creation and any onboarding experience immediately afterward, we've created four personas for users. By mapping newly-registered Wikipedians on a spectrum of their interest and experience with editing, as well as what kind of objective they have, we were able to better understand what the primary elements of an onboarding experience should be.

Current
Currently, there is little to no direction given to new registered users immediately after they join Wikipedia, other than a link to user preferences, other projects, and the internal referrer that brought the user to account creation. It looks like...



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. Not all people can or should edit Wikipedia, but those who are registering can be safely assumed to be better candidates for conversion to editing than random readers.

Proposed
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.

Since our goal is to increase the number of editors, the question that follows is who is registering and what kind of editing task might they want to complete? To understand the kind of users signing up for accounts and making their first edits, we've crafted four personas to represent newly-registered Wikipedians.

The possible ways to onboard new Wikipedians, regardless of their experience and motivation, breaks down into the following list:


 * 1) Help people accomplish their immediate goal. Of the 30% of registrations that edit, most of them seem to have something to do in mind.
 * 2) For the 70% of registrations who currently do not ever edit, get them to do something useful and interesting right away.
 * 3) Educate people about what an account is for and the many ways to contribute.
 * 4) Help them make social connections and find help.

There are various workflows which may help us serve these purposes, described below in the order which we plan to test them. The question guiding this work is, What kind of onboarding is needed?, and specifically, how much handholding do most new editors need to get started?

Flow 0

 * 1) Arrives at Wikipedia from a specific article (this won't work for referrals from special or non-editable pages).
 * 2) Visits the account creation page.
 * 3) Successfully creates account, is redirected to the welcome page. The landing page detects whether the referrer includes   and presents users with a special call to action to return to editing.
 * 4) If users visit the referrer are encouraged to edit by using guiders to editing and saving.

Rationale: This is a minimalist version of an onboarding task, simply testing whether we can increase the number of new registered users who complete their first edit. This is listed as "Flow 0" because it could be applied as a feature of all the following flows, since they all will continue to include a referrer link. If guiders are successful at increasing successful edits, we may alter this flow to avoid using a landing page, but simply redirect the user back to their referrer without an interstitial.

Flow 1

 * 1) Arrives at Wikipedia, either through one of the main portals (wikipedia.org, Main Page) or a specific article.
 * 2) Visits the account creation page.
 * 3) Successfully creates account, is redirected to the landing page including a welcome message, a prominent link to return their internal referrer, and a link to the Community Portal open task list. This new call to action may be phrased like "Help out", and is intended to invite those without a task in mind to contribute. Ideally, the two main calls to action on the page will Agora-style buttons.
 * 4) Either goes back to reading/editing their referring page, departs, or visits the Community Portal, entering the open task workflow there.

Rationale: By removing non-essential elements of the previous landing page, such as invitation to view user preferences, and making the "Return to article" link more prominent, we intend to better serve users that are like Adam, the reader who joined in order to make a specific edit, and Sarah, who joined because she was required to register in order to edit a semi-protected page or create an article. By adding a prominent invitation to view the open tasks at the Community Portal, we are providing a destination for users like Nora, who are willing to contribute but do not know where to start.



Flow 2

 * 1) Arrives at Wikipedia, either through one of the main portals (wikipedia.org, Main Page) or a specific article.
 * 2) Visits the account creation page.
 * 3) Successfully creates account, is redirected to the landing page including a welcome message, a prominent link to return their internal referrer, and a list of tasks to try
 * 4) Either goes back to reading/editing their referring page, departs, or chooses to accept one the tasks presented to them.
 * 5) If the user accepts a task, they are given a guided tour of how to complete it the first time.
 * 6) When users complete a task, they are show where to find more to do.

Rationale: this flow presents the same advantages for users like Adam and Sarah as Flow 1, in that it reduces cruft and makes the "return to" path more prominent. However, by placing a simplified version of the task list directly in the landing page, we aim to better aid users like Nora, who have no immediate plans to edit. The trade-off is that increasing the number of choices on the page may be distracting.

Flow 3

 * 1) Arrives at Wikipedia, either through one of the main portals (wikipedia.org, Main Page) or a specific article.
 * 2) Visits account creation page.
 * 3) Successfully creates account, and is redirected to a landing page with
 * 4) * a prominent method for returning to the page they were previously reading or editing
 * 5) * a call to action to make their first edit by fixing a simple error clearly presented in a simplified editor. (See initial mockups below)
 * 6) At this point, users may return to the original page they were reading/editing, skip the task presented, or accept the task.
 * 7) If users accept and complete the task, we may either present them with a similar task, or send them to the open task list at the Community Portal for more to do.

Rationale: the current designs for this flow aim to increase the affordances for all users we've described in our personas, but the particular advantage is that it aids Nora, who not only has no idea of what to do, but is almost completely unfamiliar with the mechanics of editing. Compared to the task list presented in Flows 1 and 2, this tool presents a single clear task, and shows the user obvious steps towards it completion. This flow may also make use of guiders.

Technical documentation
Much of the capability for testing these flows for onboarding new editors is contained in Extension:E3Experiments. Potential new requirements include:


 * Modification of the account creation user experience to support campaigns, previously implemented as URL parameters.
 * Use of usertagging to identify editors who engage in a particular onboarding workflow.
 * First tests will inject new content or remove it from the welcome page after account creation, which is a relatively easy thing to do.