Growth/Focus on help desk

This page describes the Growth team's work on the "Focus on help desk" project, and contains major assets, designs, and decisions. Most incremental updates on progress will be posted on the general Growth team updates page, with some large or detailed updates posted here.

Summary
It is common for new editors to face technical, conceptual, and cultural challenges when they start editing. They have specific questions, and could benefit from a human editor answering their questions. Most wikis have a help desk where new editors can ask questions, and such venues have been proven to be effective, especially the Teahouse in English Wikipedia (see this paper for an analysis of impact). The problem is that most new editors don't know about or find the help desk -- even though they frequently receive "welcome templates" on their talk pages with links.

We have two hypotheses:


 * Newcomers are more likely to seek help when presented with an easy way to submit questions.
 * Newcomers are more likely to complete edits by knowing where to seek help.

Therefore, the "Focus on help desk" project contains two parts:


 * 1) Invite new editors to the help desk.  We had four ideas for how to invite them: by posting on their talk pages, by using banners, through email, or by adding a link in the editing context.  We have decided to invite new editors to the help desk by adding a clear and obvious link to the help desk inside their editing experience, which we are calling the "help pane". That's for these reasons:
 * 2) * We know from the New Editor Experiences research that getting help in-context is important. This would offer a link to get help at the moment when users need it, and in a place that currently has no clear way to get help.
 * 3) * We have open questions around the "In-context questions or chat" idea, and this will help us learn whether there is demand for such a feature.
 * 4) Once we are successful at driving new editors to the help desk, undertake improvements to the help desk itself that make it a better place to ask questions.  This might include listing new questions at the top of the page or notifying new editors when their questions have been answered.

The Growth team is building Part 1 (the help pane) first during 2018 Q2 (October 2018 - December 2018). Our goal is to deploy an initial version of the help pane at the beginning of January 2019 inside an experiment. After analyzing the results, we will decide whether and how to pursue Part 2.

Comparative review
Our team's designer reviewed the way that other platforms (e.g. SurveyMonkey, American Express, Codecademy) offer help in-context to their users (see this task for details). We think there are best practices we can learn from other software, especially when we see the same patterns across many different types of software. Even as we incorporate ideas from other software, we will still make sure to preserve Wikipedia's unique values of openness, clarity, and transparency. The comparisons are shown in this slide deck, and the main takeaways are:

In-context help UIs


 * In-context help is usually presented as a sticky button or tab in the bottom right of the screen
 * Clicking on help will usually open up a sticky panel over the UI offering one or more help options
 * Users are often able to search and view top help topics within the in-context help pane
 * In-context help will also link users to the dedicated/primary help center/forums
 * General/site-wide Help is usually a primary navigation option as well, and may also enable access to chat/feedback within the UI
 * Indicators of privacy and security also often shown in the expanded help UI


 * Mobile (app/web) versions typically do not have help accessible in-context but accessed as a primary navigation item that opens separately

Types of help offered in-context


 * Link to a Help Center / Help Desk
 * Top FAQs listed for that particular context
 * Live chat
 * Video/Tutorials
 * Guided tour links
 * History of previous help queries
 * Community forums - used in a couple of places where there is less expectation of immediacy in response times and level of ‘service’
 * “Report a bug” - for users to send feedback about unexpected behaviors/bugs, often with the option to include a screenshot of the UI. Implicit expectation is the user should not to expect a response.

Features of Chat/Q&A in help


 * Users are able to email questions using the chat pane when there is no “Live” agent is available
 * Users are given feedback on response time windows and where they can expect answers
 * Voice and tone of chat is friendly and personable, sometimes with emoji and gif options in chat.
 * Users likely expect a level of service, as chat is typically provided by paid customer service reps.
 * Privacy links and information about how chat history is managed is clearly shown
 * Frequently asked questions/topics common for the particular context is often presented in the same UI as an less engagement-heavy help alternative for users
 * Automated answers / “Answer bots” are sometimes offered first to try to resolve the issue before users are given the option to post their question

Review of similar Mediawiki features
As we discussed ideas for the help pane, several WMF staff reminded us that two similar-sounding features had been worked on in the past: MoodBar and Article Feedback. Those features (though no longer in use) both gave users an in-context tool for providing information, and so we think we can incorporate learnings from them. The details of this work are on this task, and the main takeaways are:

Article feedback tool


 * Potential for account creation and editor activation - anonymous users who start an edit may be prompted to create an account when asking for help so that they can get feedback from the “Help team”.
 * Provide more upfront help options prior to allowing submission of free-text comments and questions - Per findings from the Article Feedback Tool, making it too easy to submit unstructured and out-of-context comments about articles leads to a high degree of noise for moderators. Whilst our hypothesis is that users who are in the editing context and seeking help for a specific task may be less likely to submit un-useful questions, providing more self-directed help alternatives upfront may further reduce volume.
 * Mechanisms to provide context to comments – The lack of context to comments in AFT was a main point of dissatisfaction for editors. For in-context help, it would be ideal if users submitting a question or comment would be able to denote where in the article or UI they would like assistance – for example being able to submit a screenshot along with their question, or being able to highlight the section related to their comment.
 * Making interactions into actual edits - This tool created a separate queue of work for experienced editors to deal with, that they couldn't manage through their Watchlists or RecentChanges, and current curate with existing processes for removing damaging content. It is important that any additional traffic we create can be managed through existing systems, which is done most easily if interactions with our feature are done as posts on wiki pages.

MoodBar


 * Capturing email for responses is an effective option – As shown in the MoodBar experiment, email notifications is an effective means of engaging new editors.
 * Clear, prominent call to action for new editors to ask for feedback/help - per high level findings, the addition of a tooltip drawing attention to the MoodBar significantly increased its use.
 * Tracking the perceived helpfulness of responses is important - It would be useful for us to track similar new user perceptions of feedback, since a poor experience from receiving unhelpful advice has been shown to negatively impact editing.

Resources
While a lot of communities don't have a lot of experience concerning Help desk, Community relations have gathered on a page with some best practices that would help community to have more successful collaborations with newcomers.