調査目標からユーザビリティテストシナリオを作成する、7つのステップ

ユーザビリティ調査の目標を策定し、何をテストするかを決めて、ユーザーシナリオを作り出すのは困難なものだ。しかし、今回、紹介する手法によって、そうしたプロセスが楽にできるようになるだろう。

From Research Goals to Usability-Testing Scenarios: A 7-Step Method
by Susan Farrell
on September 17, 2017
日本語版2018年2月23日公開

ユーザビリティ調査の中には、テストすべきインタフェース要素がわかりきっていて、数が限られているものもある。しかしながら、システムが複雑だったり、リサーチャーがそのシステムをよく知らなかったり、テストする機能の候補のリストが長い場合も多い。この記事では、7ステップの方法によって、まずテストすべきである最も重要な要素に皆が集中できるようになり、それと同時に、後の調査のために懸案事項のすべてに優先順位をつけることもできる、ということを示す。

7つのステップ

最も重要なユーザータスクを決定する。
システムのどの部分が最大の問題であるかを発見する。
1と2で抽出した項目をグループ化し、そうした課題をユーザーや組織に対する重要度順に並べ替える。
重要度の高い課題のそれぞれについて、情報を問題ステートメントにまとめる。
問題ステートメントのそれぞれについて、調査の目標をリストアップする。
調査の目標のそれぞれについて、参加者のアクティビティと行動をリストアップする。
目標のグループのそれぞれについて、ユーザーシナリオを書く。

さらに大きなプロセスについては、「ユーザビリティ調査の計画のためのチェックリスト」という記事で説明をしているので参考にしてほしい。

重要なのは、利害関係者にこうした計画のステップに参加してもらうことである。というのも、リサーチャーはユーザー調査を実施した後、調査結果に対して抵抗を受けることがあるからだ。たとえば、間違った参加者をリクルートしていたとか、テストした要素が間違っていた、などと言ってくる人がいるのだ。しかし、チームとして、テストの計画プロセスの一部を経験することで、皆が調査の目標や優先順位、手法を理解し、サポートしてくれるようになる。

利害関係者と会う機会が限られている場合は、1と2のステップは前もってやっておいて、3～5のステップを利害関係者とのワークショップで実施し、その後、6と7のステップだけをUXリサーチャーまたはUXチームでやればよい。

各製品で、この全プロセスをおこなうのは一度でいいかもしれない。というのも、このプロセスによって、重要な相互理解や多数の有益な調査課題、潜在的な指標が生み出されるからだ。また、折々に出てくる新機能や課題は、この一度限りのプロセスによって生じる生成物に容易に付け加えることが可能である。

1. 最も重要なユーザータスクを決定する

ユーザーは何をする必要があるのか。このステップでは、ユーザーがシステムで達成できなければならないタスクをリストアップしよう。

どんな組織にも最重要なユーザータスクのリストはあるものだ。なぜならば、このリストは、Webサイトやデバイス、アプリケーションのユーザビリティの評価だけでなく、改善されたかどうかの経時的な追跡にも役立つからだ。理想としては、システムがサポートしているあらゆるタスクの順位付けをユーザーにしてもらって、体系的なやり方で最重要なタスクを取りまとめるべきだろう。

しかし、こうした活動をまだ正式におこなっていなくても、Webサイトのアナリティクスのトラフィックデータ、検索ログのキーワード、調査データ、競合他社の分析などのユーザーデータを調べることで、最重要なタスクは判断できる。また、重要なタスクが明白だったり、わかりきっている場合もある。たとえば、ECサイトでの最も重要なタスクは、商品の購入だ。このタスクは以下のようなさまざまなサブタスクから構成されている：

最重要のタスク：商品の購入
- 希望する商品を探す。
- 類似の商品を比較して、どれを買うかを決める。
- 商品をショッピングカートに入れる。
- 決済プロセスを完了する。
- 購入が完了したことを確認する。
- いつ商品が到着する予定なのかを理解する。

これ以外にも、ECサイトの重要なタスクには、返品する、カスタマーサービスに問い合わせる、前回の購入を調べる、などがある。

2. システムのどの部分が最大の問題であるかを発見する

ステークホルダーが最も心配していることとは何だろうか。多くの組織には、ユーザビリティテストをしようという気になるような懸念があるものだ。たとえば、ユーザーが新しい機能をしっかり理解してくれるだろうか、とか、トレーニングやサポートの費用が減らせないか、ある事柄をユーザーがする（あるいは、しない）理由を明らかにしたい、などがそうだ。ユーザーを不快にさせる課題、組織に費用の負担がかかっている問題、達成するのに時間がかかりすぎるタスクを探してみるとよい。

ステークホルダーがこうした項目のリストをまだあなた方の部屋のドアに貼り出していないなら、製品チームのメンバーやカスタマーサポートのスタッフ、販売員、ソーシャルメディアやドキュメンテーションの担当、トレーナーにインタビューすれば、最も大きな懸念や、どうしても質問したいことが発見できるはずだ。他にも、検索ログやFAQ、カスタマージャーニーマップ、カスタマーサポートやトレーニングのスタッフが作った、テストで調べると有用そうな課題を挙げた資料などの証拠がある場合もある。システムの設計レビューの実施も、テストをすると有益そうな課題を見つけるための良い方法である。

3. 1と2で抽出した項目をグループ化し、その課題をユーザーや組織に対する重要度順に並べ替える

関連のあるユーザータスクやステークホルダーの懸念、質問をグループ化しよう。このプロセスでは、付箋紙やホワイトボード、スプレッドシート、カードソーティングシステムが役に立つ。グループ化した課題のリストは1回で調査するにはおそらく量が多すぎるだろうが、長い期間、役に立つものなので、すべて取っておこう。重要なのは、そこにユーザータスクが含まれていることである。なぜならば、ユーザーのやりたいことや、やる必要のあることが、ステークホルダーの懸念に常に含まれているとは限らないからだ。とはいえ、最重要なタスクはユーザブルでなければならないので、テストが必要になることが多いのである。

可能なら、ステークホルダーの代表者と一緒に、課題の優先順位付けをチームとしておこなおう。

関連する課題のグループそれぞれに名前を付けたら、それをスプレッドシートに記入し、並べ替えて、優先順位を決めよう。優先順位はいろいろなやり方で決めることができるが、ユーザーに関する目標とビジネスに関する目標の両方を考慮したシンプルな例が以下である。

課題	重要度ランキング
名称	ユーザー	組織	総合得点
カスタマーサービスの品質への苦情	5	5	10
検索結果の品質に関する課題	5	3	8
ステレオが比較しにくい	2	5	7
シェア機能が十分に使われていない	0	5	5
ポッドキャストを聞く人がほとんどいない	0	4	4

順位付けには、スプレッドシートとポイントシステムが役に立つ。つまり、名前をつけた課題を、ユーザーの懸念および組織への利益とコストを考慮して、重要度の最も高いものから最も低いものの順に並べ替えればよい。

組織とユーザー両方への重要度によって、課題に順位を付けよう。ステークホルダーや課題が多い場合は、（たとえば、丸ラベルやコインなど）票の代わりになるものによる投票や、アンケートプラットフォームのランキングシステムの利用を検討してみよう。

このステップの目標は以下である：

重要な事柄をすべて捉える。
課題のリストに迅速に優先順位を付ける。
合意を形成する。

得点の付け方にこだわる必要はない。重要な課題をスプレッドシートにリストアップして、1つの列にユーザーにとっての重要度を、別の列に組織にとっての重要度を入力しよう。もし、課題の数が多ければ、最も重要度の高い10～15個の課題のみを表に入れて、順位をつければよい。そして、課題ごとに、ユーザーと組織の得点を合計したら、総合得点によって行を並び替えよう。

それと同時に、次のユーザビリティ調査で重点的に取り組む課題を選ぼう。総合得点は優先順位付けや合意の形成には重要だが、たとえば、コストのかかる問題や新しい機能など、ユーザーに対する得点が0なのに、組織に対する得点が高い課題はテストしたほうがよい場合もあることは覚えておこう。

ヒント：もっと精度が必要なら（たとえば、リストアップされたタスクが大量にある場合や、テストの回数が非常に少ない場合、商品の変更に非常に費用がかかる場合など）、ユーザーとステークホルダーに別々にアンケートを取り、重要度の高いタスクや懸念を明らかにして、順位付けをするといいだろう。（UXプロジェクトのための「順位付けテクニックについての動画」（2分間）を参照してほしい）。

4. 重要度の高い課題のそれぞれについて、情報を問題ステートメントにまとめる

問題ステートメントは、皆を重要な事柄に集中させ、そして、調査の目標を皆が解決したい課題に結びつけやすくするものだ。既知の問題をリストにしておくと、調査活動の正当性が説明しやすいし、賛同も得られやすくなるからだ。また、問題ステートメントは、改善したかどうかを経時的に追跡するために測定する指標であるともいえる。時には、こうした問題ステートメントが質問を含むこともある。そして、関連する課題が1つの問題ステートメントにまとめられるので、問題ステートメントは重要な課題よりも最終的には数が少なくなる可能性もある。そうした場合、問題ステートメントに優先順位を付ける必要があるが、ステップ3で決めた課題の優先付けなどの方法が使えるだろう。

ステークホルダーにはこのステップにも参加してもらおう。人というのはユーザー調査の過程で一定の役割を果たした経験があれば、とても楽にその調査の結果を受け入れたり、それに従って行動したりするものだからだ。

このミーティングの目的が、最初にテストすべき最も重要な事柄が何で、どうやってそれをテストすべきかを決めてもらうことである、と説明しよう。
ステップ3で得られた課題の詳細なリストを皆で共有しよう。
大きなホワイトボードに課題の名前を書き出して（あるいは、チームの場所が分かれているなら、一緒にテキストを書けるように、ドキュメントを共有して）、それぞれの問題ステートメントの下は余白にしておこう。
関連する課題を問題ステートメントにまとめよう。たとえば：
問題：ユーザーがカスタマーサービスに電話してくる。なぜならば、ネットワーク照明システムのセットアップのやり方の説明が見つけられない、あるいは、その説明が理解できないからだ。カスタマーサービスの電話には非常に費用がかかるし、ユーザーは電話してくるときに腹を立てている。
（ステップ3のように）課題の得点を合算したり、投票をしたりして、テストのために、問題ステートメントに優先順位を付けよう。

5. 問題ステートメントのそれぞれについて、調査の目標をリストアップする

問題ステートメントは調査の目標を示すものだ。たとえば、上述の問題ステートメントで考えると、それに対応する調査の目標は以下のようになる：

セットアップのプロセスのどこでユーザーが説明を必要としているかを明らかにしよう。
ユーザーが説明を見つけられない理由を知ろう。
説明の最適な配置場所を決めよう。
改善する必要のある説明を見つけよう。
製品を改善するチャンスを見いだし、説明が最小限ですむようにしよう。

調査の目標の中にはユーザビリティテストでは扱えないものもある。そうした場合は、どの手法を利用するほうがいいのかに留意し（たとえば、アンケート調査がいいのか、アナリティクスがいいのか）、その目標は今回の調査の対象から除外しよう。

6. 調査の目標のそれぞれについて、参加者のアクティビティと行動をリストアップする

調査の各目標に対処するために、観察する必要のあるユーザーのアクティビティと行動をリストアップしよう。

調査の目標や問題ステートメントはかなり抽象的で、ハイレベルなものになってしまうこともある。ユーザビリティテストでこれらに取り組むためには、こうした目標や問題に関連するアクティビティをユーザーが達成しようとしているところを観察する必要がある。このステップによって、（1）調査の目標に関連するユーザーのアクティビティの種類、（2）特定のアクティビティの成功や失敗の合図となるユーザーの行動、（3）そのアクティビティをおこなう際にユーザーが利用できそうな手順や問題解決の方策、を特定できるようになるだろう。

たとえば、「セットアッププロセスのどこでユーザーが説明を必要としているかを明らかにしよう」という目標に対するセットアッププロセスのアクティビティとしては以下のようなものが考えられる：

照明システムを箱から出す。
照明ユニットを組み立てる。
照明ユニットをネットワークに接続する。

そして、成功や失敗の合図として、参加者の取りうる行動には以下のようなものがあるだろう：

質問をすること（彼らの言い回しを正確にメモしよう）
1分以上、立ち往生していること
助けを得るために誰かに連絡を取りたがること（誰にどうやって連絡を取りたがっているかをメモしよう）

また、そのアクティビティを達成するためにユーザーが利用しそうな問題解決の方策には以下のようなものがあるかもしれない：

説明を箱の中や箱の上で探すこと
Webサイトで説明を探すこと（検索キーワードやナビゲーションの経路をメモしよう）

目標ごとにこうした分析をおこなったら、1つのシナリオで複数の目標を扱えるように、アクティビティや行動観察の結果のすべてまたは多くが共通している目標を1つのグループにしよう。

この事例でリストアップしたアクティビティと行動は、「ユーザーが説明を見つけられない理由を知ろう」、「説明の最適な配置場所を決めよう」、「改善する必要のある説明を見つけよう」という目標も対象に含んでいるように思える。そして、この問題ステートメントの最後の目標である、「製品を改善するチャンスを見いだし、説明が最小限ですむようにしよう」は、あなた方と観察者に調査中に浮かんだアイデアによっておそらく対応できるだろう。

このレベルまで詳細に計画することによる主なメリットは以下の4つである：

シナリオ（ステップ7）で観察したいことに集中できる。
セッション中、気をつけなければならないことに観察者が集中できるようになる。
成功や失敗の基準の粒度を決められる。
たとえば、（照明システムの設定のような）一体となった1つのユーザーアクティビティを基準にする代わりに、参加者がうまく達成できたサブタスクの一部やすべてにポイントを与えるかどうか（あるいは、そうしたサブタスクの成功や失敗を単に追跡するかどうか）を検討してもよい。
参加者にどこまで自由にさせるか、また、テスト環境はどのくらいの規模にする必要があるか、参加者にどんな指示をすればよいか、をあらかじめ決めやすい。

たとえば、今回の事例では、以下のことについてどうするのかを決める必要がある：

通話のプロセスがどのくらい有効であるかを調べるために、参加者の声を聞く。
サポートチケットのフォームを埋めるのがどのくらい大変そうかを明らかにするために、彼らがサポートチケットを作成しているところを見る。
彼らがサポートに送るつもりである質問を入手する（どのようにして？）。
カスタマーサポートのサイトに目を通してもらう（どのくらいの時間？）、または、単にカスタマーサポートのランディングページを探してもらう。
参加者に、以上のどれかをやってもらえるように促したり、逆に、やらないように指示したりする（その際、ファシリテーターが言うべきことはどのように言い表すのが一番いいだろうか？）。

7. 目標のグループのそれぞれについて、ユーザーシナリオを書く

シナリオとは、調査中にテスト参加者が読む指示のことである。今回、調査の目標（ステップ5）とそれに対応するアクティビティ（ステップ6）の例として挙げたリストに対する適切なシナリオは以下のようになる：

新しく買ったAcme Home Illumination Kit（ネットワーク照明システム）をどのようにセットアップするかを見せてください。そして、そのシステムを組み立てている間、考えていることや、やっていることを細かく説明してください。

運が良ければ、このシナリオに取り組む参加者が、必要に応じて、説明を見つけて、それを読んでくれて、さらに、彼らの思考を解説するために、考えていることを声に出して言ってくれることだろう。その結果、システムと説明に関しての彼らの困難さを理解できるようになるというわけだ。

例に挙げている状況はかなりわかりやすいので、このシナリオはわかりきったものに見えるし、そこに到達するためのステップも意味のないもののように思える。（とはいえ、シナリオとは、思考や計画のプロセスを、参加者がすぐ理解できるシンプルな文に落とし込んだものでなければならない）。

それにもかかわらず、この手法は複雑で大きなシステムを解きほぐし、優先順位が競合し合っている部屋いっぱいにいるステークホルダーをおとなしくさせて教育し、調査課題を優先順位付けした長い間機能するリストを作り出し、調査計画や進行役の台本、観察者用の調査ガイドを用意しやすくし、ユーザビリティ指標を生み出し、そして、ユーザビリティセッションの実行や不測の事態についてじっくり考える助けになってくれるものなのである。

ヒント：

目標の中には、複数のシナリオを導き出してしまうものもあるし、シナリオの中には、複数の目標が対象になるものもある。このプロセスに取り組みながら、シナリオが長くなりすぎたり、複雑になりすぎることなく、そうした目標をどうシナリオにまとめられるかについて考えてみよう。
同様に、問題ステートメント同士でも、目標やアクティビティのリストの作成中に自然に重複が発生するだろう。リストの作成後、一部のステップを削除したり、いくつかのシナリオを統合したり、連続したものにして、アクティビティの繰り返しを減らしたり、（あるシナリオを実行することで、ユーザーが他のシナリオについてもいろいろと知ってしまうような場合の）バイアス効果を低減できないかどうか考えてみよう。各参加者がたくさんの検索をするのを見ることに意味がある場合もあるが、それ以外のアクティビティについては参加者ごとに一度か二度見ればいいだろう。

シナリオを書くためのガイドライン

効果的なシナリオを書くこと、また、タスクの具体的な指示でのよくあるエラーを回避すること、のための記事を過去に我々は書いている。そうした記事の内容を簡単にまとめると以下のようになる：

シナリオでは、ユーザーの動機になりそうな成果を中心に置く。
観察する必要のある事柄をユーザーがやらざるをえないようなシナリオを書く。
ユーザーインタフェースの操作をユーザーに指示しない。
インタフェースのラベルに言及しない。（例外は検索についてのテストでの「検索する」だが、その言葉を口に出して言う前に、ユーザーが自分で検索ツールに気づいたり、どこにあるかを見つけたりするかを確認しなくてもいいのかを考えよう）。
参加者が理解できる一般的な単語を使用し、専門用語やそのブランド特有の用語は使わないようにしよう。

次のステップ

調査の目標に合ったシナリオを作成したら、その次のステップは、通常、以下のようなものになる：

ユーザー調査活動に対する賛同を得て、合意形成し、最も重要な課題に集中できるように、ステークホルダーに調査セッションを観察してもらう。
何を測定して、どう得点化するかを決める。
セッションのパイロットテストをして、シナリオやプロセスの修正をし、セッションごとにいくつのシナリオに取り組むかを決定する。
上記の7ステップから生み出された情報を調査の全シナリオのための調査プランに組み込む。その残りの情報も将来の調査のために文書化しておく。
ステークホルダーを調査セッションに招待して、メモを取る手伝いをしてもらう。

結論

この7つのステップからなる手順は、何をテストするのか、それをどうテストするのか、そして、わかりやすいユーザーシナリオをどう書くのか、を楽に決断できるようにしてくれるものだ。また、その各ステップで生み出されるリストによって、調査の目標の優先順位付けができ、調査セッションのための賛同が得られ、調査セッションや資料の準備が進んで、重要な課題の経時的な追跡もしやすくなるだろう。

キーワード　