System Usability Scale (SUS)

System Usability Scale（SUS）は、コンピューターインターフェースのユーザビリティ認識を測定するために使用される標準化された指標です。現在および過去の SUS スコアは、UX 部門パフォーマンス指標で見つけることができます。

SUS は合計 10 の質問で構成され、これらは肯定的および否定的な方向で構成されています:

1. 私は GitLab を頻繁に使いたいと思う。
2. GitLab が不必要に複雑だと感じた。
3. GitLab は使いやすいと思った。
4. GitLab を使えるようになるには、技術者のサポートが必要だと思う。
5. GitLab のさまざまな機能はうまく統合されていると思った。
6. GitLab には一貫性がなさすぎると思った。
7. ほとんどの人が GitLab の使い方を非常にすばやく学べるだろうと想像する。
8. GitLab は使うのが非常に面倒だと感じた。
9. GitLab を使うことに非常に自信を感じた。
10. GitLab を使い始める前に多くのことを学ぶ必要があった。

各質問の応答スケールは 5 ポイントの Likert 同意スケールです:

これら 10 の質問の後に、*「GitLab を使用しながら、どのような問題やフラストレーションを経験しましたか？」*という 1 つのオープンエンドな質問を続けます。

これらの質問は、プロダクトのユーザーに調査形式で配信されます。

SUS と GitLab

GitLab では、FY20-Q1 に System Usability Scale を採用しました。SaaS と Self-Managed の両方のユーザーに、四半期ごとに 2 回調査を展開しています。これにより、プロダクトの全体的なユーザビリティを理解し、時間の経過に伴う変化を追跡できました。SUS をUX 部門の KPIとして依存し始め、スコアを改善するために複数の OKR 関連の取り組みを進めています。

この強調により、SUS が厳格で持続可能な方法で展開されることが重要です。

SUS の実行

SUS Survey の結果を GitLab で追跡しており、System Usability Scale (SUS) Surveyの現在の結果のエピックがあります。

SUS 指標が信頼性と持続可能性をもって収集でき、ユーザー人口を正確に表すことを確実にするために、FY21-Q4 に以下の要件を持つ SUS 収集の新しい方法を開発しました:

• 持続可能: ユーザーベースを使い果たすことなく、十分な数のユーザーをサンプリングできます。ユーザーは年に 1 回以上 SUS 調査の招待を受けるべきではありません。
• セグメンテーション可能: 関心のあるユーザーのセグメントを事前に定義し、スコアを導きたい任意のセグメントに対して十分な数の応答を収集します（ただし、事前に定義されたセグメントのみ）。ターゲットにしているセグメントを変更したい場合、将来の四半期でそれらを変更できます。
• 検証済み基準: データウェアハウスまたは Marketo から最新データを取得して、ユーザーのプランやアカウントの古さなどを含む適切なユーザーを特定します。
• アクティブユーザー: 特定の期間内の最小使用、または複数のステージの使用を含む、プロダクトの最近の経験があることがわかっているユーザーをターゲットにできます。
• ランダム化: 私たちが定義する基準以外では、招待するユーザーが地理的位置や組織の規模など、特定の方向に偏らないことに自信を持つべきです。

通常の参加者基準

• 最近アクティブ: 過去 30 日間に少なくとも 2 つのステージにわたる 10 のプロダクトイベントの最小しきい値を使用します。「イベント」は、ユーザーが GitLab の特定の領域で何かを行っていることを示すものです。このアプローチには 2 つの目標があります: 複数のステージを使用している人々をターゲットにし、機能とエクスペリエンスのユーザビリティへの限られた露出を持つ人々を排除することです。また、回答者が最近 GitLab を使用し、最近の改善を経験する可能性が高いことを確実にします。
• サンプルサイズ: SaaS ユーザーについては、各コホートの n が 200、合計 n が 800 を目指します。これにより、高い信頼度でスコアを計算できます。

通常のコホート

時間をかけて追跡する以下のコホートを定義しました:

• 有料ユーザー: 有料サブスクリプションに関連付けられているユーザー（そのサブスクリプションが購入されたか、GitLab によってギフトされたかに関わらず）
• 無料ユーザー: 現在有料サブスクリプションに関連付けられておらず、Free プランを使用しているユーザー。
• 経験のあるユーザー: 180 日以上の在籍期間を持つユーザー。
• 新規ユーザー: 180 日未満の在籍期間のユーザー。

これらのコホートは重複するため、必ずしも各コホートに対して 200 の回答を収集するわけではありません。たとえば、経験のある無料ユーザーはFree userコホートとExperienced userコホートの両方に属していると見なされ、両方の割り当てにカウントされます。

Self-Managed コホート

Self-Managed ユーザーの経験が SaaS ユーザーの経験とどのように比較されるかを理解するために、Self-Managed ユーザーの限定的な SUS 測定を四半期ごとに実施しています。これらのユーザーの大部分は Marketo を通じて募集されます。

Self-Managed コホートには以下の基準があります:

• Self-Managed ユーザー: ユーザーが自己申告で GitLab の Self-Managed インスタンスのユーザーであると報告。
• 最近アクティブ: ユーザーが自己申告で過去 30 日間に Self-Managed インスタンスでアクティブだったと報告。
• n = 100: Self-Managed ユーザーは募集が難しいため、Marketo パネルの Self-Managed ユーザーを使い果たさず、適時にデータを取得するために、サンプルサイズを下げたいと考えています。このコホートは、通常のコホートと比較して、より高い誤差マージンを持ちます。

配布

調査ツールである Qualtrics を使用して、メールで調査招待を配布します。回答は懸賞によりインセンティブを提供されます（Promotional Games workflow）。調査を完了した人は、四半期ごとの懸賞で 200 ドルのギフトカード 3 枚のうち 1 枚を獲得するために抽選に入ります。Self-Managed コホートは、限られた人口の応答率を最大化するために、同じレートの 3 枚の 200 ドルギフトカード受賞者でインセンティブを受けます。

希望するサンプルサイズに達するまで、四半期の最後の月に数日ごとにメール配信を開始することを目指します。

回答者が私たちの活動基準を満たすことを確実にするために、すべてのメール配信で新しいユーザーリストをプルします。過去 12 か月間に SUS 調査が送信された人は、リストからスクラブされます。

分析とレポート

会計年度の四半期ごとに SUS の結果を要約し、スコアを計算します。各四半期について、全体的な SUS スコアと、事前に定義されたセグメントの SUS スコアを報告します。同じセグメントについて、各個別の質問の平均スコアも報告します。すべてのレポートと結果は、内部でSystem Usability Scaleフォルダー（internal only）に保管されています。

SUS スコアの計算

SUS は 0〜100 のスケールで採点されます。各質問のスコアを正規化します。肯定的指向の質問については、元のスコアから 1 を引きます。否定的指向の質問については、元のスコアを 5 から引きます。これにより、すべての応答に対して 0〜4 の一貫したスケールが得られます。次に、すべての質問のスコアを合計し、その合計を 2.5 倍して最終的なスコアを取得します。たとえば、ユーザーの 10 の質問への応答の合計が 30 の場合、その合計に 2.5 を掛けて SUS スコア 75 を取得します。

SUS を構成する個別の質問のスコアを計算することは、標準プロセスの一部ではありません。私たちはこれを行って、エクスペリエンスの特定の側面について私たちがどのように行っているかについての追加の方向性のある洞察を得ます。たとえば、システムが一貫していないという質問の平均応答が平均より低い場合、これは一貫性の欠如がさらに調査すべき問題であることを示します。

個々の質問のスコアは、全体的な SUS スコアに使用されるスケールを反映しています。これにより、全体的なスコアに対する個別の質問のパフォーマンスがどのようなものかを理解できます。このスコアを取得するには、正規化された単一質問のスコアを取り、25 を掛けます。たとえば、単一質問への平均応答が 2.5 の場合、その平均に 25 を掛けて、SUS 相当スコア 62.5 を取得します。

SUS スコアの解釈

SUS スコアは 100 ポイントのスケールですが、パーセンテージではなく、そのように扱われるべきではありません。Jeff Sauro は、SUS スコアをパーセンタイルとして伝えることを推奨しています。SUS スコアを報告するときは常に、Sauro が開発した独自のスケールを使用してパーセンタイルと文字グレードを含めます。

SUS スコアの会社目標は次のとおりです: Q4-FY24 までに 73、Q4-FY25 までに 77、Q4-FY26 までに 82。

テーマのコミュニケーション

四半期ごとに、調査回答者からのフィードバックをレビューし、回答を高レベルのテーマにコード化します。これらのテーマを使用して、時間の経過に伴うトレンドを強調し、GitLab のユーザビリティに影響を与える領域をより深く理解します。すべてのチームメンバーがデータにアクセスできるように、調査の逐語と対応するテーマのリストが最初に Google スプレッドシートで共有されます。プロダクトマネージャーとプロダクトデザイナーには、フィードバックをレビューし、GitLab Issue トラッカーで既存または関連する Issue を検索することを推奨します。

ステージ別の SUS 逐語の共有

四半期ごとに、Issue が作成され（Issue テンプレートを参照）、PDM に割り当てられて、自分のステージに該当する逐語を分類します。逐語がステージ別に分類されると、SUS ドキュメント内のステージ固有のタブに自動的に入力されます。ステージ固有の逐語は、その後、指定された Slack チャンネルを通じて配布されます。

ステージ固有の洞察を共有する際は、以下のサンプルメッセージテキストを使用してください:

Hello :wave: - We just completed analyzing the `Q# FY##` System Usability Scale (SUS) data! I wanted to share the verbatim that's relevant to us in the `fill in stage name here` stage. Here's a sampling:

* `Stage UXR to paste example in italics`
* `Stage UXR to paste example in italics`

You can view the remaining `#` quotes here --> `link to the Sheet, on the specific tab`

Let me know if you have any questions or if you're interested in pursuing some of these!

SUS 回答者アウトリーチ

SUS 調査の最後に、回答者が GitLab チームメンバーと自分の回答について話し合うことに関心があるかどうかを尋ねる質問を含めています。プロダクトマネージャー（PM）とプロダクトデザイナー（PD）がフォローアップインタビューを行って、回答者が経験しているユーザビリティの問題をよりよく理解できるようにプロセスを作成しました。このアウトリーチはチームメンバーにとってオプションですが、強く推奨されます。プロセスの詳細については、SUS Responder Outreach ページを参照してください。

制限事項

事前定義したセグメントでのみカットできる

調査応答データを想像できるあらゆる側面でスライスして、予期しない洞察を見つけようとするのは自然です。ただし、その特定のスライスに十分なサンプルサイズがない場合、信頼性の低いスコアを計算する可能性があり、それが誤解を招くことさえあります。これが、調査を配布する前に理解したいセグメントを定義する理由です。これにより、割り当てに到達し、これらのセグメントのそれぞれに対して十分に大きなサンプルを収集できることを確実にできます。これにより、スコアが特定のセグメントを正確に表すことに高い信頼を持つことができます。

SUS は遅行性で不完全な指標

SUS を定期的に展開しますが、それは改善がすぐにスコアに反映されることを期待すべきだという意味ではありません。プロダクト変更を出荷したら、人々はまず私たちの調査が十分な数に達するように十分な数で経験する必要があります。これは、特定の機能の使用状況によって異なる時間がかかる可能性があり、効果的に推定することは不可能です。また、単一のプロダクト変更がユーザーに与える影響を知る方法はありません。多くのユーザーにとって大きな苦痛であることが、調査するユーザーにとっては小さなイライラかもしれません。単一の機能拡張が SUS の増加を促進することを期待すべきではなく、むしろ、時間の経過に伴う持続的な機能拡張が全体的なユーザビリティの改善につながり、それが長期的に SUS スコアを増加させるはずです。

よくある質問

Q: 特定のステージや機能の SUS スコアを計算できますか？

A: SUS は、全体的な意味での GitLab のユーザビリティの測定を意図しています。私たちのユーザーは、必ずしもプロダクトをステージのコレクションとして概念化しません。私たちが行う質問も全体的なレベルでフレーム化されており、特定の機能の使用や感情について尋ねません。したがって、特定のステージのスコアを計算することは、人々が与える応答が特定のステージの使用を反映していると仮定することになりますが、確実に知る方法はありません。

Q: 特定のユーザーセグメントの SUS スコアを計算できますか？

A: 特定のユーザーセグメント（特定のプランタイプなど）のスコアを計算するためには、スコアが有効であり、ランダムな偶然の結果ではないことに自信を持てるよう、十分なサンプルサイズが必要です。ユーザーのサブセットのスコアを計算したい場合、収集を開始する前にそれを事前に定義します。これにより、十分な応答を収集するために募集基準を変更できます。

Q: ユーザーのサブセットのスコアを計算できる十分なサンプルサイズは？

A: この質問に単一の答えはありません。サンプルサイズは、全体的な人口の何人が基準に適合するかに依存します。全体的な人口が大きいほど、サンプルサイズはその人口の割合として小さくする必要があります。サイズ要件を推定するには、サンプルサイズ計算機を使用できます。すでに調査済みの人々で、追加の基準を満たす場合は、サンプル要件を満たすことができることがあります。他の時には、サンプル要件を満たすために、ユーザーを特定的に識別してターゲットにする必要があります。

Q: SUS に関連するオープン Issue を見つけるにはどうすればいいですか？

A: SUS に関連する Issue には、UX 部門ハンドブックのラベルの使用方法セクションに示されているラベルのいずれかが付けられます。最近の SUS 発見と一致するユーザビリティ問題に関連する Issue を見た場合は、自由にラベルのいずれかを追加してください。疑問がある場合は、マネージャーに連絡するか、#ux Slack チャンネルで尋ねてください。

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