taninnosorani blog

What is the UX Workflow?

ユーザビリティテストのタスクシート

ユーザビリティテストの進行やユーザーの行動などを記録するタスクシート(プロトコルのようなメモや議事録の雛形)を作成しました。ただユーザビリティテストを専門で行っているわけではないので、要素の抜け漏れなどはあるかもしれません。ユーザビリティのテストプラン作成やレポート作成、被験者のリクルーティングなどは参考情報をご参照下さい。ここではユーザビリティテスト全体ではなく、インタビュー中に使用するタスクシート(インタビューシート)に関してになります

2014/10/2 新しいタスクシート(ver2)を追記しました

ver2の変更箇所

  • ver1ではフェイズ毎に別の列を記載していましたが、ver2では全て共通の列名を使用しています。列名がバラバラであったためスプレッドシートにしては複雑なレイアウトなっていました。今は列行は1つなので固定行にしてスクロール時にも見やすくなりました。
  • 経過時刻を記載する列を追加しました。進行管理を行うときに遅れているのか進んでいるかのをすぐに把握するためです。
  • テストからの気付きを記載する「テスト結果の感想」列と、タスクを実施するための準備を記載する「準備・メモ」列を分けました。
  • 達成や効率などの評価ポイントを自動で計算するようにしました。ちなみにこのポイントは数字が多いほどユーザーが躓いたことを表します。
  • 13inchのMacBookでなるべく収まるように全体的に幅を短くしました。



各ステップ ~ユーザビリティテストの構成~

1.アンケート

リクルーティング時に被験者のリテラシーを全て把握していれば必要はありませんが、社内などの身近な方を対照するディスカウントユーザビリティテストなどではデモグラフィックのデータが揃っていないことが多いので、ここでセグメントを分類するためにアンケートを記載していただきます。このアンケートの目的はテストするサービスにどれだけ接点があるかです。利用頻度サービスをどの程度まで理解されているかで、その後のテストの進め方にも影響します(例えば、実はハードユーザーであったのなら初心者向けタスクはスキップするなど)。もちろん外部や専門部署へリクルーティングを依頼する場合には、前もって設定したリテラシー範囲を挙げる必要があります。

2.テスト前のお願い

アンケートの後には、思ったことをそのまま口に出してもらう思考発話法の実践していただくようにお願いをします。ただし、ユーザビリティテストに慣れていない方にこのお願いをしても、すぐにはうまくいきません。そのためテストの最中に考えていること聞いて話を促しますので、わざわざ発話法に触れなくても良いと思います。そもそも発話法に慣れている方というのは被験者としてはあまり参考にならないかもしれません。他には被験者を評価しているわけではないことや、テスト中に質問されてもヒントになってしまう場合は答えられないことを伝えることが推奨されますが、儀式なようなものなのでアンケート後はすぐに状況説明をして良いと思います。

3.状況説明

いきなりプロトタイプ(スマフォやPC、またはペーパープロトなど)を渡すのではなく、感情移入しやすいようにテスト前の状況の経緯を伝えます。例えば、Webサイトのテストなら対象のサイトが表示された端末を渡すのではなく、「あなたはXXXが気になったので、GoogleでAと検索して、一番上に表示されたBというサイトをタップしました」と伝えてから始めます。こうすることで被験者がより自分の実体験に置き換えて実際の行動に近づけやすくなります。この状況はUXプロセスのストーリーで設計したシナリオを当てはめます。考えたシナリオは状況説明だけではなく、この後に行うテストにもシナリオがベースとなります。

4.テストの実施

テストのタスク内容もシナリオを流用します。ユーザビリティテストの実施を見越してシナリオの元になるプロット(http://taninno.github.io/blog/2013/05/16/my-ux-design-approach/)を作成しておくと良いかと思います。このようなユーザーのタッチポイントや操作順序、時間経過をまとめたプロットがあればタスクシートの作成も簡単になります。

5.質問(回顧法)

テスト中に思った疑問を聞きます。インタビューアーの方ならテスト中でも「どうしてXXXを選択したんですか?」など聞きやすいですが、メモをとっていた人や別室でウォッチしている人は疑問をまとめて後で質問します。インタビューアーの方でもFive-Whysなどでコアな理由・原因を知りたいときにテスト後の時間を利用すれば、時間超過やタスクのヒントを言ってしまうことも防げます。また、サービスの全体的な印象を聞いたり、100満点で点数をつけてもらうときもここで行います。あとは逆に被験者からの質問・もやもやしていることを聞いたりします。



タスクシートの項目について(ver1)

下記の表の各列を左から説明します。

タスク

タスクの項番です。

目安

個々のタスクにかかる時間を記載します。ここでは分単位にしています。被験者によって大きくことなるので目安として設けています。

優先度

時間が足りなくなってきた際に、どのタスクをスキップすればいいのかを判断するために記載します。

発言

インタビューアーが被験者に質問する発言内容です。慌てても大丈夫なように台本のような見本となるセリフを記載します。ただし棒読みしてしまわないように自分なりの言葉に言い換えたほうが良いと思います。

補足:インタビュー中のポイント
  1. ユーザーが「~できるんですか?」と聞いてきたら「どう思います?」と逆に聞き返す。
  2. ユーザーが思考発話でひとりごとを発している時には、「そうなんですね」とオウム返しをしてあげる。
  3. ユーザーが少し戸惑っていたら、「どうしました?」と聞く。
  4. ユーザーが操作を中断してしばらく経ったら、「~あたりに何かないですか?」とヒントを伝える。

ポイント

当該タスクの目的を記載します。テストで確認したい箇所や着眼すべき箇所がどこなのかをハッキリさせます。

想定する行動

被験者の操作手順が最もベストだと思える操作を記載します。ここに記載する流れは既にシナリオで作成した内容になります。個人的にはユーザビリティテストで大切なことは個々のタスクの流れがシナリオ通りに進めているかを見つけ出すものだと考えています。

実際の行動

被験者がどのような操作や発言をしたのかを記載します。

メモ

記載者が個人的に気付いたことを記載します。被験者の発言からの発見やテストの改善など気になったことをメモする欄です。

達成(効果/effctiveness)

  • ◯はタスクを完了した場合
  • △はインタビューアーのヒントを得てタスクを完了した場合
  • ☓はタスクを完了で来なかった場合

効率(efficiency)

  • ◯は想定の操作通りにできた場合
  • △は多少迷っていた場合
  • ☓は目安時間を超過した場合

満足(satisfaction)

  • ◯は被験者が特に不満を持っていないと思われた場合
  • △は不満を持っていそうだと思われた場合
  • ☓は不満を露わにしていた場合

評価(インパクト分析)

達成・効率・満足を数値化してどの操作(タスク)が問題となっていたかを把握します。数値は一般的な優先順位付けではなく、重要度を測りやすくするため、数値が多いほど問題が大きくなるようにします。係数は以下の表の通りです。タスクが正常に完了すれば0、最も深刻な問題は12となります。

—— 達成  効率  満足
0 0 0
3 2 1
5 4 3


参考情報

URL

書籍