プロダクトなどの課題をユーザインタビューなどで調査した結果をもとに、プロトタイプを作ることになった。では、それをデザインをした後はどうすればいいのか？

やるべきはUXリサーチの”評価”である。作ろうとしているデザインはユーザはきちんと課題をクリアしてくれるのか、それを評価する必要がある。そしてそれを元に改善し、評価と改善を繰り返すという流れだ。

評価方法にはさまざまあるが、本書ではユーザービリティテストをとりあげている。これは数あるUXリサーチ手法の中でも、最も使用頻度の高い最重要手法である。

今回はUXデザイナー志望者としてぜひとも知っておきたいユーザビリティテストを学ぶべく本書を手に取ることにした。参加者集めからテストの実施までを取り上げる。

本書の構成は以下の通り。

ユーザビリティテストとは？

ユーザビリティテストとはUXリサーチの評価手法の一つである。
ユーザに実際にタスクをこなしてもらい、その様子を開発者やデザイナーが観察する。

そしてもう一つ重要な点が、ユーザに思ったことを口に出しながらタスクを実行してもらうことである。これは思考発話法と呼ばれ、ユーザの認知プロセスが明らかになり、操作の失敗や不満の原因を論理的に分析できるようになる。

観察のポイントは以下の３つである。

①ユーザが独力でタスクを完遂できるか（効果）
②ユーザは無駄な操作を行ったり、戸惑ったりしないか（効率）
③ユーザは不安や不満を感じていないか（満足度）

評価では②が重要視されがちだが、３つを満たしてこそ良いプロダクトが生まれる。

テストの参加者は５人で十分であるが、問題が見つかった後に改善したものを再度テストする必要があるので、通常は５人のテストを２〜３回、のべ１０〜１５人のテストが必要になる。

また、ユーザの行動を観察して問題点を発見するので、インタビューのように質問を投げかけてはいけない。

テストではユーザの近くで案内や観察をする司会者、参加者の見えない別室などで見学者がいる。プロトタイプを作った開発者やデザイナーなどが見学者となる。

参加者をどう集めるか

ユーザビリティテストは①リクルート②設計③実査④分析の４ステップで実施し、期間は１〜２週間（慣れていない場合２週間は確保しておきたい）である。

このうち参加者集めであるリクルートが最も時間がかかり、かつ重要なステップである。

では参加者の条件はどう決めるのか？通常そのプロダクトを利用する「代表的なユーザ」にあてはまる人物をリクルートする。
代表者像は求人広告のような３０字前後の一行ステートメントで簡潔にまとめられる。

最も重要なのは性別・年齢・職業などのでもグラフィック属性ではなく、そのプロダクトのユーザ特有の行動を定義することである。
プロダクトの”操作”はできても、”使用”はできないかもしれない！

条件を決めたらチャネルを使って実際に人を集める。

最も確実で楽なのは調査会社のモニターを利用することであるが、ある程度の費用がかかる。

顧客という手もあるが、営業や顧客管理部門の許可など社内調整が必須である。

SNSや友人を使った人脈も有効な手段である。相手がどんな人物か分かり易いのでテスト参加者の質は上がる。

タスクの設計

ユーザビリティテストでは、ユーザに作業課題（タスク）をしてもらう。
例えば、ECサイトで商品を購入してもらったり、スマホで撮った写真を加工してもらったりする。

一見タスクのようで、タスクでない似非タスクも存在する。

「ボタンを押す」、「メニューを選択する」といった”動作”、「ヘルプ」、「ズーム」といった”機能”はユーザの手段であって目的ではないのでタスクではない。

またビジネスゴールにも注意する。例えば「マンションの販売」ならば、タスクは「マンションの購入」よりも「気に入った物件の見学申し込み」のほうが適切である。

タスク設計には以下の４原則が存在する。

①主要なタスクに絞り込む
ユーザの利用目的はさまざまなので細かい場合分けをするとキリがない。

②ユーザの視点で発想する
UIはユーザの目的達成のために存在する。開発者の目的（動作・機能・ビジネスゴール）をタスクとしないようにする。

③スタートとゴールを明確にする
ユーザがタスクを達成したかの判断にはゴール地点が必要である。またスタート地点も決めておかないと経路がぐちゃぐちゃになってしまう。

④シナリオ化する
いきなり「このサイトで店を探してください」などと言われても戸惑ってしまうので、仮の状況設定をして物語風にする。そうすることでユーザは自身の体験を思い出しながらプロダクトに向き合える。

タスクの作り方

タスクの作り方には手順がある。

①ユースケースのリストアップ
そのプロダクトを使ってユーザがどのようなことをするのかをリストアップ

②ユースケースの選択
次にテスト目的に適したユースケースを選ぶ（今回ならば基本的な利用体験である「探す／予約する／変更する」）。

③シナリオ設定
選択したユースケースが成り立つ仮の状況を設定する。

「（仮に）あなたの部署で送別会があるとします。今回、あなたが幹事を務めることになりました。部内で調整したところ日程は〇月×日、人数は10名くらいになりそうです。」

④タスク指示文の作成
ユーザにタスクを指示を与えるための文章を作成する。

●タスク1：「飲食店情報サイトXを使って送別会のお店を探してください。候補を3店舗くらい見つけてください。」
●タスク2：「A店に予約を入れてください。」
●タスク3：「参加人数が15名に増えそうです。予約を変更してください（場合によっては店舗を変更しても可）。」
※必ず1タスク1カードで提示

テストの設計

テストの構成要素を設計したらインタビューガイドを作成し、司会者は原則その通りに進行する。

なお事前に必ずパイロットテストを行うようにする。テストの問題点を見つけるためなのでタスクの達成は重視しなくて良い。

ユーザビリティテストはタスクだけではない。
ユーザの人物像を把握する事前インタビューやタスク終了行後に感想や主観評価を尋ねる事後インタビューも必要になる。

ユーザとは事前インタビューと同時に信頼関係（ラポール）を築くように努め、スムーズにタスクに移行できるようにする。

事後インタビューでは率直な感想を聞いた後、主観的評価（５段階評価で満足度、再利用意向度など）を回答してもらう。

最後に見学者からの質問を受け付ける。別室からチャットツールなどで送ってもらい、司会者が取捨選択して質問する。

司会者の心得

タスクを見守る司会者はいくつか心得ておかなければならないことがある。

それはタスクの観察中はユーザに話しかけてはいけないこと、さらに質問などにも答えてはいけないことである。司会者の話がユーザの認知に影響をあたえてはいけないので、基本的には無口を貫く。

もしユーザが本当にタスクを達成できそうにない場合は、ちょっとした介入や誘導することができる。しかし、その場合タスクは「未達」とする。

タスクが終われば会話は解禁されるので、気になったことがあればそのときにユーザに聞く。

ユーザビリティテストは実際にプロダクトに触れることでユーザが何を思って行動するのかが推察できる貴重な機会である。
事前によく知識を蓄えて実際のテストに臨みたい。

このテストはパイロットテストだけでも価値がありそうだ。
以前紹介したオブジェクト指向デザインの本の冒頭部で、牛丼屋の食券機の話があったのだが、

その食券機はお金を入れる前にメニューをタッチすると「先にお金を入れてください！」と注意される。目についたメニューを選択して、最後にお金を払うのが自然な流れだが、著者が観察していた１０人中８人が注意されていたというのだから、この食券機のメーカーはパイロットテストすらしていないのが想像がつく。

リクルートの件は、大学で心理学を学んでいた際も実験参加者を集めるのにかなり苦労したことを思い出した。やっと参加者を集めても当日になって現れないことも多々あった。そういった時は謝礼で用意したお菓子があまるので少しだけ嬉しかったが…

当時は定量的なデータを集めることに集中していて参加者がどう感じているかなどの定性的データを過小評価していた節がある（そもそも自分の実験ではそんなデータをとっていなかった）。とりあえずSPSSに数値を入れ仮設検定の有意差が出ればOKというような、まさに官僚主義的な作業だった。

数字ばかりにとらわれず、自分の観察したありのままの状況をよく解釈し、議論してUX向上に役立てていきたい。