ユーザビリティベンチマーク

Nielsen/Norman Groupによると、ユーザビリティまたはユーザー体験のベンチマークとは、「意義のある標準と比較した相対的なパフォーマンスを、指標によって測ることでプロダクトまたはサービスのユーザー体験を評価するプロセス」です。ベンチマークには相当な時間と労力が必要ですが、同じ量のデータと同じ粒度の洞察を得られる代替のリサーチ手法はほとんどありません。このページでは GitLab でユーザビリティベンチマークに取り入れるプロセスと考慮事項を説明します。

ユーザビリティベンチマーク調査を行う理由

ユーザビリティベンチマークでは、関連するワークフローの集合を個別タスクに分解し、複数の観点からその使いやすさを測定します。これにより、具体的なペインポイントと改善領域を示す、豊富な定量・定性データが生成されます。これらのペインポイントはプロダクト全体のユーザビリティを向上する実行可能な洞察に変換できます。ベンチマーク調査により、チームはプロダクトを改善するための、検証済みで粒度の細かい提案を得られます。

ベンチマークを行うタイミング

ベンチマークは、縦断的な定量比較を生成する有用な方法です（例: ユーザーインターフェースの大きな変更前後で、タスク完了にかかる時間を追跡する）。ベンチマーク調査を複数回実施する利点から、ベンチマークは単発の活動ではなくリサーチプログラムと捉えることが有用です。GitLab ではこのように考える傾向があります。

GitLab でのベンチマーク

ベンチマークは、リサーチリードに高い厳密さを求める、徹底的で時間のかかる取り組みです。このページでは、ベンチマークの品質と一貫性を保証し、新しい取り組みの「立ち上げコスト」を削減するためのガイドラインとベストプラクティスを示します。

構成要素

ベンチマーク調査には、調査を成功させるために必要な基本要素という、似た「骨格」があります。通常は次のとおりです。

• プロトコル: 実施する各セッションの設計図です。調査の紹介と説明のために各参加者に話す内容、質問とその順序を含みます。通常、各セッションを行うスクリプトとして機能します。
• タスク: 参加者に実施してもらい、調査で測定する個別タスクです。
• 指標: 調査開始前に、収集するデータ、報告する指標、方法論の根拠を明確にします。ユーザビリティベンチマークでは、他のベンチマークで使用している同じ指標を報告することが重要です。ただし、価値を加える場合はステージレベルで追加指標も報告できます。
• タイムライン: ベンチマーク調査の計画、実施、分析には時間がかかります。自分とステークホルダー向けのタイムラインを作ることで、調査を軌道に乗せ、チームに情報を共有できます。

ベンチマーク調査の計画

ベンチマーク調査を主導する際は、プロトコル、タスク、指標、タイムラインについて全員が合意するよう、Product Manager (PM) や Product Designer (PD) を含む複数のステークホルダーと調整します。主導する他の UX リサーチプロジェクトと同様、テスト計画を UX Research チームと共有してピアレビューを受けることを忘れないでください。

初期の計画段階は、調査の残りを成功に導くために重要です。計画の最初の数週間を最大限活用するには、フィードバック提供方法をステークホルダーと話し合います。非同期でフィードバックを得る場合は、交渉できない明確な期限を設定します。期限が守られない場合は、リサーチタイムラインを維持するため、予定された会議のような同期コミュニケーションに切り替えてください。

サンプルと採用

ユーザビリティベンチマーク調査の採用時はサンプルを考慮します。決まったガイドラインはありませんが、通常は次の要素の参加者をバランスよく含めます。

• 調査対象領域に関連するペルソナ。対象ユーザーでテストするためです。
• 参加者が勤務する企業規模。通常行うタスクの種類や、Enterprise 規模での習熟度に影響します。
• 参加者が直接所属するチーム規模。All-in-One チームの人はプラットフォーム全体の経験が多く、タスクにより熟達している可能性があります。チーム規模は GitLab でのユーザーの操作に大きく影響します。
• 参加者が勤務する企業の SaaS と自己管理型のライセンスタイプ。自己管理型ユーザーは古い GitLab バージョンを利用しており、パフォーマンスに影響する場合があります。
• 個々の参加者の GitLab 利用期間。経験豊富な人はタスク完了を助ける背景知識があります。ワークフローやタスクに応じ、新規またはまったく新しいユーザーを明示的にサンプリングすることがあります。一般に混在させるのがよい実践です。
• 参加者が勤務する企業の業界分野。業界によりタスクへの取り組み方が異なる場合があります。
• GitLab 利用期間を除く、ロールにおける個人の経験。ロール経験が多い人は、タスク完了に異なる背景知識を持ち込みます。
• 参加者が利用するインターフェースの好み。好みにより GitLab の Web UI またはターミナルを利用し、タスクへの取り組みに影響します。

これらのいずれかの要素の参加者に偏りすぎないようにします。例えば、自己管理型ライセンスの参加者だけをサンプリングしないでください。採用 Issue を作成する際は、Research Operations Coordinator が採用努力を最も適合させられるよう、ベンチマークに理想的な対象サンプルを説明します。

プロトコル

各プロトコルは調査のトピックと詳細に合わせますが、類似したセクションを含むことがよくあります。通常、以下を扱います（多くはすべてのモデレーターあり調査に共通します）。

• 参加者を歓迎し、協力に時間を割いてくれたことに感謝する。
• 録画と、GitLab 内で録画を共有することへの同意が提供されていることを確認する。
• 参加者がここにいる理由を説明し、調査の概要を示す。
• 日常、GitLab の利用期間、リズムに入るためのその他の「簡単な」質問をする。
• セッションを説明する。ベンチマークでは、各タスクの実施方法、推奨または非推奨の行動（ベンチマークでは通常思考発話をしないなど）、参加者が一緒の時間に期待できる構造を示します。

Usability Benchmarking テンプレートには、調査に利用できる定型文があります。

タスク

調査のタスクを選択する際のガイドラインを示します。

• すべてのタスクをペルソナのいずれかの Job To Be Done に関連付ける。
• SUS フィードバックをレビューし、ユーザーが否定的なフィードバックを提供する領域を特定する。これは 2 つの理由で有用です。
  1. タスク作成を助けるため - SUS や他のフィードバックメカニズムでペインポイントが特定された場合、タスクでさらに探索できる機会を探すのがよい実践です。これにより、ペインポイントを直接見て、詳細を理解できます。
  2. データの三角測量のため - ベンチマークデータを分析した後、タスクを通じてペインポイントを特定します。SUS データを使用して、ベンチマークで特定したペインポイントが SUS フィードバックにも見られたかを理解できます。三角測量は洞察を強められます。例えば「このペインポイントは Q1 の SUS フィードバックでもテーマでした」と述べられます。ベンチマークのペインポイントが以前に SUS フィードバックで特定されなかった場合も、指摘してさらに探索する価値があります。
• 個々のタスクをワークフローごとに、合理的な順序でグループ化する（例: 「Issue を開く」タスクの前に「Issue を閉じる」タスクを置かない）。
• タスクの複雑さの適度な中間点を決める。簡単すぎても意味がなく、複雑すぎるとワークフローの特定部分を測定しにくくなります。
• すべてのタスクを進められるよう、各タスクに「打ち切り」時間制限を設けることを検討する。
• 参加者にタスクを説明するときは注意する。意図せず正解に導かないよう、正確だが UI テキストと完全には一致しない言葉を使う。
• 各タスクを自分で実行し、「ハッピー」または期待される経路を記録する。不確かな場合はステークホルダーに確認を得る。
• タスク指示をテストするため、1〜2 名のパイロット参加者を採用し、ユーザーが必要なことを十分に理解できない場合は修正する。
• 各タスクの完了条件を列挙する。これは完了を記録する際に一貫性を保つためのチェックリストになります。
• ユーザーがタスクを完了できるすべての方法を特定する。GitLab では同じ結果への複数経路が提供される場合があります（例: UI の 2 つの別ページでデプロイを承認でき、どちらもタスク成功と数えます）。
• 優先度または重大度を計算しやすくするため、各タスクに重みまたはポイントを付けることを検討する。

タスクリストに書いた単一タスクの例を示します。

打ち切り時間に関する注記

タスクに打ち切り時間を割り当てる厳格なルールはありません。次の方法があります。

• 自分でタスクの完了時間を測り、専門家であれば初心者にかかる時間のガイドラインとして 3 倍にする。
• タスク時間の概算を得るために KLM (Keystroke Level Modeling) 計算を行う。
• 打ち切りを適用せずパイロットを行う。タスク時間を測定し、ベースラインにします。迅速に完了したタスクには時間を追加し、長すぎたと感じたタスクから時間を引くことを考慮する必要があります。

重みに関する注記

重み付けの一つの方法は、完了条件に必要なステップ数を見ることです。上の例では、完了条件に 5 ステップがあり、割り当てた重みは 5 です。これはタスクの複雑さの代理として重みを設定します（調査に適している場合も適していない場合もあります）。通常、計算で重みを使用するのは、総括的指標を報告する乗数としてです。

簡単な例:

• タスク A と B の 2 つを取ります。
• タスク A のスコアは完全な 20/20、タスク B のスコアは低い 10/20 です。
• タスク A の重みが 1、タスク B の重みが 2 だとします。この場合 B は A の 2 倍重み付けされます。
• 組み合わせたタスクの成績を採点するときは、各スコアに重みを掛けます。A は 20/20 のまま、B は 20/40 (10 2 = 20、20 2 = 40) になります。
• 次にタスクの合計を加算し、最終的な加重スコアを得ます (20 + 20 / 20 + 40)。
• タスク B の重みが大きく、B のパフォーマンスが悪いため、総合スコアは非加重平均の 30/40 または .75 ではなく 40/60 または .67 です。

指標

次の指標と定義が、GitLab のベンチマーク方法の中核です。

採点と指標に関する注記

参加者がタスクの完了条件を満たさない場合:

• その参加者のその特定タスクについて、タスク時間を入力しない。各タスクの完了に成功するまでの時間を測りたいからです。
• CES スコアとエラー数は含める。タスクを完了したすべての人の体験を理解したいからです。
• 参加者が完了したと考えていても完了条件を満たしていない場合、タスクを不完了として記録する。
• 参加者が完了していないと考えていても完了条件を満たしている場合、タスクを不完了として記録する。

タスクごとの指標では:

• 明確な別の理由がない限り、すべての指標を 95% 信頼区間で報告する。
• 完了率の信頼区間には調整済み Wald 計算を使用する。
• タスク時間の信頼区間には自然対数計算を使用し、推奨されるベストプラクティスとして中央値ではなく幾何平均を報告する。
• エラーを正確に定義し数えることは難しく、常に実施する必要はありません。実施する場合は、タスク内のエラー定義を非常に明確にする必要があります。
• エラー率を収集する場合はタスクごとに報告する。同じ参加者がタスクの同じ部分で複数のエラーを記録した場合（例: 同じ誤ったリンクを複数回クリック）を含め、そのタスクで可能なすべてのステップに対してエラーを数えます。エラー率が 100% を超える場合があります。
• Customer Effort Score (CES) では、サンプルが 30 未満なら母標準偏差を使用して信頼区間を計算します。N が 30 より大きい場合は標準偏差計算を使用します。両方の選択肢と信頼区間を含む便利な計算機があります。

ワークフローごとの全体成績計算では:

• ワークフロー内のタスクごとの全指標が 1 つのカテゴリ（例: 「Fair」）にある一方で、計算スコアが別の成績カテゴリ（例: 「Good」）にある場合、全体成績は指標と同じカテゴリで表します（例: 「Fair」カテゴリの下位指標があるワークフロースコア 80 も「Fair」に分類します）。

重大度の計算

各セッションで、このハンドブックページで定義される、そのユーザーの体験を最もよく表す重大度番号をタスクごとに記録します。この方法論は広く知られた Nielsen/Norman systemと似ていますが、逆です（私たちのシステムでは低い数字ほど重大です）。

不完了タスクの重大度は 1 と評価します。非常に苦痛な完了は 2、やや苦痛な完了は 3（以下同様）と評価します。ユーザーがユーザビリティ上の問題にまったく遭遇しない場合は 5 と評価します。

各タスクの重大度スコアを平均し、次のスコアに従って全体の重大度を割り当てます。

例えば、調査に 10 名の参加者がいるとします。タスク A で各実施の重大度スコアが 1, 4, 1, 2, 2, 3, 4, 5, 1, 3 の場合、合計は 26 です。10 で割ると平均 2.6 となり、そのタスクの重大度割り当ては 2: Critical です。

タスクごとの全体成績計算

各タスクについて、次の基準で最終成績を計算します。

1. 各タスクの完了数から始めます（例えば、20 名の参加者から 15 回の完了がある場合があります）。
2. そのタスクの平均 CES スコアを完了数に加えます。（平均 CES が 5/7 なら、5 + 15 = 20 です）。
3. 次に、そのタスクの平均重大度スコアを加えます。（上の 2.6 を使用するとスコアは 22.6 です）。
4. この数を可能な合計ポイントで割ります。ここで可能な合計は参加者数 (20)、可能な最大 CES スコア (7)、可能な最高（最良）の重大度スコア (5) の合計です。この場合 20 + 7 + 5 = 32 です。例では 32 点中 22.6 点で、22.6/32 = 0.70 です。
5. 結果に 100 を掛けます（小数から変換するため）。したがって 0.70 * 100 = 70 です。
6. 文字評価のルーブリック（90〜100 = A、80〜89 = B、以下同様）を使用して最終成績を得ます: 70 = C。

上記の例を表にすると次のとおりです。

SUS Companion Analysis

上述のとおり、ベンチマーク調査で特定したペインポイントをステージの SUS 自由回答と三角測量すると、SUS 自由回答のどの割合に対処するかを理解して、チームが優先すべきペインポイントを特定するのに役立ちます。

ベンチマーク調査の調査結果をステージの SUS 自由回答と三角測量するには、次の手順を取ります。

1. 分析に使用するステージの自由回答セットを集めます。
2. 肯定的な内容だけの自由回答（例: 「ci ではかなり滑らかです」）と、情報にならないほど短いもの（例: 「ci」）を除きます。
3. 自由回答の 25% をランダムにサンプリングしてカテゴリを作成します。
4. 各タスクと UX テーマのベンチマークペインポイントのリストから始め、Learnability や Documentation のような新しいテーマを取り込むため必要に応じカテゴリを追加します。複数テーマを反映する複雑な自由回答は別々に分割します。これにより、異なるテーマに一致する自由回答の割合を表すために必要な、相互排他的な方法でカテゴリを適用できます。
5. 分類できない自由回答には NA（not applicable）の一般カテゴリを用意します。すべての自由回答がベンチマークのタスクやテーマと一致するわけではありません。
6. カテゴリを作成した後、分析に含める自由回答のサンプル全体に適用します。これにより各自由回答で可能なすべてのカテゴリを考慮したことを確認できます。
7. ベンチマークタスクとテーマに一致する自由回答全体の割合、各テーマ、タスク、ワークフロー、NA カテゴリのもの、観察した追加カテゴリ（例: Learnability と Documentation）を、「SUS Companion Analysis」というベンチマークレポートの付録に報告します。

実行可能な洞察とラベル

UX Researcher とそのチームは、調査結果に対処するために取る次のステップを明確にする問題である実行可能な洞察を特定します。

実行可能な洞察には次のラベルを付ける必要があります。

• Usability benchmark
• 調査対象のセクションとステージを特定する Section::Stage スコープラベル
• Actionable Insight::Product change または Actionable Insight::Exploration needed
• 注: Actionable Insight::Product change では各 Issue に重大度ラベルを適用する必要があります。
• チームが優先順位を把握できるよう、ステークホルダーとともに各実行可能な洞察の重大度レベルを評価することも役立ちます。上記のタスクレベルの重大度評価を使用して、各実行可能な洞察の重大度レベルを属性にできます。

タイムライン

ベンチマーク調査の準備と実施には時間がかかります。以下は典型的なベンチマークプログラムを開始して最初の調査を実施するサンプルタイムラインです。

最初のベンチマーク調査では開始から終了まで丸 1 四半期を計画する必要がありますが、時間の投入は週ごとに異なります。セッションを実施する週を除き、この期間にベンチマークだけをリサーチ活動として計画すべきではありません。 注: 同じタスクとペルソナで実施する後続のベンチマーク調査では、このタイムラインを大幅に短縮できる場合があります。

ユーザビリティベンチマークツールキット

新しいベンチマークの立ち上げコストを削減するリソースをいくつか示します。

• スプレッドシートテンプレート - セッションのメモとデータを記録する Google Sheets テンプレートで、一般的に報告する指標用のページと数式が含まれます。
• Google Slides テンプレート - ベンチマークレポートを作成する Google Slides テンプレート。
• Q1FY23 Create Benchmarking の Google Slides - 最初のベンチマーク調査のスライドデッキ。スライドの構造と一般的なプレゼンテーションの流れを確認できます。
• Usability Benchmarking Alignment Workshop 用 Figjam テンプレート - ステークホルダーと Usability Benchmarking Alignment Workshop を実施する Figjam テンプレート。
• ベンチマーク Epic の例
• Neilsen/Norman のベンチマーク - プロセス
• Neilsen/Norman のベンチマーク - 指標

FAQ

Q: ベンチマークは UX Scorecard リサーチとどう異なりますか？

A: 例えるなら、UX scorecard は虫眼鏡でユーザビリティを見るようなものです。ユーザビリティベンチマークは顕微鏡でユーザビリティを見るようなものです。 ベンチマークはより時間を要します。軽量なものではありません。より多くの参加者（約 20 名）とより長い時間（約 120 分）話し、複数の JTBD を対象にし得るより多くのタスク（約 25 個）を実施します。 ベンチマークは同じ指標の多く（さらに多くも）を報告し、N が大きいためその指標は代表性が高い可能性があります。GitLab では業界標準の統計を使用して指標を報告します（95% の信頼区間、完了率の調整済み Wald 計算など）。この意味で、UX scorecard と組み合わせてベンチマークを使用し、これらの調査結果を検証・更新できます。 ベンチマークは単発調査ではなくプログラムとしても意図されています。ユーザビリティ改善の非常に粒度の細かい提案を生成し、十分な提案が実装されたら再度ベンチマークを実行して、時間の経過に伴う傾向を確認できます。

Q: ユーザビリティベンチマーク調査を実施するなら、UX Scorecard または CM Scorecard の調査は実施する必要がありませんか？

A: いいえ。ユーザビリティベンチマーク調査に加えて、UX Scorecard と CM Scorecard の調査も実施する必要があります。3 種類の調査はいずれも、プロダクトに対するユーザー体験を理解するうえで価値があります。

Q: このスコアと UX Scorecard スコア、CM Scorecard スコアをどのように見るべきですか？

A: 3 つすべて（UX scorecard、CMS、ベンチマーク）は全体の文字評価を提供するため、同じタスクまたは JTBD に焦点を当てている場合は、すべての成績が一致するのが理想です。

Q: ユーザビリティベンチマークはどのくらいの頻度で実施すべきですか？

A: これはニーズと、以前のベンチマーク調査からの提案が実装される速さにより変わります。ただし、一般に同じタスクについて年 1〜2 回を超えてベンチマークを実施する理由はありません。

Q: ユーザビリティベンチマークは最新リリースで実施する必要がありますか？

A: はい。ベンチマークは今後の機能のソリューション検証に実施するには重すぎます。以前のリリースで実施することはできますが、収集する時点ですでに結果が無効になっている可能性があります。時間の投入を考えると、これは強く推奨しません。

Q: ユーザビリティベンチマークはどの GitLab 環境でテストすべきですか？

A: プロジェクトの UX Researcher は、UX Cloud Sandboxページの手順に従い、GitLab のクラウドインスタンスを設定し、プロジェクトにサンプルデータを作成できます。パイロット調査を実施するときに、ベンチマーク調査のすべてのタスクを完了するのに十分なサンプルデータがあることを確認してください。#ux-cloud-sandbox Slack チャンネルで助けを求めることもできます。

Q: テスト環境はどの程度複雑／現実的にする必要がありますか？

A: 状況によります。基本的にはタスクリストを確認し、移動する（または参加者が合理的に移動すると予想される）プロジェクトの各領域に何かがあることを確認する必要があります。タスク時間が目的の経路をスキャンして検索することを考慮できるよう、理想的にはそこに 1 項目以上（ファイル、マージリクエスト、コメント、環境、デプロイなど）があります。焦点を当てる領域によって、多くのサンプルデータが必要な場合も、そうでない場合もあります。

Q:プロダクトライフサイクルのどこに位置付けられますか？

A: ベンチマークは、ビルドトラックの「improve」ステージと、検証トラックの「アイデア収集／問題理解」部分をつなぐ空間に位置します。ベンチマークは現在のプロダクトのパフォーマンスを確認する優れた方法であり、サイクルの「測定、学習、改善」部分に適合します。その後「学習」と「改善」の部分が、検証トラックのアイデア収集／問題理解部分への入力になります。したがってベンチマークでは、現在のプロダクトを測定し、既知の問題を検証し、これらの問題に対処またはプロダクトを全体的に改善するアイデアを生成します。 注: ベンチマークは通常のワークフローのやや外側にあります。非常に時間がかかるため、すべての機能や Issue の一部にできる、またはすべきものではなく、同じタスクについて年 1〜2 回を超えて実施すべきではありません。

Q: 達成しようとしているスコアは何ですか？

A: 最初から特定のスコアを目指すのではなく、ベンチマークで本当に見たいのは時間の経過に伴う改善（あるベンチマーク調査から次の調査まで）です。ただし、ベンチマークは指標が多く、確認する「スコア」も多数あります。目標は、各タスクと各 JTBD の全体成績（A〜F、重大度 1〜5）を一目で把握でき、関心がある人には詳細な指標も提供することです。

Q: Product Designer は提案をどのように処理・管理しますか？

A: ベンチマークでは、UX Researcher が多くの「処理」を担います。UX Research チームには実行可能な洞察をより活用する FY23 objectiveがあります。ベンチマークの主な成果の 1 つは、実行可能な洞察または情報的洞察に変換されるプロセスを経る提案のセットです。このプロセスの一部では、実行可能な洞察を「exploration needed」または「product change」カテゴリに分類し、それぞれがこのラベルを持つ Issue になります。

UX Researcher は、ベンチマークの他のすべての調査結果とともに、提案のリストをすべての関連ステークホルダー（特に Product Designer と Product Manager）と共有する責任があります。正確な構造はグループやステージで異なる可能性がありますが、このプロセスの一部にはすべての「product change」実行可能な洞察のコミュニケーションと引き渡しを含める必要があります。その後、チームはこれらの Issue に優先順位を付け、確実に完了させるために協力します（次の質問につながります）。

実行可能な洞察が、より小さく、すぐに達成可能なチャンクに分解されていることを確認することが重要です。実行可能な洞察が大きすぎないことを確認するため、（ワークショップ中がよいタイミングです）チームに、より小さな Issue にどう分解できるかを尋ねてください。

Q: 提案が古くなる（優先付け／実装されない）のをどう防げますか？

A: これは非常に重要な質問です。リサーチチームには、ベンチマークで生成される、Actionable Insight::Exploration Needed（より多くのリサーチが必要）のマークが付いた実行可能な洞察に関するリサーチ優先順位付けの KRがあります。これらの Issue は追加リサーチのために優先順位付けプロセスを通ります。Actionable Insight::Product change カテゴリの提案、つまり Product Designer と Product Manager がより関心を持つ提案には、重大度ラベルを適用するプロセスがあります。一般に Product Designer が「product change」の洞察に重大度を割り当て、UX Researcher が「exploration needed」の洞察に重大度ラベルを割り当てます。プロセスの詳細は、このハンドブックページを参照してください。

Q: GitLab のベンチマークアプローチには競合分析が含まれますか？

A: いいえ、現時点では含まれません。上のたとえを使うと、競合ユーザビリティ評価も顕微鏡のようなもので、UX Researcher は特定タスクときめ細かなパフォーマンスの側面を見ます。競合他社との比較を確認するため、競合ユーザビリティ評価でいくつかのベンチマークタスクを使う可能性がありますが、その作業は現在スコープ外です。競合他社間のパフォーマンスを見る前に、まず自社プロダクトでベンチマークアプローチを導入したいと考えています。さらに GitLab での競合ユーザビリティ評価の最初のイテレーションは、タスクを顕微鏡で見る前に、競合から何を学べるかを見る虫眼鏡として使うことかもしれません。

Q: チームはどのようにベンチマーク調査を依頼できますか？

A: プロセスを始めるため、チームの UX Researcher に相談してください！

Q: ベンチマーク調査のプロトコルについて何を変更できますか？

A: ベンチマーク調査の主な特性は一貫性です。ただし、データによる効率化、提案の共同作業のための結果ワークショップ、Issue／Epic の形作り方、ストーリーテリングなど、多くの方法で柔軟性を持てます。タスクに関する追加データを収集することもできます。取得する指標など、他のことを変更する提案をしたい場合は Google ドキュメントを開始します。Google ドキュメントの提案には、提案する変更、変更の利点、変更の影響、導入する可能性のある懸念、その変更をどう実行できるかを含めます。

ページのソースコードを見る - ページの編集 - please contribute.