Growth/ヘルプデスクにフォーカス

Growth

Growth 機能

ツールを使う

コミュニティ向け

更新情報

Growth チーム

Phabricator で追跡中
タスク T206711

このページではGrowth チームが担当する「ヘルプデスクにフォーカス」プロジェクトを説明し、主なアセットや設計、意思決定を載せてあります。 進捗状況に関する定期的な更新情報は主にGrowth チームの更新ページにあり、このページには大がかりな、あるいは詳細な更新情報があります。

Focus on help desk Make it easy for new editors to ask questions グループ: Growth 開始: 2018-10-01 チームのメンバー: Stephane Bisson (software engineer), Benoît Evellin (community relations specialist), Elena Tonkovidova (QA engineer), Kosta Harlan (software engineer), Morten Warncke-Wang (data analyst), Rita Ho (senior user experience designer) バックログ: #T206711 リーダー: Roan Kattouw 管理者: Ryan Kaldari (engineering), Marshall Miller (product), Jazmin Tanner (program) 更新: Most updates posted here.

ヘルプパネルとはこのプロジェクトを支えるために開発された機能で、詳細はこのページで説明してあります。誰でもテスト ウィキペディアでヘルプパネルを実際に試用でき、アカウントを登録したら個人設定/編集を開いてヘルプパネルを有効にして、どこかのページで「編集」ボタンを押してください。

2019年9月時点で試行結果の分析を完了、ヘルプパネルは新規参加者の活発化にも定着率向上にも影響しなかったことが示されました。 それにより、この機能は今後、反復作業を進めないことに決定、代わりに見込みのある新規参加者ホームページならびに新規参加者タスクの両機能に集中する予定です。 試行結果の詳細はこちらをご参照ください。

ヘルプパネルの見た目、フランス語版（画面キャプチャ）

閉じた状態のヘルプパネル（画面キャプチャ）

ヘルプデスクに質問を投稿する（画面キャプチャ）

現状

• 2019-09-30: ヘルプパネルの試行を終了、要点を公表。
• 2019-07-22: A/Bテスト中、アラビア語版ウィキペディアに実装したヘルプパネル。新規参加者の半数には非表示。
• 2019-03-26: 先行指標に関する導入時の報告 を公表。
• 2019-03-04: ヘルプパネルには名前空間ごとに関連のあるページを表示させた。ヘルプとそのトークページ、ウィキペディアとそのトークページ、利用者ページとそのトークページなど。
• 2019-02-28: A/Bテスト中、ベトナム語版ウィキペディアに実装したヘルプパネル。新規参加者の半数には非表示。
• 2019-02-14: チェコ語版と朝鮮語版ウィキペディアの被験者グループで実装した検索機能。
• 2019-01-11: A/Bテスト中、チェコ語版と朝鮮語版ウィキペディアに実装したヘルプパネル。新規参加者の半数には非表示。 対象ウィキ群でヘルプパネルから質問を閲覧する方法は、それぞれのヘルプデスクを参照してください。
  • チェコ語版ヘルプデスク
  • 朝鮮語版ヘルプデスク
• 次：利用者の行動をうながす多段階の機能を開発中で、実際に質問を投稿したり、検索結果の質を高めたり、またヘルプデスクの返信をちゃんと読む確率を上げることまで目指せたらと考えます。

実験の結果（2019年9月）

• 新規参加者向けのヘルプパネルは2019年1月に初めて実装し、同年9月時点でそのデータ分析を終えて影響力の検討準備ができました。これは概要であり、より詳細な分析結果は公開の準備中です。
• 概略としては、ヘルプパネルは活動（実際に編集作業をしたかどうか）あるいは新規利用者の定着率（編集のためにまたウィキを開いたかどうか）の増加を 示していません。期待外れの結果ではありますが、今後も成果のありそうな機能を何種類か実験していくつもりです。
• ヘルプパネルはごくわずかですが、実際に編集量（編集の回数）に変化を もたらしました が、結果とは衝突が見られます。編集回数は新規参加者の初日こそ増えたものの、その後の2週間で減少しています。
• 全般として、今のところはヘルプパネルがなぜこう言う結果を生んだか原因はまだ見つからず、仮説は複数あり今後の検討課題です。一例として、ヘルプパネルは編集の仕方を解説しており、新規参加者が最初の編集を始める気持ちになるだろうと期待していました。 可能性として、かえってややこしい説明が多いと受け取られ、新規参加者に読むのがめんどくさいとか、難しそうと思わせてやる気を失わせたとも考えられます。
• たしかに私たちのチームでは新規参加者の定着と活動量を増やすことが究極の目標であり、また今回の観察によると新規参加者はかなりの率でヘルプパネルを開き（20%）、開いた人は使っています（50%）。ここから、ヘルプパネルが提供する種類のヘルプの需要はあるとわかりました。
• これらの結果を総合すると、ヘルプパネルが評価指標に良い影響を与えていることを期待していただけに、この結果は残念なものとなりました。 ヘルプパネルの改善案はたくさんありますが、直近の課題としてこれ以上繰り返して開発をしないこと、新規参加者ホームページならびにお勧め編集へ注力することが決まりました。 どちらも初期の結果に期待でき、ヘルプパネルよりもさらに多くの新規参加者を対象にしています。 新規参加者向けタスクのプロジェクトではヘルプパネルを活用し、今後とも Growth チームの取り組む新規参加者の経験に組みこむ予定です。 将来、さらにこの課題を掘り下げる可能性はあります。

要約

編集初学者にとって、編集を始めてみると技術や概念、文化の壁にぶつかることがよくあります。 それぞれの人が固有の質問をかかえ、人間の編集者から回答をもらうと利便性は高まります。 大多数のウィキではヘルプデスクを用意し、編集初学者の質問を受け付けており、そのような場は効果的であると証明され、中でも英語版ウィキペディアには井戸端のほかに「ティーハウス」Teahouse を設けて活用しています（影響力の調査結果はこの論文をご参照ください。） ところが問題は、編集初学者の大部分はヘルプデスクの存在も、どこにあるかも理解されていません -- 初学者個人の利用者ページにはしばしば 「歓迎テンプレート」が置かれてリンクもあるのですが。

仮説を2件、立てました。

• 新規参加者は、簡単に質問ができる方法を得たほうが、ヘルプを受けてみようと考えやすい。
• 新規参加者は、どこでヘルプを頼めば良いかわかっている方が、編集を完了しやすい傾向がある。

これらを受け、「ヘルプデスクにフォーカス」プロジェクトは下記の2つの部分で構成します。

1. 編集初学者をヘルプデスクへ案内します。その方法は4案ありました。相手のトークページに投稿する、バナーを表示、メールでお知らせ、編集作業の文脈にリンクを置く。 そこから選んだのは、編集体験ではっきりと目に入るようにヘルプデスクへのリンクを置いて目立たせ、それを「ヘルプパネル」と呼ぶことにしました。その理由は以下のとおりです。
   • 編集初学者の経験調査から得た知見には、文脈に沿った 手助けをしてもらうことの重要性があります。これはヘルプを探せるリンクの表示につながり、タイミングは利用者がヘルプしてほしい瞬間であり、場所は現在はどこでヘルプが得られるか明確に示していないページも対象に考えます。
   • 未解決の疑問として「質問は本文の流れに沿うのかチャット式か」という発想があり、そのような機能を皆さんが求めているかどうか知る手がかりとなるものです。
2. 編集初学者がヘルプデスクを開くようになった段階で、ヘルプデスク自体の改善に取り掛かり、質問をしやすい場所に変えます。 これにはページ最上部に表示する質問を更新したり、編集初学者が質問した場合に回答がついたと通知したりすることも視野に入れます。

Growth チームは第1段階 (ヘルプパネル) を2018年第2四半期に着手 (Q2、2018年10月 - 同年12月)、条件付きA/B テストの一環でウィキペディアのチェコ語版と朝鮮語版に導入したのは2019年1月11日でした。 この試験は2019年7月までかけて完了させています。 結果を入手する中で、機能の拡張ほか、実装先のウィキを増やしたり第2段階への移行（ヘルプデスク自体の改善）を決断する可能性があります。

賛否のレビュー

当チームの設計者は他のプラットフォーム（SurveyMonkey、American Express、Codecademy）を調べ、それぞれが文脈に沿ったヘルプをどう利用者に提示しているか評価しています（詳細はタスク T206713をご参照ください。）他のソフトウェアから学べる最善手法があり、特にさまざまなソフトウェアを横断する同種のパターンについてはそう判断できると考えます。たとえほかのソフトウェアから発想を取り入れるとしても、あくまでもウィキペディアの特徴である公開性、明確さ、透明性という価値を貫きます。比較対照の報告はこのスライド集に盛りこまれており、主な収穫は次のとおりです。

文脈に沿ったヘルプ UI 群

• 関連性のあるヘルプは通常、画面右下に常置する（ねばっこい）ボタンもしくはタブとして 表示
• ヘルプボタンを押すと、通常はUI に常置されるsticky パネルが開き、ヘルプの選択肢を1件またはそれ以上、表示する
• 利用者は文脈に沿ったヘルプパネルを離れずに、その分野でよく参照されるヘルプのトピックをしばしば検索したり表示できる
• 関連性のあるヘルプは利用者を専用の／代表的なヘルプセンター／フォーラムへ導く
• 一般的な／サイト共通のヘルプさ、常に第一の移動先とする選択肢もあり、さらにUI 内のチャットやフィードバックにアクセスできる方法も要検討
• ヘルプ UI を開くと、個人情報保護とセキュリティの指針もしばしば表示
• モバイル環境（アプリ版・ブラウザ版）では関連性のあるヘルプは提供されないけれども、初期のナビゲーション項目として、（記事内ではなく）別に表示されます。

そのコンテキストに直結するヘルプの種類

• ヘルプセンター/ヘルプデスクへのリンク
• よくある質問で、その文脈に特化したやり取り
• その場でチャット
• 動画/チュートリアル
• ガイド付きツアーのリンク
• 過去のヘルプクエリの履歴
• コミュニティのフォーラム - いくつかの場所に表示され、その場所では対応までの時間に緊急性が低く、また「やってもらいたいこと」のレベルが高くないと予測される
• 「バグの報告」 - 利用者から予期しない挙動やバグに関するフィードバックを送信、しばしばオプションで UI のスクリーンショットも含まれる。利用者は応答を期待すべきではないという暗黙の期待があります。

ヘルプ内にチャット/よくある質問の機能を

• もしその時間帯に「生で参加している」エージェントが不在の場合、 チャットパネルから質問をメールする機能がある
• 利用者は回答を得られそうな場所と返信の時間枠についてフィードバックを受ける
• チャットの雰囲気や態度は親しみが持てて個性を示しやすく、チャット中に使える絵文字や gif 動画のボタンもよく見かける。
• 利用者の側にはやってもらえることのレベルに一定の期待値があり、理由はチャットの相手がカスタマーサービスの有給スタッフであるから。
• チャットの履歴の管理について、個人情報保護のリンクと情報を明確に表示する
• よくある質問および／またはトピックで特定の文脈によく見られるものは、同じ UI に一緒に表示してあり、利用者にとってヘルプの代替手段となり、負担が軽い（読むだけでも済む）
• 自動回答機能／「回答ロボット」が最初に表示される事例は多く、まず問題の解決を試みてから、利用者が実際に質問を投稿する選択肢を示している

以下の各節は今後数週間のうちに大きく変更されるか、技術面に特化した話題あるいはプロジェクトの理解との関連性が低い可能性があります。そのため、翻訳対象から除外してあります。

ウィキメディアの同類の機能を評価

ヘルプパネルのアイデア出しをしている時、財団職員から過去に同類の機能が検討された話を聞きました。MoodBarとArticle Feedback（どちらも現存せず）は情報提供という意味でこちらの開発で参考になると考えます。その点はタスクタスク T206714で担当、おもな参考点は次のとおりです。

Screenshot of Article Feedback Tool

記事のフィードバック・ツール

• アカウントの作成で編集者の活動を促す - 編集作業を手がける利用者が手助けを頼む投稿をしたとき、アカウントを作成すると「ヘルプチーム」からフィードバックが来ると伝え、登録を呼びかける方法があります。
• 自由記述式の質問欄を作る前に、あらかじめヘルプの選択肢を増やしておく - 記事フィードバック・ツール Article Feedback Tool で得た知見によると、記事に対して関連性が低くあるいは構造化していないコメントを楽に投稿できることこそ、仲裁者に無用のノイズを増やすばかりです。 編集自体に関心があって特定のタスクに手助けを求める人なら不要な質問はしないと仮定はしていますが、ヘルプを自分で探せる道すじを用意すると発生件数をさらに減らせる可能性があります。
• コメントに関連性を持たせる機構 – AFT ではコメントに関連性が欠けており、編集者の低評価の核でもあります。関連性に基づくヘルプを実現するには、理想としては質問者やコメント者が自分はどの記事もしくは UI のどの部分を話題にしているか具体的に示す – たとえば質問に画面キャプチャを添えて投稿する、あるいはまた、文章のどこに対するコメントなのか対象部分を強調表示できると役立ちます。
• 実際の編集に対話式に関与する - このツールには別の作業キューを想定し、経験を積んだ編集者が個人の「ウォッチリスト」や「最新の更新」では追いきれない対象、現状のプロセスではキュレーションできないが除去するべき有害なコンテンツを検知します。ここで重要な点は発生するトラフィック負荷の管理を既存システムで行うことで、いちばん簡単な対処法は、私たちが作る関与機能による相互作用をウィキ上の投稿として扱うことです。

Screenshot of MoodBar

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.

Design for help panel

Our evolving designs can always be found in this interactive prototype. These clickable mockups also contain other design ideas for future iterations of the help panel, although some elements in those mockups may be obsolete. To see the latest version of the help panel, edit a page in Beta or Test wiki after having turned the help panel on in your preferences.

The "Comparative review" and "Review of similar MediaWiki features" were critical in the design process because they helped us "dream big" to explore the space of what the help panel could eventually become. Our team mocked up and discussed many ideas that probably will not become part of the help panel unless we see that earlier, simpler versions are successful. First, we are going to work on an initial version of the help panel to be deployed in January 2019.

Initial version

In the initial version of the help panel, we want to answer these questions:

• Will newcomers click on a clear option to get help during the editing experience?
• Do newcomers seem more interested in reading content to answer their own questions, or in asking a question for others to answer?
• Will newcomers take action to write and post a question to the help desk?
• Will the presence of the help panel increase new editor retention?

Therefore, we have decided to include these elements in the initial version, detailed in T206717 and T209318:

• A call to action in the editing context.
• A panel that opens containing links to helpful existing pages.
• The ability to ask a question from that panel, and for that question to be automatically posted to the wiki's help desk.
• The ability to add an email address to their account if the user does not already have one, and to modify their email address if it is not yet confirmed (and then to receive a confirmation email upon submitting).
• The ability to turn off the help panel by clicking through to Preferences.

The mockups below show initial designs for that functionality as of November 2018 (to see the most up-to-date designs, use this interactive prototype). Right now, we will show this only to newcomers (meaning new account holders who are not auto-created). We also know that the wording in the feature is very important here, because it is critical that newcomers understand where and how information they write will be posted, and when and where they can except a reply. These mockups only contain some initial drafting of the wording, and we'll continue to refine it. We are hoping for strong ideas from community members, so please post any ideas on the talk page.

• 
  1) Mockup of initial call-to-action on desktop and mobile
• 
  2) Mockup of help pane initial state on desktop and mobile
• 
  3) Mockup of asking a question in help pane
• 
  4) Mockup of confirmation received after asking a question
• 
  5) Mockup of a question having been automatically posted to a help desk

Business rules for initial version

Below are the current rules we're using to determine who receives the help panel and how it works. These may change as our team and the community continues to discuss and learn from the feature.

• Users: the help panel will be a feature that can be turned on and off in user preferences. When it is deployed in January, it will be turned on to only newly created accounts (not auto-created) from the deployment date forward (except for a control group that will not have the feature). All other users whose accounts were created before the deployment date will have the feature turned off, but will be able to go to their preferences to turn it on if they wish to try it out. We will also be embedding an option to turn the help panel off inside the feature. Our team discussed the possibility of turning the help panel on for all users, but wanted to first learn about how new users interact with it, and we want to make sure not to flood help desks with incoming questions. See this Phabricator task for the discussion.
• Namespaces: the help panel will be available in all namespaces. Our team discussed limiting the feature to only the main article namespace because the help documentation linked in the panel is mostly relevant to that namespace. Ultimately, we decided to make it available in all namespaces so that we can learn in which namespaces people are most commonly looking for help -- we know that new editors struggle to edit the Talk namespace. We will also encourage communities to develop documentation relevant to editing other namespaces (particularly the Talk namespace) so that we can make those links available in the appropriate namespaces. See this Phabricator task for the discussion.
• Headers: the help panel will automatically post users' questions to their wiki's help desk, and will automatically generate a header for that post. We have decided that the header will include the title of the page from which the question originates (with a link), as well as a timestamp to distinguish it from questions that may have originated from that some page. Users will be able to decline to include the title in their header, if they consider it sensitive. See this Phabricator task for the discussion. Our preference is to number the posts instead of including a long and redundant timestamp, but that will require additional engineering work for a future version.

Wording for initial version

The wording for the help panel is complete, and the current state can be seen in the interactive mockups. Some of the most important things we have been considering in the wording are:

• How to make it clear that by asking a question in the help panel, users will be posting in public?
• How to encourage users to add their email address, since that is the best way for them to find out when they get a response to their question?
• How to give users the option of excluding the title of the page they're editing from the automatically-generated header in the help desk, if they want to keep that private?
• How to correctly set expectations about how quickly a user can expect a help desk response?
• What to include in the automatically-generated header in the help desk?

Future versions

In determining the initial version of the help panel, many ideas for features were set aside to be evaluated later on. Many of them are visible in the initial mockups here. The following is a list of capabilities that are either being built for the help panel, or may be built in the future:

• Nearer term
  •  - Search: the ability to search help pages. Users found this option appealing during testing, and it was built in T209301 and deployed on 2019-02-14.

    

    Wikipedia help panel feature in Korean Wikipedia, with the "search" functionality in use.

  •  - More contexts: since help desks have not yet been overwhelmed with incoming questions, we are thinking of exposing the help panel to newcomers in contexts beyond editing -- perhaps while they are viewing pages in the Help or Wikipedia namespaces. We thought of this because the EditorJourney analysis showed that large portions of newcomers viewed pages in those namespaces during their first 24 hours. Currently being built in T215664.
  • Greater affordance: so far, it looks like a minority of users who see the help panel button actually open it up. We could attempt to make it more visually obvious that it is a recommended place to start.
  • - Vary links with context: the help panel contains five links to help pages, and about half of users that see them click on one. Different links are probably valuable in different contexts. For instance, there might be some links for visual editor and some for wikitext. Or some that are helpful on a talk page and some on an article page. This is being worked on in T211117.
• Longer term
  • Live chat: allowing newcomers to immediately chat with experienced editors right from the help panel. This would be a major project with many challenges. See this page for our notes so far.
  • Suggested answers: many questions that users asked may have already been answered before, and we might be able to provide suggested answers as users type. This would be relevant once many more questions have been asked. Ticketed in T209327.
  • Feedback on responses: newcomers may find the responses to their questions more or less satisfactory. By allowing newcomers to rate their responses, we may increase higher quality responses, and make it possible to surface the best ones to future newcomers. Ticketed in T209332.
  • Marking question context: newcomers may have questions related to very specific elements of the editing experience. This idea would allow them to indicate exactly where on the page their issue is occurring. Ticketed in T209328.
  • Templated replies: research shows us that the tone of a reply to a newcomer can make a difference in whether they edit again. We may be able to help people answering questions to format their replies in a nurturing way. Ticketed in T209331.
  • Anonymous editors: though our team is focused on registered newcomers, it is possible to make the help panel present for anonymous editors, though it will be more difficult for them to find out that they have received a response. Ticketed in T209325.

User testing for help panel

During the week of November 26, 2018, we used usertesting.com to conduct eight tests of the help panel interactive prototype with internet users unaffiliated with the Wikimedia movement. Four tests were done on desktop and four were done on mobile. In these tests, respondents are compensated for trying out the mockups, speaking aloud on what they observe, and answering questions about the experience. As our team's designer described on the Phabricator task, the goals of this testing were:

1. Gauge the discoverability of the help pane call to action and help pane
2. Identify improvements to the usability of the help pane:
   • Do users understand they can edit and use help links at the same time?
   • Are users able to successfully follow the steps to post a question?
   • Is there anything users that would like to be able to do from the help pane that they are missing?
3. Gauge user reactions to the help pane and expectations of how their questions will be answered.

Summary of findings

• All users found the help panel contents to be very useful in getting help for editing.
• No one had issues with having the article title included in the question.
• Most participants would post a question to the help desk as a last resort after trying to help themselves through clicking on links, with two people saying they would likely not post at all as they would want a more immediate response.
• One user said they would more likely just Google the editing help over the options shown.
• Whilst it was understood that the Help desk would be answered by volunteers, many participants wanted more reiteration and clarity of expected wait times.
• Clear layout of options, shown in the order in which almost participants said they would seek for help.
• Discoverability of the help panel call-to-action may be reduced in the case when the user is using the Visual Editor or wikitext2017 editor because those editors have a competing “?” icon.
• One user suggested having an example question in hint text.
• One user wanted more information shown about when their question was viewed and by how many people.
• Two users mentioned the help recommendations shown on the Help Desk seemed disjointed from what was shown in the help panel.

Recommendations (not all of these will be implemented)

• Prioritize the Searching help task inside the help panel.
• Provide clearer times on both the review and confirmation screens for when a newcomer should expect a response from the help desk.
• Add a more specific help question sample in the placeholder/hint text.
• Experiment or A/B test alternative text on the initial “Ask a question” call-to-action.
• Show a first-run tooltip/pulse indicator to highlight the new help panel.
• Add an additional menu item to existing editing toolbar help on Desktop VE or Wikitext2017 which opens the help panel.

Measurement and results

Measurement and experiment plans

High-level questions

These are the main things we want to find out from the help panel.

1. Does the presence of the help panel lead to questions being asked and answered?
2. Does the presence of the help panel increase editor activation (making their first edit)?
3. Does the presence of the help panel increase editor retention (coming back to edit again)?
4. Does the presence of the help panel increase the proportion of constructive edits?

Controlled experiments

See this page for the detailed experiment plan.

In order to understand the help panel’s impact on editor activation and retention, we propose a six month A/B test. During that test, 50% of new registrations on target wikis will have the help panel enabled by default, and 50% will have it disabled. We anticipate that we will be able to detect 10% changes in activation after about one month, and 10% changes in retention after about six months. We are likely to be running other experiments on the target wikis at the same time, for example, testing variants of our welcome survey. Therefore, assignment of users to treatment and control groups for all tests will have to be coordinated so that we ensure the distributions are not biased.

Specific measurements: quantitative

These are specific measurements that help us answer the high-level questions. These are measurements we will be able to do programmatically. See this EventLogging schema for the exact details on the data that is being recorded and stored.

1. What is the context the user is in when they start interacting with the help panel?
2. What percent of users open the help panel?
3. What percent close the help panel without using any part of it?
4. What percent click one or more of the help links?
5. How far do users go in the workflow of asking a question?
6. What percent of users turn the help panel off?
7. What is the average length of questions asked via the help panel?
8. What percent of users click any of the links in the final confirmation page of asking a question?
9. What percent of users who post a question return to view the answer?
10. Does interacting with the help panel alter the probability of abandoning an edit session?
11. What percent of users use the help panel more than once?
12. Are newly registered users with an email address likely to return to view the answer to their question?
13. What percent of newcomers that had no email address add one when asking a question?
14. What percent of newcomers confirm their email address (within 48 hours) after asking a question?
15. What percent of newcomers ask a question without an email address?
16. What percent of newcomers submit a question without including the title of the page they were editing?
17. How does help panel usage vary with welcome survey responses?

Specific measurements: qualitative

These are specific measurements that help us answer the high-level questions. These are measurements we will need to do manually, by counting and reading the contents of help desks.  Doing these programmatically would be an inordinate amount of work.

1. What percent of questions get answered?
2. How quickly do questions get answered?
3. How often do newcomers edit the question they asked?
4. What kind of questions do people ask and which ones are more likely to get answered?

Usage counts

After about two months of being deployed to half of new accounts in Czech and Korean Wikipedias, and two weeks of being deployed to half of new accounts in Vietnamese Wikipedia, these are the numbers (as of 2019-03-28):

• 3,343 users have seen the help panel button
• 566 users have opened up the panel
• 225 users have clicked a link in the panel
• 51 have run searches
• 51 users have submitted a question to the help desk (Czech: 34, Korean: 8, Vietnamese: 9)

Leading indicators

The help panel's experiment plan defines a set of leading indicators that the team evaluates in order to determine whether the feature is behaving as expected, and whether there are any urgent problems that need to be solved.

Using a month of data, we published an initial evaluation of leading indicators here. In summary, the help panel seems to be behaving in a healthy way, with good numbers of newcomers opening and using it. The analysis identified a couple areas for improvement that the team has taken action on:

• Because we wanted to increase the number of newcomers who open the panel, we started showing it in additional contexts on March 4, 2019. Newcomers now see the help panel when reading in the Wikipedia, Help, and User namespaces.
• Because we saw that in Korean Wikipedia very few users ask questions, we built the search feature so that newcomers would have an easier way to find helpful information on their own.

Experiment results

See results above.

Resources

• More on this feature: The help panel contains a link to learn "More about this feature". That link will lead to this page, which will hopefully answer user questions about how the feature works. Feel free to translate it into your language!
• Best practices: Because many communities don't have a lot of experience concerning help desks, the WMF Community Relations Team has assembled on a page with some best practices that can help communities have more successful collaborations with newcomers. Please feel free to translate that page into your language!