はんなりと、ゆるやかに

アジャイル、スクラムが好きなITエンジニアが日々から学んだことをアウトプット

ユーザビリティテスト実施前に! / UXリサーチの道具箱IIを読んだ。

UXリサーチの道具箱II ―ユーザビリティテスト実践ガイドブック―を読みました。実践ガイドブックという名のとおり具体的な内容でした。

ユーザビリティテストに必要なことがわかる

ユーザビリティテストを簡単に説明すると、開発中のプロダクトをユーザに触ってもらって改善のヒントを得る手法です。

簡単に説明できますが、実践は難しいです。ユーザはどうやって呼ぶのか?謝礼は?実施方法は?実施したあとの分析方法は?などなど知るべきことがたくさんあります。

そして、本書はそれを1から10まで教えてくれます。目次はこんな感じです。

  • Chapter1 ユーザビリティテスト概論
  • Chapter2 求人ガイド
  • Chapter3 設計ガイド
  • Chapter4 実査ガイド
  • Chapter5 分析ガイド
  • Chapter6 UTちょい足しレシピ集
  • 附録 UTタスク事例集

個人的には「求人ガイド」でユーザのリクルート方法が書かれている点が特に実践的だと思いました。ヒアリング方法、分析方法が学べても、ユーザを集められないと何もできませんもんね。

本書を読んで特に気になった部分をまとめていきます。

コストだけでなく成果の大きさも考える

「求人ガイド」の項目はテスト計画やリクルートについて学べます。その中でコストについてもまとめられていて、謝礼やリクルート費用、参加者の工数について書かれています。具体的な金額も書かれています。

その中で「気をつけないとこの罠に嵌ってしまいそうだなー」ということが書かれていてました。それは、工数を削減するために最少人数で進めて、それ以外の人はレポートを読むだけにしないことです。誰かがまとめたレポートはその人の主観が入ります。レポートではなく、一緒に体験して自分なりの考えを持つことは大切ですね。

ドタキャンされた場合にも対応

カバー範囲が広い!っと感じた部分はドタキャンされた場合の対応方法も書かれている点です。

ユーザーストーリーがタスク設計に役立つ

ユーザビリティテストは、ユーザに作業課題(〇〇を予約してくださいなど)を実行してもらい、それを観察します。そして、作業課題をタスクと呼びます。「設計ガイド」では、タスクの設計方法とユーザビリティテストの始まりから終わりまでのタイムスケジュールが学べます。

本章はタスクを決める際の原則についてまとめられていて、どれも納得できる原則でした。個人的にはユーザストーリー単位でタスクを設計するのが良さそうだと思いました。

具体的な実査ガイド

「実査ガイド」は受付からエンディングまでの流れを実践さながらに書かれています。自分たちでユーザビリティテストをする前に読んでおくと準備のモレなど気づきがあると思います。

観察は事実を書く

「分析ガイド」に書かれている内容で早速役立った内容があります。「事実を書く」「ユーザ視点で書く」です。具体的な例を本書から引用します。

「戻るボタンがない」というのはユーザの視点ではありません。ユーザは戻るボタンを使いたいのではありません。単に「前の画面に戻りたい」だけです。つまり「(ユーザは) 前の画面に戻れなかった」と書くべきです。

私も開発で第三者が操作している様子を観察することがあります。そのとき、個人的に「戻るボタン」を付けた方が良いと思っていると、「戻るボタンがない」のように、自分の考えを含めたメモしたことがありました。観察はあくまで観察。意見を混ぜずに事実を書くべきだと気づきました。

まとめ

  • ユーザビリティテストするときの参考になる書籍
  • 具体的に書かれているため、実施している人は自分たちとの差を見つけやすそう
  • 観察するときは事実と意見をわける