制作の流れ FLOW

ここでは、良いサイトに仕上げるために、ユーザテストを行います。
よいサイトとは「ユーザが考えずに目的のコンテンツにたどり着けること」です。

「どんな選択肢があるのか一目ではわからない」
「選択肢は程よい数があり迷わない」
「今すぐ買いたいのにどうしたらよいかわからない」
もしこんな使いにくいサイトだったら、困りますよね。
もちろん、「文章で説明してある」と思うかもしれませんが、そもそもWEBユーザは文章を読んでくれません。つまり、わからない＝即離脱につながります。
こうならないためにも、直感だけで目的のコンテンツに辿り着ける必要があります。

そのために、仕上げのユーザテストは不可欠です。
なぜなら、会議室で議論するよりも、ユーザの行動を見れば問題点が一目瞭然だからです。

ユーザ中心設計では、この「ユーザテスト→プロトタイプ」を繰り返すことが重視されています。
目指すは、「考える必要のないサイト」です。
そのために行うのがこのユーザテストを行いましょう。

ユーザーテストの概要

ユーザーテストといっても、ユーザに自由にサイト（まだ未完成のプロトタイプ）を見てもらうわけではありません。ユーザは、司会者が設定した状況にあるつもりで、指示されたタスクを実行してもらいます。
なお、ここでは「中古書籍サイト」のユーザテストを行う前提で解説します。

　　　実際の設置した図
　　↑キャプション）ユーザが操作するPC（あるいはスマホ）の画面を撮影用のスマホで撮影します。
また、会場全体を写すスマホも設置しておきます。
各スマホと見学者用のPCをオンラインミーティングツール（例：Zoom）で会議している状態にします。そうすることで、見学者もユーザの操作を閲覧したり、録画することができます。

被検者

被検者は、サイトの商品を利用する可能性のある人が対象となります。
この被検者を選定するには、「３．コンテンツ設計」のときに定義したターゲットを参考にしてください。
たとえば、中古書籍の販売サイトなら、中古本を飲むことがあり、サイトから購入できるスキルを持つ人です。
さらに、サイトの性質によっては「月〇回以上購入する人」や「性別」「居住地域」などで絞っても構いません。

被検者の数に関しては、ヤコブニールセン氏によると5人と言われています。
しかし、５人を一度にテストせず、最初に問題点が発見できたらすぐにプロトタイプを修正し、次のテストを行うことがおすすめです。そうすることで、少ない人数で改善が期待できるからです。
理想を言えば、十数人以上テストし、自信を持ってサイトを公開したいところです。

見学者

運営側、制作側の立場でユーザテストを見学し、問題点を発見する役を担います。
できるだけ全員が見学をすることがおすすめです。というのも、結果レポートを見るよりも、ユーザの行動を見ることで問題点が一目瞭然になることがこのテストの目的だからです。

タスクの設計

タスク実施中は被検者にヒントを与えたくないため、タスク設計は綿密に行います。
その上で、テスト実施中は司会者はただ忠実に設計通りに進めるのです。

タスク設計

タスクは「シナリオ」と「タスク１～３（多くとも５つ程度）」で成り立ちます。各々、A4一枚にプリントしておき、被検者に見せながら読み上げるのです。

・シナリオの例

「あなたはよく中古の書籍を買われるということでした。ちょうど、買っていた本を読み切ったため新しい本を読みたいと思っています。」
なるべく被検者がこの状況になりきれるようなシナリオを考えます。
×よりリアルにするために、下記のような対話でシナリオを仕立てることもできます。
×司会者：「どんなときに中古の書籍を読みたいと思いますか？」
×被検者：「本を読み終わった時です」
×司会者：「では、その状態であると思って、タスク１…」

・タスク１の例

「あなたの勤務先で書店に立ち寄りたいと思っています。
それでは、新宿駅近くの書店を探してください」

・タスク２の例

「あなたは書籍〇を読みたいと思っています。この書籍を探し実際に購入してください。」
※以下、タスク３の例、略。

×ただし、「〇を購入してください」だけだと、単なる作業になってしまい、リアルなサイト閲覧状態ではなくなってしまいます。
×そんなときは、「あなたが好きなのは誰の写真集ですか？」「それでは3分でこのサイトから探して購入してください」といった、シナリオを作っておいたほうがよりリアルです。

タスク設計の注意点

・検証したいところだけに絞る

被検者に行わせるので、タスク数は時間的な制限があります。本当に検証したいタスクだけに絞りましょう。

・リアルさ、実際にあり得るか？

ユーザにはできるだけリアルに近い状態でテストを行ってもらいます。そのため、状況を設定しなぜそんな行動（タスク）を行うモチベーションを高めてもらう必要があります。
単に「…ボタンを押してください」「…ページに移動してください」というのは、タスクではなく作業です。
ユーザが能動的に見ている状況を作り上げる工夫をしてください。

・スタートとゴールはあるか？

スタートは定めてあっても、ゴールが明確でないことがあります。必ずゴールを定義しておきましょう。

・運営側でパイロットテストを事前に行う

タスクなどをブラッシュアップするために、運営者側で必ずパイロットテストを行っておきましょう。

タスクの実施

１．状況説明

タスク設計で設定したシナリオを読み上げると同時にそのプリントも手渡します。

２．タスクを与える

タスク設計で設定したタスクを読み上げると同時にそのプリントも手渡します。

３．ユーザは思考発話をしながら操作する

ユーザには「今やろうとしていること」や「今感じていること」をつぶやいてもらいながらタスクを実行してもらいます。（思考発話と言う）
これが、サイトの改善の大きな手掛かりになります。
ただし、すぐに思考発話がうまくできません。そのため、事前に司会者が別のサイトを例に手本を見せておくとよいでしょう。

口出し厳禁

タスク実行中は、司会者は手助けをしてはいけません。サイトを使う時の状態に近づけて検証したいので、ただ黙って観察します。
ですので、事前に「テストの性質上質問には答えられない」旨、伝えておかなければなりません。

しかし、こそっとアシスト

口出しはできませんがあまりに思考発話がうまくいかないなら、司会者がそっとつぶやき被検者をアシストするのも一つのテクニックです。ただし、被検者との会話にならないように注意します。
　・「今、何をご覧になっています？」
　・「何を考えています？」
　・「何をしてます？」
　・「次にどうしようと思っています？」
　・「これは期待どおりでした？」
　・「どうなると思っていました？」
　・「なぜそう思いました？」
　・「今のお気持ちは？」

４．結果を測定する

・効果測定）タスクを遂行できたか？

〇（独力でタスクを完了）　△（タスクを完了したが無駄な操作や戸惑いがあった）×(タスクを完了できなかった)で評価します。

・効率測定）どのくらい早くできたか？

タスク開始から完了までの時間を計測します。

・満足度）満足度を聞く

タスク終了後に、サイトの満足度を５段階評価で確認します。

・率直な感想を聞く

タスク終了後に率直な感想を聞きます。
もし良い点を話したら、反対に悪い点を聞きます。そうやって両面を確認します。
ただし、「何が悪かったですか？」とは聞いてはいけません。単に「～が見つからなかった」という事実だけにとどめます。ここでもやはり、「なぜ、どうしたら」を考えるべきなのは運営者です。

結果分析

見学者のメモや記憶から問題点をリストアップし、何を改善するかを決めます。その際、測定した結果も参考にします。
できればテスト直後に、見学者で認識をすり合わせをし、録画などを見直しながら改善点を洗い出します。記憶が新しいうちがベストだからです。
なにを改善すべきかが決まったら、プロトタイプを修正し再度ユーザテストを繰り返しましょう。