カテゴリ成熟度スコアカード

イントロとゴール

Category Maturity (CM) Scorecardは 総括的評価 であり、ユーザビリティテスト（つまり解決策検証）でしばしば測定される個別の改善ではなく、Job to be Done (JTBD)によって定義された全体的なエクスペリエンスを考慮します。この特化したプロセスは、製品の成熟度 を評価する助けとなるデータを提供します。

このプロセスのゴールは、時間とリソースの制約を考慮しつつ、可能な限り客観的にデータを生み出すことです。このため、このプロセスは他のUXリサーチ手法よりも厳格で、考えや言語的なフィードバックよりも測定値に焦点を当てています。

私たちが信頼できるデータを生み出すには、観察された指標と自己報告のユーザーセンチメントに依拠する、主観的判断ができるだけ含まれないデータであるべきです。私たちのゴールは、追加や改善が定量化可能な方法で製品の成熟度にどのように影響したかを見るために、時間とともにデータを比較することです。これを促進するため、私たちはこのプロセスを規範的にし、すべてのプロダクトデザイナーが製品のすべてのカテゴリーで一貫して適用できるようにしました。

留意点

評価が必要なJTBDが、アラートに対応する際の多段階プロセスのように、時間を超えて発生する場合があります。これらのケースでは、CM Scorecardシナリオでの JTBDの次のフェーズに移るときに、’(一定の時間) が経過した’ というフレーズを含めるのが適切です。

時折、チームはCM Scorecardから驚くべきことを学ぶ状況に直面します。例えば、この単一のリサーチイニシアチブのスコアは成熟度を上げるのに十分高いにもかかわらず、発見に基づいてまだ準備ができていないと信じる場合などです。この場合、プロダクトマネージャーとプロダクトデザイナーは、成熟度を変更する前に根本的な問題に対処するための良い判断を使い、その決定をステークホルダーに伝えるべきです。

質問、改善の提案がある場合、またはこのプロセスがユーザーまたは製品カテゴリーのニーズを満たさないと感じる場合は、グループのUXリサーチャー に連絡してください。

Category Maturity Scorecardの取り組みは、GitLab UXリサーチプロジェクトで対応するIssueが作成されているべきです。UXリサーチの取り組みの追跡に役立つよう、Issueに CM Scorecard ラベルが適用されていることを確認してください。

Category Maturity Scorecard研究を検討する前に、満たされるべき特定の要件があることに注意してください。これらの要件は、以下を捉えるように設計されています。

• ユーザビリティの進捗
• GitLab Design Standardsへの準拠
• 少なくとも1つの競合と比較しての私たちの立ち位置

下の表は、各成熟度レベルの要件を概説しています。

Category Maturity Scorecard研究の採点を理解するには、Category Maturity ページを参照してください。

過去に完了したCategory Maturity Scorecardは、この エピック で見ることができます。

Category Maturity Scorecard研究を実行するステップ

ステップ0: Jobs to be Done (JTBD)

Category Maturity Scorecardは、定義されており確信できる JTBDに対してエクスペリエンスの質を判断することについてです。JTBDは、製品デザインプロセスの傘下のコンポーネントであり、製品戦略と機能を導くためにそれを使用します。そのため、CM Scorecardプロセスを開始する前に、自信のある1つまたは複数のJTBDが必要です。

JTBDの書き方 について学ぶには、JTBDページ を参照してください。

ステップ1に進む前に、まず評価したい優先度の高いJTBDステートメントを選択し、スクリプトのシナリオに変換する必要があります。ジョブステートメントごとに作成するシナリオの数は、テストする機能の複雑さによって決まることが多いです。ユーザーリサーチ研究の時間制限（通常は参加者ごとに30〜60分）のため、参加者の疲労を避けるのに役立つよう、研究ごとに2つを超えるジョブステートメントを評価しないことを推奨します。ただし、2つを超えるジョブステートメントをテストしたい場合はそうすることもできます。ただ、研究を実行するのにかかる総時間に注意してください。

ヒント: ジョブステートメントはペルソナと解決策に依存しないため、スクリプトシナリオを書くためのガイダンスとしては広すぎる場合があります。その場合は、高レベルのジョブステートメントと実行可能なシナリオの間のギャップを埋めるための中間ステップとして、ジョブステートメントをユーザーストーリーに分解することを検討してください。ジョブステートメントとユーザーストーリーの違いについて詳しくは、How to Write JTBD を参照してください。

まとめると、このステップで従うべきワークフローは以下のとおりです。

1. プロダクトマネージャーが、焦点を当てる関連する優先度の高いジョブステートメントを最大2つ選びます。
2. プロダクトデザイナーが、Category Maturity Scorecard研究で使用するシナリオを作成します。必要に応じて、PM + プロダクトデザイナーが、広いジョブステートメントを機能固有のユーザーストーリーに分解する中間ステップを通り、研究のシナリオを作成する際のガイダンスとしてそれらを使うことができます。

JTBDが決定したら、Category Maturity Scorecard Issue を作成します。

ステップ1: ユーザーを定義し、リクルートする

JTBD作成と検証フェーズの間に、プロダクトデザイナーとプロダクトマネージャーは、ジョブで参照しているユーザーを記述するためのユーザー基準のセットを考案したはずです。Category Maturity Scorecardのリクルーティングの際は、適切なタイプのユーザーからフィードバックを集めることを確実にするために、同じ基準を使用するべきです。

迅速さと多様な視点を得ることのバランスを取るため、私たちはCategory Maturity Scorecardリサーチを、1セットのユーザー基準から5人の参加者で実施します。JTBDに複数のユーザータイプがある場合は、各ユーザータイプから5人をリクルートするのが理想です。研究を管理可能に保つために、研究ごとに最大2つのユーザータイプに焦点を当ててください。JTBDを正確に測定するために2つを超えるユーザータイプが必要な場合は、残りのユーザータイプについて別のフォローアップ研究を実施してください。

例: JTBDは、DevOpsエンジニアとリリースマネージャーによって完了できます。この場合、合計10人の参加者をリクルートします: 5人のDevOpsエンジニアと5人のリリースマネージャー

リクルーティング基準は既存のペルソナに基づくことができますが、スクリーナー調査に変換できるほど具体的である必要があります。次に、Qualtricsでスクリーナー調査を作成し、見込みの参加者がそれに記入することで、参加資格があるかを判断するのに役立てます。

テンプレート調査には、セッションを録画されることに同意するかを尋ねる質問が含まれています。Category Maturity Scorecardに必要な分析のため、参加するためには、参加者はこの質問に はい と答える必要があります。スクリーナー調査が完成したら、UXリサーチプロジェクト で Recruitingリクエスト Issue を開き、関連する Research Coordinator にアサインします。コーディネーターはスクリーナーをレビューし、Issueがある場合は連絡を取り、与えられたタイムラインに基づいてユーザーのリクルーティングプロセスを開始します。

注: ユーザーのリクルーティングには時間がかかるので、リサーチを実施したい時期の少なくとも2〜3週間前にリクルーティングIssueを開いてください。

ステップ2: テスト環境を準備する

プロトタイプは少し違うエクスペリエンスかもしれないので、実際の製品を評価するためには、本番環境でのテストが最善の選択です。

参加者をどのシナリオを通させるか分かったら、使用するインターフェースを決定することが重要です。自問すべき質問:

• 参加者は自分のGitLabアカウントを使用できますか？ できない場合、GitLab.comアカウントを設定して、それを使ってもらえますか？
• self-managedインスタンスが必要ですか？ はいの場合、提供する必要がありますか？
• シナリオには外部のアクションが必要ですか？ 例えば、特定のアラートを表示する必要がありますか、それとも参加者が自分ですべてを完了できますか？
• シナリオはGitLab Webベースのインターフェース以外のものとのやり取りを必要としますか？ 彼らはメールを受け取るべきか、コマンドラインインターフェースを使う必要がありますか？

参加者がシナリオをどのように完了するかを徹底的に計画することが重要です。特に上記の質問のいずれかに「はい」と答えた場合はそうです。所望のフローを通じてユーザーを通すことについて不確実性がある場合は、プロセスの早い段階で技術的なカウンターパートを巻き込んでください。

きれいなテスト環境を作成する助けが必要な場合は、必ず #demo-systems Slackチャンネルで Demo Systems グループに連絡してください。彼らはユーザーのためのデモ環境を作成し、テスト環境に必要な特定のパラメーターを構築するのを助けることができます。リサーチ研究のためにテスト環境を設定するのは、時間がかかり、難しいことがある点に注意してください。あるいは、UX Cloud Sandbox を利用できます。

JTBDが他のステージグループのエリアとやり取りする場合は、製品の彼らの部分があなたのシナリオをサポートすることを確実にするために、彼らに連絡してください。

これは現在のエクスペリエンスの総括的評価であるため、参加者がアクセスする必要があるすべての利用可能なオプションは、GitLabインスタンス内で利用可能でなければなりません。参加者をリクルートするときは、JTBDシナリオを完了するために彼らがアクセスする必要があるツールと機能を念頭に置いてください。

ステップ3: JTBDシナリオの成功／失敗フローを文書化する

シナリオが完成した後、自分でシナリオを実行してください。各シナリオの成功完了として何が認められるかを、将来の参考のために文書化します。

リサーチ参加者と評価する前に、必ず同僚とこれらのシナリオをテストしてください。理想的には、同僚はシナリオに精通していないか、エキスパートレベルの理解を持っていないことです。少しコーチングすることは許容され、パイロットを使ってシナリオの問題を発見するための議論として使います。

👍 ‘成功’ の定義

• 成功したシナリオの完了。
• 単一のシナリオには、完了に至る、つまり ‘成功’ をもたらすエンドゴールへのパスがいくつかある場合があります。チームは、誰もが整合するよう、研究開始前にエンドゴールを特定しなければなりません。
  • なぜこれが重要か？ エンドゴールを特定し整合することにより、モデレーターは何が成功／失敗かを正確に知ることができ、これはフォローアップの質問がシナリオの完了に依存するため、知るのが極めて重要です。
• 参加者がエンドゴールに到達した方法は、チームが文書化するために重要ではないかもしれません。参加者が長いパスを取り、それが簡単であったかどうかを感じた場合、それはスコアに反映されるべきです。最も重要なのは、エンドゴールに到達したかどうかです。

👎 ‘失敗’ の定義

• シナリオを完了できない。
• シナリオの部分的な完了。

研究中に ‘失敗’ が起きた場合の対処

• 失敗があった場合、チームはなぜそれが起きたのかを理解するために、最善を尽くすべきです（例: シナリオの言い回しの仕方が問題だったのか？ エクスペリエンスが混乱を招いたのか？ など）。
  • どうやってこれを行うか？ これを行う1つの方法は、研究の終わりに戻って、参加者にそのシナリオをもう一度通してもらうことです。今回は、エクスペリエンスで彼らがそのルートを取った理由を理解するために、ターゲット質問をすることができます（例: ‘Issues’ をクリックしたようですが。なぜそのメニュー項目を選んだのか、もっと教えてください’、‘この時点でシナリオを完了したと感じましたね。XYZの目標を達成したという自信を与えたものは何でしたか？’）
• 参加者がシナリオを完了できない場合、そのシナリオの評価は破棄され、CM Scorecardスコアの計算には考慮されません。
• 研究中に参加者の80%未満がシナリオに合格できないことに気づいた場合、リソースを節約するために、最新の参加者でスタディを停止すべきです。

エラーのメモを取る

CM Scorecard IssueテンプレートとCM Scorecard Dovetailテンプレートの両方に、CM Scorecard中に遭遇したエラーをメモするためのエリアが含まれています。エラーは、‘happy path’ から外れた重要な何かと考えることができます。例としては、別のエリアにナビゲートして探しているものを見つけようとそのエリアで時間を費やすこと、何かを誤解することなどがあります。重要でなく、すぐに回復するなら、カウントする価値はないかもしれず、単に彼らが犯した間違い、またはテストシナリオの結果である可能性があります。エラーは計算には必要ありませんが、失敗または評価を正当化する際に有用です。

ステップ4: テストスクリプトを完成させ、リサーチを実施する

シナリオを通じて参加者を走らせる前に、テストスクリプトを書く必要があります。Category Maturity Scorecardは標準化されたプロセスなので、モデレーターはこの テストスクリプト を可能な限り正確に完成させ、それに従うべきです。モデレーターは通常プロダクトデザイナーですが、これは厳密には必要ありません。メモを取るのを助けるために関連するステークホルダーがセッションに参加することを推奨しますが、彼らは沈黙を保つことが非常に重要です。

参加者がシナリオを通る前に、彼らが声に出して考えるべきではないことを強調することを必ず行ってください。これは、CM Scorecardリサーチのゴールは、可能な限り客観的にデータを生み出すことだからです。声に出して考えるプロセスは、ユーザーをエクスペリエンスから引き出し、研究に時間を加えるため、客観的なデータを得るのを妨げます。参加者が経験した何かをさらに深く掘り下げたい場合は、研究の終わりに彼らとそれを議論してください。シナリオのセットに関する主に言語的なフィードバックを得たいときは、CM Scorecard研究の前にユーザビリティテストを実施することを強く推奨します。

私たちが尋ねる3つの質問

参加者がシナリオの完了に成功したとき、彼らはそのエクスペリエンスを測定するための3つの質問を尋ねられ、これをカテゴリーの成熟度に結びつけます。参加者がシナリオの完了に失敗した場合、これらの3つの質問を尋ねる必要はありません。

エクスペリエンスをレート／評価する方法の根本では、3つの主要な要素に帰着すると言えます。

1. 何かをするのがどれだけ簡単だったか - これは使いやすさとして定義され、その中にユーザビリティのコンポーネントが組み込まれています。
2. ユーザーがそのエクスペリエンスをどう評価したか - 私たちのユーザーセグメントを考えると、彼らはユーザーエクスペリエンスとは何かを知っているので、それについて尋ねることができます。ユーザーがそのエクスペリエンスについてどう感じたかを理解することは、計算に基づいて彼らの評価を推論するのではなく、彼らに直接評価する機会を与えます。
3. ユーザーが必要とすることをエクスペリエンスが行えるか - これは、エクスペリエンスがユーザーの所望のワークフローや類似ツールの使用に基づいて、ユーザーの期待にどれだけマッチするかを評価します。

質問1: Single Ease Question (SEQ)

Single Ease Question (SEQ) は、他のUX関連の質問と測定値に基づいて新しく導入された業界全体の質問です。この質問は、シナリオを完了するのが簡単か難しかったかを理解するのに役立ち、シナリオパフォーマンス満足度を測定するシンプルで信頼できる方法を提供します。この質問は、UX Scorecardの形成的評価アプローチでも使われます。

Q1: 「全体として、このシナリオは…」

• 非常に簡単
• 簡単
• 簡単でも難しくもない
• 難しい
• 非常に難しい

質問2: 満足度評価

率直に言えば、‘ユーザーエクスペリエンス’ という用語は広く、全体的なユーザーエクスペリエンスをどう評価するかに完全に適用できる、私たちが気にする多くのコンポーネント（例: 効率性、速度、ユーザビリティなど）を網羅しています。そのため、私たちは意図的に ‘ユーザーエクスペリエンス’ を定義せず、オーディエンスを考えると、その定義は集合的に高い精度で理解されると感じています。この質問は、UX Scorecardの形成的評価アプローチでも使われます。

Q2: 「このエクスペリエンスの品質をどう評価しますか？」

• 非常に良い
• 良い
• 良くも悪くもない
• 悪い
• 非常に悪い

質問3: UMUX Lite, adjusted

UMUX Lite スコアは、Finstadによって作成されたUMUX（Usability Metric for User Experience）に基づいており、SUS およびNet Promoter Scoreと高度に相関しています。SUSと類似することを意図していますが、より短く、ISO 9241のユーザビリティの定義（有効性、効率性、満足度）を対象としています。この質問は、UX Scorecardの形成的評価アプローチでも使われます。

Q3: 「あなたは私たちの <Scenario> の実装を経験しました。次のステートメントにどの程度同意するか、または同意しないか:

<Scenario> は私が自分の仕事で行う必要があることに必要な機能を持っている。」

• 強く同意する
• 同意する
• 同意するか同意しないか分からない
• 同意しない
• 強く同意しない

シナリオ名をどう構成するかを決める必要があります。Category Maturityページ でカテゴリーに使用する名前を考慮してください。私たちが使うシナリオ名をそのまま使うことは、ユーザーに対してフィードバックを得るためにプレゼンするには十分に明確でないかもしれない場合があります。

ZoomおよびRespondent.ioのヒント

Respondentでプロジェクトを設定するとき、参加者ごとにリンクを変更できない（つまり各参加者が同じZoomルームリンクを持つ）ので、必ず個人のZoomルームリンクを使ってください。さらに、これらのセッションのパスワード要件を必ずオフにしてください。

無人テスト

CM Scorecardテストを無人で実施することは可能です。重要なのは、参加者がそのエクスペリエンスをそのように評価した理由を理解するのに役立つ、豊かな質的洞察を得ていることを確認することです。さらに、イテレーションを行うために必要な正当性も持っているべきです。

ステップ5: 発見を分析し文書化する

CM Scorecardスコアを計算する

参加者がシナリオの完了を試みると、私たちの目的では、最終結果は成功か失敗のいずれかになります。次のカテゴリー成熟度レベルに移るには、最低スコアと共に、最低 % 合格率が必要です。下の図表は、最低 % 合格率、SUS、CM Scorecardレベル、CM Scorecardスコアの間の関係を示しています。

CM Scorecardスコア: CM Scorecardスコアは、各シナリオについて簡単に計算できます。

ヒント: 計算がすでに組み込まれている、この Google Sheet（内部のみ）を使用してください。

ステップ1: 各シナリオについて、関連する質問にわたるテスト参加者の回答を入力し、ドロップダウンを使ってタスクの成功／失敗を文書化します。

注: タスク失敗を経験した参加者については評価を入力しないでください。これらの評価はCM Scorecardスコアの計算には考慮されません。

ステップ2: 各質問の全体スコアとタスクの成功率は平均され、シナリオスコアを提供します。

ステップ3: すべてのシナリオスコアが計算されると、全体スコアと成熟度レベルが提供されます。詳細については、Maturity level セル（J40）のメモをチェックしてください。

例:

• 4.70平均 = ‘A’ CM Scorecard成績 = ‘78.9-100’ SUS = Complete
• 3.93平均 = ‘B’ CM Scorecard成績 = ‘72.6 - 78.8’ SUS = Competitive

最低 % 合格率: 最低 % 合格率は、シナリオで成功するために何 % の参加者が成功する必要があるかを示すのに役立ちます。これはまた、どのレベルのシナリオ失敗が許容されるかを示すのにも役立ちます。シナリオ失敗はメモするのに重要であり、無視できないため、カテゴリー成熟度レベルを移動するための基準の一部として組み込まれる必要があります。研究中に任意のシナリオの最低 % 合格率が80%未満である場合、リソースを節約するために、最新の参加者でスタディを停止すべきです。万一これが起きた場合、カテゴリー成熟度をレベルアップさせることはできません。チームはそれらの学びを取り、イテレーションし、準備ができたら再テストすべきです。次のことを学ぶために、レトロスペクティブを開催することも推奨されます。

• 何が起きたか？
• なぜ参加者はシナリオを正常に完了できなかったか？
• これに対処するために何をするか？

スコア解釈の例:

• 現在Minimalにある製品カテゴリーが、内部参加者でCM Scorecard研究を完了しました。結果のスコアは4.0で、成功率は80%です。最低 % 合格率を満たしているので、製品カテゴリーはViableに上がることができます。結果の4.0スコアはCompetitiveレベルにあっても、シナリオを外部ユーザーでテストすることが、カテゴリーをさらに成熟度レベルで移動させるために必要になります。結果の推奨事項は、カテゴリーをViableに移動することです。
• 現在Viableにある製品カテゴリーが、外部参加者でCM Scorecard研究を完了しました。結果のスコアは3.85ですが、成功率は60%で、最低 % 合格率を下回っています。この場合、製品カテゴリーは成熟度を上げず、低い成功率につながった原因を調査することが推奨されます。

セッション後のデブリーフィング

セッションが終了したときに、モデレーターと任意のステークホルダーが通話を離れないことが重要です。代わりに、参加者を取り除き、通話に残ってください。グループが今経験したことについてデブリーフするためにこの時間を使います。メモ取り係はこの議論についてメモを取るべきです。

• 各人にセッションの主要な発見だと感じることについて話してもらいます。
• セッションに関するIssueや、将来の研究で違う方法で行うべきことを言及します。ただし、計画されたセッションの実施方法に変更を加えないでください。そうしないとデータが比較できなくなります。このため、不具合を解決するためにパイロットセッションを実行することを提案します。
• セッションが終了する前に、誰もがカバーされた内容について質問したり、言わなければならないと感じることを言ったりできるようにします。

結果データ

Category Maturity Scorecard テストスクリプト に従うことで、機能ごと（シナリオごとではない）にレポートする以下の測定値が得られます。ただし、シナリオには複数の機能が含まれる場合があります。

• Single Ease Question
• ユーザーエクスペリエンス評価
• UMUX Lite（調整版）評価
• 成功／失敗 Category Maturity Scorecardデータを分析するゴールは、JTBDに関連する現在のエクスペリエンスのベースライン測定値を確立することです。時間が経つにつれて、新しい機能／機能が追加／変更されるにつれて、私たちの製品は変わります。ここで収集されたデータをレビューして、これらの変更がユーザーエクスペリエンスにどう影響したかを理解し、改善を行うのに使えます。

分析するには: シナリオごとにCM Scorecardスコアを計算する助けとして、Google Sheet（内部のみ）を使用してください。さらに、参加者がそのように評価した理由の背後にあるテーマを探してください。

文書化するには: Actionable Insight scoped ラベル を活用して、Issueを通じて改善のための領域を文書化し強調表示し、エクスペリエンスへのさらなる改善を行います。

UXリサーチチームの Dovetailでのインサイト文書化 ガイドを読んでください。

JTBDデータファイルを更新する

いくつかのグループは現在、特定のカテゴリーの全体的な解決しようとしている問題を表す各ジョブの現在の成熟度を示すために、jobs_to_be_done.yml を使用しています。YMLファイルの各エントリは、以下のキーで構成されています。

特定のJTBDのCM Scorecardスコアを成績の文字にマッピングするには、以下の基準を使用してください。

• A: 3.95以上
• B: 3.65から3.94の間
• C: 3.14 - 3.63の間
• D: 2と3.13の間
• F: 2未満

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