UX スコアカード
はじめにとゴール
UX スコアカードは、ヒューリスティックのセットに基づいて、プロダクトの体験のユーザビリティを特定し採点する方法です。私たちはユーザーへの共感を育み、改善の機会を素早く見つけるために UX スコアカードを使用します。
UX スコアカードは、すべての主要なジョブで実施し、定期的なペースで繰り返すべきです。UX スコアカードは 6 ヶ月ごとに、または大きな変更や改善が行われた後に更新することを検討してください。これにより、あなたとチームは、ユーザーのために体験を良くする進捗を継続的に監視できます。グループでスコアカードが実施されてから時間が経っている場合は、ペースを再確立するためにすぐに実施することを計画すべきです。
UX 実践者として、私たちはユーザーに品質のある体験を提供するために、GitLab プロダクト内のユーザビリティの課題を解決することについて戦略的に考えなければなりません。関連する推奨事項を持つ UX スコアカードを作成することは、特定のワークフロー内のユーザビリティの懸念に対処する取り組みを特定、スコープ、追跡することを可能にします。完了すると、修正を意味のあるイテレーションにグループ化し、UX 関連の Issue を優先順位付けすることについて、プロダクトマネージャーと協力するために必要な情報を得られます。
完了したすべてのスコアカードは以下をご覧ください:
プロセスについて
UX スコアカードは 1-2 日で完了できます。一部のワークフローはもう少し時間がかかる場合がありますが、一般的にプロセスがそれ以上時間がかかる場合は、スコープを縮小することを検討してください。UX スコアカードのプロセスは、柔軟性と一貫性のバランスを取るように意図されています。スコアカードを作成する方法はいくつかあり、軽い方から重い方まで以下に挙げられます。利用可能な時間、ユーザーへのワークフローの優先順位、またはこれがそのジョブの最初のスコアカードかどうかに基づいて、適切なアプローチを選択してください。
スコアカードのアプローチ
スコアカードを実施する際、オプションがあります:
オプション A: ヒューリスティック評価を実施する
ヒューリスティック評価を行うことで、現在の体験をレビューします。これは半日でできるので、以前に採点されたタスクのスコアカードに取り組んでいる場合は特に高速なアプローチです。
評価中は、ジョブに関連するペルソナの帽子をかぶり、あたかも新規ユーザーであるかのように UI をペルソナの視点から見るように努めます。評価を進める中でこれを忘れがちなので、モニターに貼り付ける付箋に「あなたは新規ユーザーです!」と書くなど、視界のどこかにリマインダーを置くことを推奨します。
ヒューリスティック評価は、エキスパート評価、ディスカウントユーザビリティ手法と見なされていることを念頭に置いてください。ここでの「エキスパート」は、ユーザーエキスパートではなく UX エキスパートです。したがって、これは潜在的な問題を見つけるための出発点であり、必ずしもエンドポイントではないと考えることができます。改善の領域が見つかった場合は、次のステップとして、以下に概説されているオプション B の UX スコアカードを、実際のユーザーで物事を検証する方法として行いたいかもしれません。
オプション B: 形成的評価を実施する
内部または外部のユーザーにジョブを達成しようとさせることで、形成的評価を行うことができます。ゴールは、参加者にコンテキスト(シナリオ)を提供し、参加者がどのようにジョブを完了しようとするかを聞き、観察することです。学ぶことは、参加者によって異なる場合があります。
形成的評価を実施するとき、3-5 名の内部または外部ユーザーを観察する「軽い」ユーザビリティテストを行います。これは貴重なインサイトを提供し、主観性を取り除きます。これは、評価しているシナリオがテストプロジェクトでセットアップしやすい場合、約 1 日で行えます。シナリオが非常に技術的で複雑なカスタマイズが必要な場合は、評価のための環境をセットアップするだけで数日かかることがあるので、前もって計画してください。私たちが好むセットアップはアンモデレートスタディですが、より良い評価につながるならモデレートも可能です。
すべての場合において、
- スコアカードを実施する前にジョブを定義する。
- 体験を評価する際に、私たちのヒューリスティックを使用する。
- 体験のベンチマークスコアとなる全体的な測定を提供するために、採点ルーブリックを使用する。
- ユーザーの観察は、主観性を取り除くので、純粋なヒューリスティック評価よりも好まれる。
これは、デザインプロセスを情報伝達し、品質の高いハードルを維持するために役立つことを意図したプロセスです。
UX スコアカードのやり方
すべてのスコアカードが同じではないことに注意してください。プロダクトデザイナーは、可能な限り客観的であり、精神と成果が同じである限り、ステップを自分のニーズに合わせて変更することを歓迎されます。
GitLab Design プロジェクトで UX スコアカードテンプレートを使って Issue を作成し、テンプレートの指示に従ってください。方法を変更する場合は、説明にそれを記載してください。
テンプレートを見たり編集したりしたい場合は、こちらで見つけられます:
採点ルーブリック
全体体験
評価された各シナリオの後、スコアカードに付与する適切なスコアまたはグレードを決定するのに役立つ 3 つの質問のセットが尋ねられます。
質問 1: シングルイーズクエスチョン (SEQ)
「全体として、このシナリオは…」
- 5 - 非常に簡単
- 4 - 簡単
- 3 - 簡単でも難しくもない
- 2 - 難しい
- 1 - 非常に難しい
質問 2: 満足度評価
「この体験の品質をどう評価しますか?」
- 5 - 非常に良い
- 4 - 良い
- 3 - 良くも悪くもない
- 2 - 悪い
- 1 - 非常に悪い
質問 3: UMUX Lite、調整版(有用性)
「あなたは私たちの <シナリオ> の実装を体験しました。次の文にどの程度同意または不同意しますか:
<シナリオ> には、自分の作業で必要なことをするための機能があります。」
- 5 - 強く同意
- 4 - 同意
- 3 - 同意も不同意もしない
- 2 - 不同意
- 1 - 強く不同意
スコアの計算
全体スコアを決定するには、UX スコアカード計算シート(内部のみ)を使用します。
オンボーディングは多くの異なるシナリオを指す可能性があり、これが体験に影響を与える可能性があります:
- SaaS または セルフマネージドユーザー
- SaaS またはセルフマネージドアカウント/インスタンスをセットアップする新しい GitLab 管理者
- 会社またはチームに参加する新しい GitLab ユーザー
- トライアルユーザー
- 会社またはチームに参加する既存の GitLab ユーザー
- 新しいステージまたはカテゴリの機能を試している既存の GitLab ユーザー
- GitLab 機能、機能のセット、または完全な DevOps ステージ
たとえば、新しいチームに参加する既存の GitLab ユーザーは、馴染みのない機能の助けや、チームのグループとプロジェクトに方向付けることが必要かもしれません。一方、まったく新しいユーザーは、アプリケーション自体に方向付けることにもっと助けが必要です。
オンボーディング UX を評価するステップ
- JTBD に関連する最も重要なタスク/シナリオについて考えます。
- ユーザーがこのタスクを初めて行うシナリオを特定します。
- 各シナリオを取り入れて、それらのタスク/シナリオで UX スコアカードまたはユーザビリティテストを実施します。
- オンボーディング体験を評価するために、評価をオンボーディングヒューリスティックとルーブリックに焦点を絞ります。
- オンボーディングスコアと日付をドキュメント化します(場所は TBD)。
最近の UX スコアカードまたは録画付きの最近のユーザビリティテストがある場合、最初からやり直すよりもこれらを更新できます。たとえば、最近 MR を作成するユーザビリティテストを行った場合、オンボーディングヒューリスティックを念頭に置いてセッションを再視聴して、オンボーディング体験の初期スコアを推測できます。ただし、いつかオンボーディング体験を意図的に評価することを強く推奨します。
c955a93f)