SEQとは、ユーザーがウェブサイトやアプリで何か一つの操作を終えた、まさにその瞬間に「今の操作は、どれくらい簡単でしたか？」と尋ねる、非常にシンプルな調査方法である。「今すぐ」「これだけ」に絞って聞くなど、他の操作の記憶やサービス全体の印象に邪魔されない、たった今の体験に対する率直な評価が手に入る。
この方法の最大の強みは、サービスが抱える問題をピンポイントで、しかも数字で明らかにできる点にある。例えば「会員登録」の平均点が3.2と低く、「商品購入」が5.8と高ければ、改善すべきは明らかに「会員登録」だと判断できる。「なんとなく使いにくい」といった曖昧な感覚ではなく、「ここの点数が低いから直そう」というデータに基づいた的確な判断が可能になるため、ビジネスの意思決定を力強く後押しする。
語源・提唱者・普及者
SEQは、ユーザビリティ研究と定量的分析の専門家であるJeff Sauro氏によって提唱された。彼は、特定の機能改善の効果を迅速に測定したいという現場のニーズに応えるため、より手軽で、タスクに特化した指標が必要と考え、タスク完了直後のユーザーの記憶が最も鮮明なうちに、その体験の「容易さ」だけを問うという、極めてシンプルなアプローチとしてSEQを開発し、その有効性を広めていった。
Jeff Sauro
https://measuringu.com/about/
具体的な手順
ユーザビリティテストと同様に「商品を検索する」、「購入する」などのタスクを設計し、それごとに質問を1つだけ行う。タスク完了後の記憶が鮮明なうちに「このタスクを行うのはどれくらい難しかったですか、あるいは簡単でしたか？」と質問する。回答は「1: とても難しい」から「7: とても簡単」までの7段階の中で選択させる。回答直後に「その点数をつけた理由を教えてください」と尋ねる。特にスコアが4以下の場合は「具体的にどの部分で難しさを感じましたか？」と深掘りする 。
最後に、収集したデータはスプレッドシートへ、入力: 横軸にユーザー、縦軸にタスクをとり、スコアを入力する。タスクごとに平均スコアを出す。平均スコアが低いタスクの優先度を高くする。難しい理由を参考に、具体的なUIの改善箇所を特定する。
- ユーザビリティテストのタスクを設計
- タスクをひとつずつ検証
- ひとつのタスクごとに検証後、難易度を７段階で質問
- その回答の理由を深堀り
- 次のタスクを検証（繰り返し）
- すべての対象者に検証した後、タスク別に平均をスコアリングし、まとめる
複数質問の精度が良いわけではない
面白いのは、複数の質問で測定したとしても、「使いやすさ」の点で調査の信頼性に違いがないという点である。
例えば、ASQ（After Scenario Questionnaire）は「タスク完了の容易さ」「完了にかかった時間への満足度」「サポート情報の満足度」という3つの項目で構成される 。しかし、実際のテスト現場では、タスクがスムーズに完了できた場合、ユーザーはこれら全ての項目に高い評価をつける傾向があり、逆に失敗した場合は全てに低い評価をつける傾向が強かった（ハロー効果）。
他にも、質問が多いことで回答に手抜きしてしまう、ノイズが入りやすいなど、必ずしも質問が多いことで調査結果が信頼性を得るものではないことが検証されている。（A comparison of methods for eliciting post-task subjective ratings in usability testing）
思考発話法と操作後のSEQを組み合わせて調査する
SEQはタスクが完了した後にしか難しさを調査できないため、具体的にどのタイミングで何をどう感じたから難しかったのかを調査することが難しい。
ユーザビリティテストは、操作しながら考えていることを話す思考発話法を行ったり、戸惑いの理由、理解度合などの多くをユーザーに質問することで、問題をより具体的に深く知ることができる。しかし、それだけではユーザーが自力でタスクを完了させた時に、調査側が「問題がなかった」と認識しやすい。SEQを行うことで、自力ではできたものの悩んだり戸惑うことが多くて実際には難しかったという事実を調査できる。
そのため、操作中における質問を行った上で、タスク完了後にSEQを行うという方法もある。ただし、話ながら操作することが難しく感じたり、タスク完了にかかる時間が増える傾向もあり、SEQのスコアに少なからず影響があることに注意しておく必要がある。
関連用語
- 思考発話法
- 回顧的発話法
