System Usability Scaleについて読んだことがあるでしょう。良いスコアがどのようなものかも知っています。次は実際に実施してみましょう。

これは実践ガイドです。読み終わる頃には、誰に調査すべきか、いつ送るべきか、何件の回答が必要か、そして結果が返ってきたときにどう扱うかがわかるようになります。

ステップ1：何を測定するかを決める

何かを送る前に、何を評価するのかを明確にしましょう。SUSは技術に依存しません。Webアプリ、モバイルアプリ、デスクトップツール、物理デバイスのいずれでも同様に機能しますが、範囲が具体的であるほど効果的です。

製品全体を測定しますか？オンボーディングやチェックアウトのような特定のフローですか？リリースしたばかりの新機能ですか？

範囲が狭いほど、シグナルは有用になります。ユーザーに製品全体を評価してもらうと、ユーザビリティの大まかな全体像が得られます。オンボーディング体験に限定して評価してもらうと、そのジャーニーの該当部分についてより精確な測定ができます。

SUSを初めて実施するほとんどのチームにとって、製品全体を測定するのが適切な出発点です。ベースラインが得られます。どこを詳しく見るべきかがわかれば、その後でより具体的に掘り下げることができます。

ステップ2：参加者を選ぶ

SUSは実際のユーザーを代表する人々に回答してもらうべきです。同僚でも、友人でも、たまたまそばにいた人でもありません。

これはサンプルサイズよりも重要です。適切な人からの10件の回答は、不適切な人からの50件の回答よりも多くのことを教えてくれます。

いくつかの原則：

製品を使用したことがある人であること。 SUSは知覚されたユーザビリティを測定するため、実際の経験が必要です。デモを見ただけの人やウォークスルーを視聴しただけの人に質問しないでください。

ターゲットオーディエンスに合致していること。 製品が中小企業のオーナー向けなら、中小企業のオーナーに調査してください。まったく異なるメンタルモデルでアプローチする開発者やデザイナーではありません。

パワーユーザーである必要はありません。 実際、新しいユーザーの方が最も有用なシグナルを提供することが多いです。経験豊富なユーザーは時間の経過とともに摩擦に適応し、気づかなくなります。

ステップ3：サンプルサイズを決める

SUSの良いところは、少ないサンプルサイズでも統計的に信頼性があることです。数百件の回答は必要ありません。

実践的な目安として：

• 5件の回答 — 大まかな方向性を示すシグナルが得られ、非常に素早いチェックに有用
• 12〜15件の回答 — ほとんどのプロダクト判断に十分な信頼性
• 20件以上の回答 — 高い信頼度、ステークホルダーへの報告や過去のスコアとのベンチマークに適切

リリースをまたいで定期的にSUSを実施する場合、完璧さよりも一貫性が重要です。毎回比較可能なユーザーから12件の回答を得れば、信頼できるトレンドラインが形成されます。

ステップ4：適切なタイミングを選ぶ

ユーザーにアンケートへの回答を依頼するタイミングは、誰に依頼するかとほぼ同じくらい重要です。

SUSは、ユーザーが製品と実際にインタラクションした後に実施すべきです。実施前でもなく、体験の記憶が薄れるほど後でもありません。

最も一般的な2つのアプローチ：

セッション後 — ユーザビリティテストや特定のタスクの直後。最も新鮮な印象が得られ、SUSが元々設計されたアプローチです。

オンボーディング後 — ユーザーがサインアップし、探索する時間を持った数日後に送信。正式なリサーチプロセスを持たないチームにとってより実用的で、実際の体験をより代表的に反映します。

数ヶ月前にサインアップし、製品を頻繁に使用しているユーザーにSUSアンケートを送ることは避けてください。長期的な慣れはユーザビリティの問題を覆い隠します。経験豊富なユーザーは摩擦に適応し、気づかなくなります。

ステップ5：アンケートの導入文を書く

10問のSUS質問は固定です。変更しません。しかし、質問の前に書く導入文がコンテキストを設定し、回答の質に影響します。

簡潔にまとめましょう。ユーザーに以下を伝えます：

1. 何を評価してもらうか（特定の製品または機能）
2. 正解も不正解もないこと — 正直な印象が欲しいこと
3. 2分もかからないこと

シンプルな例：

「[製品名]の使いやすさについてお聞かせください。これまでのご経験をもとに、以下の10問にお答えください。正解も不正解もありません。率直な第一印象をお聞かせください。所要時間は2分未満です。」

ポジティブな言葉（「製品を楽しんでいただけていると思いますが」）やネガティブなフレーミング（「いくつか問題があることは承知していますが」）で誘導しないでください。中立を保ちましょう。

ステップ6：10の質問を送る

SUSアンケートは標準化されています。正確な文言が重要です。質問を言い換えたり、順序を変えたりしないでください。ユーザーは各項目を1（まったくそう思わない）から5（非常にそう思う）の尺度で評価します。

10の項目は以下の通りです：

1. このシステムを頻繁に利用したいと思う。
2. このシステムは不必要に複雑だと感じた。
3. このシステムは使いやすいと思った。
4. このシステムを使うためには、技術的な知識のある人のサポートが必要だと思う。
5. このシステムの様々な機能はよく統合されていると感じた。
6. このシステムには一貫性のない点が多すぎると思った。
7. ほとんどの人はこのシステムの使い方をすぐに覚えられると思う。
8. このシステムはとても使いにくいと感じた。
9. このシステムを使う際にとても自信を持てた。
10. このシステムを使い始める前に、多くのことを学ぶ必要があった。

実践的な注意：「システム」をより自然に読める場合は、製品名に置き換えてください。「[製品名]は使いやすいと思った」で問題なく、アンケートがより具体的に感じられます。

ステップ7：スコアを計算する

計算方法は、質問が肯定的な表現と否定的な表現を交互に使っているため、やや直感に反します。以下がその方法です：

奇数番号の質問（1, 3, 5, 7, 9）の場合： ユーザーの回答から1を引きます。

偶数番号の質問（2, 4, 6, 8, 10）の場合： 5からユーザーの回答を引きます。

10個の調整済み値をすべて合計し、2.5を掛けます。結果が、そのユーザーのSUSスコアで、0から100の尺度になります。

全体スコアを得るには、全回答者の個別スコアの平均を取ります。

面倒に聞こえるかもしれませんが、実際にそうです。ほとんどのチームは計算を処理するスプレッドシートのテンプレートを作成するか、自動的に計算してくれるツールを使用します。

ステップ8：結果を解釈する

スコアが出たら、以下のように読み取ります：

覚えておいてください：68は平均であり、良いスコアではありません。70台前半のスコアを喜んでいるなら、それはC評価です。80以上を目指しましょう。そこからユーザーが積極的に他者に製品を推薦し始めます。

ステップ9：1回のスコアで終わりにしない

単一のSUSスコアはスナップショットです。有用ですが、限定的です。

SUSの真の価値は、時間をかけて追跡することにあります。一定の間隔でアンケートを実施し、トレンドラインを観察します。今日の71というスコアは、それだけでは大した意味を持ちません。4回のリリースを通じて58から71に上昇したスコアは、チームのユーザビリティ改善作業が測定可能な効果を上げていることを示しています。

SUSをリリースサイクルに組み込みましょう。重要な変更のたびに実施してください。毎回、前回を超えるという目標を持ちましょう。

近道

上記のすべては手動で行えます。アンケートにはGoogleフォーム、スコアリングにはスプレッドシート、各実施後に手動で更新するグラフ。

特に始めたばかりの頃はそれで機能します。しかし摩擦が生じ、結果として一貫した実施がされなくなりがちです。次のリリース後にアンケートが送られないのは、誰かが忘れたから。スプレッドシートが更新されないのは、誰も担当していないから。トレンドラインは決して形成されません。

UXScoreはアンケート、スコアリング、トラッキングを自動で処理します。SUSの定期的な実施がプロジェクトではなく習慣になります。