同じタスクを完了した2人の被験者でも、その体験の語り方はまったく異なることがあります。ある人はすぐに進め方を見つけ、もう1人は手戻りを繰り返しながら、支払いが完了したか不安を抱えつつなんとか成功するかもしれません。一般にSEQと略されるSingle Ease Question（単一の容易性質問）は、タスクを試みた直後に、それがどれくらい簡単、または難しく感じられたかという主観的な評価を捉える手法です。

通常、1の「非常に難しい」から7の「非常に簡単」までの7段階評価尺度が用いられます。これにより、システム全体の包括的な評価を集めるSystem Usability Scale（SUS）とは異なり、タスク単位でユーザーが感じた使いやすさを測ることができます。

タスクの記憶が新しいうちに尋ねる

長時間のディスカッションによって体験の記憶が書き換えられてしまう前に、対象となる各タスクの試行直後に質問を提示してください。これには途中で失敗した試行も含めます。MeasuringUによるSEQの開発経緯についての解説では、この指標を支える研究や質問文の変遷が詳しく紹介されています。

確立された設問形式を一貫して用い、表現や両端のラベル、尺度の向きを記録しておきましょう。実用的な表現としては、「このタスクを完了するのはどれくらい簡単、または難しかったですか？」と尋ねる形が一般的です。回答者が評価を変えようと誘導されないよう、その理由を尋ねる追加の質問は評価自体とは分けておきます。

例えば予約手続きの調査では、希望枠の確保に成功したにもかかわらず、被験者が低い評価をつけることがあります。理由を聞いてみると、「本当に予約が確定したのか不安だった」といった心理が明らかになるかもしれません。スコアは「体験が難しく感じられた」という事実を伝え、その付随するコメントが原因の特定に役立ちます。

観察された行動とスコアを照らし合わせて読み解く

SEQが測定するのは認知であり、操作の正しさそのものではありません。誤った予約に気づいていない人は手続きを簡単だと感じる一方で、正しく完了できた人が苦労したと感じることもあります。1つの指標ですべてを代弁させるのではなく、回答をタスク成功率やエラー、観察記録とあわせて読み解くことが大切です。

評価と行動のズレは、特に示唆に富んでいます。不適切な選択肢を何度も選んでいるのに「簡単だ」と高く評価している場合、誤った解釈が自然に見えてしまうデザインになっている可能性があります。逆に、成功しているのに評価が低いなら、完了率という数字の裏に隠れた余計な負担がルート上に潜んでいるのかもしれません。

評価スコア単体では、どの画面や操作が難しさを引き起こしたのかまでは特定できません。その原因を解明するには、セッション中の具体的なエビデンスや、焦点を絞った追加調査が不可欠です。

合格ラインを勝手に設けず、平均値を読み解く

平均値を報告する際は、回答数や不確実性を示す適切な指標も併記してください。分布を確認できるなら、それも残しておきましょう。真ん中あたりの平均値であっても、全体的にそこそこだった体験を示していることもあれば、「とても簡単」と「とても難しい」に意見が二極化しているケースもあるからです。

MeasuringUの解釈ガイドでは、スコアを基準データや分かりやすいラベルと関連付けています。こうしたベンチマークは判断の目安になりますが、比較が妥当かどうかはタスクや調査内容によって異なります。どんなプロダクトでも「これを超えれば使いやすい」と保証する単一のスコアはありませんし、7段階の平均値を「満足したユーザーの割合（％）」のように言い換えてはいけません。

反復測定によって変化を見極める

改修したデザインをテストする際は、結果を正しく比較できるよう、タスクや評価尺度、リクルーティング方針の一貫性を十分に保ってください。2つ目のグループがより簡単なタスクを試したり、すでにプロダクトに慣れていたりすると、スコアの上昇がデザインの改修によるものとは言えなくなってしまいます。

また同じ調査内において、同一の被験者から得た複数の評価は関連し合っている点に注意が必要です。タスク間やバージョン間での分析では、調査設計全体を考慮しなければなりません。有益なレポートとは、数値的な結果と被験者の行動に見られた変化を結びつけ、平均値の変動にとどまらない「改善の確かな根拠」をチームに提示できるものです。