JTBD - Playbook を超えて
混合手法のリサーチで Jobs to be Done を使用する
JTBD は、調査からユーザビリティベンチマーキングまで、多くの UX リサーチ手法で使用できます。インタビューを通じて JTBD を検証し、JTBD キャンバスを作成したら、キャンバスの一部を多数の GitLab プロセスに情報提供するために使用できます。たとえば、ジョブのニーズと状況を使用して、ソリューション検証テストの現実性と読みやすさを高めることができます。同様に、メインジョブは、研究に適した参加者を見つけるための募集スクリーナーの作成オプションに役立ちます。
JTBD を使用して募集スクリーナーの構築を助ける
効果的な募集スクリーナーは、参加可能性のある研究について多くの情報を明らかにしすぎることなく、回答者に関する情報を収集します。通常、スクリーナーには、参加者の職種を尋ねる質問と、おそらく彼らが実行する一般的なタスクに関する質問があります。JTBD は、ジョブパフォーマーとそのメインジョブを使用して、有効なスクリーニングオプションを作成することで役立ちます。理想的な候補者を思い描くとき、対応するジョブパフォーマーを特定してみてください。職種の代わりにそのパフォーマーのメインジョブを使用すれば、より少ないスクリーニング質問で以前と同じ情報を明らかにできます。
例: 脆弱性レポートページを使用しているセキュリティ専門家が必要な研究があるとしましょう。
GitLab のユーザーペルソナリスト のセキュリティペルソナで使用される職種を見ると、Security Analyst、Security Operation Engineer、Security Consultant、Application Security Engineer など 10 以上の職種に及ぶリストになります。このリストは回答者にとって回答するのが非常に煩雑であり、理想的な候補者の日々の役割を正確に反映していない可能性があります。
Secure および Software Supply Chain Security ステージ向けの JTBD を使用して、研究に理想的な 2、3 のジョブ／ジョブパフォーマーを特定できます。これらのジョブステートメントを例に見てみましょう: 「組織の資産のリスクを特定する」と「検出されたビジネス上重要な脆弱性に対処する」。さらに、不適合な候補者を除外する無効なオプションを含めたい場合、Secure セクションの他のワークフローからのジョブを含めることができます。このスクリーナー質問は、参加者が選択できる少数のオプションになり、結果として理想的な候補者を正確に反映する参加者を得ます。
簡単にするために、ステージのすべてのメインジョブをテンプレートとして保存し、この例 のように、研究ごとに選択したものだけを許可できます。参加者がメインジョブと一致しない場合、それはあなたに戻って、JTBD をどう発見したか を正確に確認するシグナルになります。
JTBD を使用してソリューション検証スクリプトを書くのを助ける
デザインをテストするためにソリューション検証を実施する場合、ユーザーが試みてフィードバックを提供するタスクを含むスクリプトを作成することになるでしょう。フィードバックの質の重要な要因は、明らかな解決策でユーザーをバイアスせずに、タスクがどれだけユーザーにとって現実的であるかです。それを行う 1 つの方法は、あなたが構築しているジョブの状況、ジョブプロセス、ニーズを活用することです。
スクリプト内に JTBD を組み込むには、次の手順に従うことができます。
- ユーザーがあなたの機能を使用するときに達成しようとしているメインジョブを特定します。すべてのサービスやプロダクトの目標は、ユーザーの問題に解決策を提供することであるべきです。そのため、デザインが解決を助けているジョブを特定します。
- 潜在的に無効な候補者を特定し、それらのジョブステートメントを使用して、これらの回答者を不適格にするスクリーナー質問を作成することも役立つかもしれません。
- そのジョブの状況、プロセス、ニーズを特定します。この情報は、ジョブを発見する ときに JTBD キャンバスに含まれているはずです。
- 状況を使用して、タスクの開始時にシナリオを確立します。これは、ユーザーが役割を実行する際のコンテキストと同様に、タスクのための参加者のコンテキストを提供します。
- たとえば、Security Policy グループの以前に発見された JTBD キャンバス では、ユーザーが「組織で新しいセキュリティポリシーが公開された」ときにセキュリティコントロールを実装することを発見しました。この状況をモデレートされていないテスト用のシナリオに変えるために、「このシナリオでは、あなたの組織が最近、以下に示すパラメータで新しいセキュリティポリシーを公開しました。あなたのタスクは、資産がセキュリティポリシーに準拠するように、必要なセキュリティコントロールを実装することです」と言うことができます。
- ジョブプロセスとその中のスモールジョブを使用してソリューション検証タスクを作成します。これにより、ユーザーが他では持っていない可能性のある情報でバイアスをかけることを避けます。JTBD はユーザーリサーチ中に特定された言葉を使用するため、ユーザーにより自然な体験を与えます。
- たとえば、セキュリティコントロールを実装する最初のステップは「セキュリティポリシーを収集する」ことです。このジョブステップをタスクに変えるために、「まず、必要なセキュリティポリシーを収集してください」と言うことができます。参加者はこれを読んで自然にタスクを理解し、私たちは彼らに行ってほしい場所を明らかにする必要はありません。
- ジョブのニーズを使用して、テスト後の評価質問を作成します。ラップアップ質問 を作成する際、タスクを参加者のより大きな目標または望ましい結果に関連付けることができます。
- たとえば、ポリシー作成者が最も望む結果は、「組織の資産における潜在的な脅威の可能性を減らす」ことです。これを質問に変えるために、「1〜7 のスケールで、1 がまったく役立たない、7 が非常に役立つとして、組織のセキュリティ脅威の可能性を減らす上で、この機能はあなたにとってどれほど役立ちましたか？」と言うことができます。定量的な比較を得るために、ユーザビリティベンチマーク からのメトリクスも使用したい場合があります。
JTBD を使用してヒューリスティック評価に情報提供する
ヒューリスティック評価 は、チームメンバーがプロダクトとのユーザーの現在の体験を理解するのに役立ちます。これらの評価は、ユーザビリティを改善するために直接的な変更を必要とする、または問題に対する組織的な理解を高めるためのさらなるリサーチを必要とするインサイトを明らかにします。ヒューリスティック評価は通常、Product または UX のステークホルダーと UX リサーチャー間で 1〜2 ミーティングがかかります。
ヒューリスティック評価に JTBD フレームワークを統合するには、次の一般的なステップに従うことができます。
- ユーザーがあなたの機能で達成しようとしているジョブを特定します。プロダクトやサービスの目標は、ユーザー（または顧客）の問題に解決策を提供することなので、デザインが解決を助けているあなたのステージのジョブを特定します。
- そのジョブのプロセスとニーズを特定します。この情報は、ジョブを発見する ときに JTBD キャンバスに含まれているはずです。
- このテンプレート のような、ヒューリスティック評価のための計画ドキュメントを作成します。
- ジョブプロセスを使用して、評価プロセス中に取るステップを特定します。これは、あなたが従うべき一般的なワークフローです。
- 状況を使用して、評価のために作成するシナリオを確立します。場合によっては、ステップを再度たどる必要がありますが、異なる視点からです。
- 関連するジョブを使用し、どのジョブがスコープ外であるかについてコンセンサスのために協働します。
- GitLab のヒューリスティックリスト を探索するか、よく知られた Nielson Norman 10 ユーザビリティヒューリスティック を使用します。どのヒューリスティックがあなたの評価に適用されるかを判断します。
- 適用可能なヒューリスティックを言い換えることで、評価中に互いに尋ねる質問を作成します。
- たとえば、ヒューリスティックの 1 つは「ユーザーコントロールと自由」です。これを質問に変えるために、「1〜7 のスケールで、1 がまったく役立たない、7 が非常に簡単として、ツールへのナビゲートとツールからのナビゲートはどれほど簡単でしたか？」と言うことができます。
- 評価のモデレートを誰が行い、誰がユーザー役を務めるかを指定します。「ユーザー」は UI を通じてタスクを完了するために移動し、モデレーターは進捗を評価し質問を行います。両方のステークホルダーがフィードバックを提供することが推奨されますが、モデレーターはすべてのタスクが評価されることを確認する必要があります。
–>
bfd74782)