はじめに
あなたの作っている製品やサービスは、本当にユーザーにとって使いやすいものになっているでしょうか。ユーザーにとってよいものだと信じて作っているものでも、それは開発者やデザイナー（あなた）の思い込みかもしれません。ユーザーが実際に使っている様子を観察することでその思い込みを解消したり、ユーザーが行う操作の意外性やパターンを知ったりすることで、その後の開発の糧とすることができます。
ユーザビリティーテストというと、前述した「マジックミラー付きの実験室でユーザーが操作している様子を観察する」というイメージを持たれがちです。また、ユーザビリティーテストを実施するまでの過程もあまり明らかになってないのではないのでしょうか。実験室がないと実施ができないものではなく、オフィスのなかの会議室を1つ使って、そこにパソコンを1つ持ち込めばそこが立派な実験室になります。テストのための準備も、ちょっとした知識と手順がわかればそんなに手間がかからないはずです。
本連載でお話ししていくのは、大掛かりなテストではなく、できるだけ小さな規模に落とし込んだテストです。大掛かりなテストを1回やるのではなく、小さなテストを数多く行った方が、製品やサービスの開発をスピードアップしていくことができます。また、開発サイクルに組み込みやすいというメリットもあります。小さなテストを何回も回して、製品やサービスをより使いやすく魅力的なものにしていきましょう。
対象読者
ITによるシステムやサービスを作っているすべての人。
「誰にとっても使いやすい」サービスは存在しない
そもそも「ユーザビリティー」とはどういう概念でしょうか。日本語では「使いやすさ」と訳されることが多いのですが、人が対象となるものを使うことができるか、その際の使い勝手のことを指します。ユーザビリティーは「特定のユーザー」が「特定の利用状況」において、目的を達成するまでの、有効さ、効率、満足度という3つの軸で測られるものです。
特定のユーザー、特定の利用状況とはどういった意味でしょうか。この言葉を詳しく知るために、「老若男女が簡単に満足に使うことができるデジタルカメラ」というものを考えてみましょう。一見するとユーザビリティーが高い製品ができそうに見えますが、具体的に考えていくとその印象は一変します。
- 漢字が読めない子供のために、文字は全てひらがなにしよう。
- 老眼の人のために液晶ディスプレイは大きくしよう。
- 女子高生が持ち歩きたくなるカメラにするためにカラーリングはパステルカラーにしよう。
- カメラ上級者も満足できるようにデジタル一眼をベースに作ろう。
一体、どういった製品になるでしょう。「老若男女が簡単に満足に使うことのできる」デジタルカメラにはなったでしょうか。
一方で「小学校低学年の子供が日常生活の中で単に使うことができるデジタルカメラ」ではどうでしょう。簡単な言葉やアイコンで機能を表そう。子供の日常生活では公園の砂場で遊ぶこともあるだろうから、多少乱暴に扱っても大丈夫な設計にしよう。子供の手のひらに収まるようなサイズにしよう。「小学校低学年の子供」、「日常生活」というようにユーザーと利用状況を特定することで、そのユーザーと利用状況において満足させられそうなデジタルカメラを考えることができそうです。
ITやWebの世界でも同じことが言えます。「音楽を簡単に購入することができるサービス」よりも「高校生がカラオケにいったときに、その場で音楽を簡単に購入することができるサービス」と考えた方が、ユーザビリティーの高いサービスを作ることができます。これは「特定のユーザー」「特定の利用状況」を考慮しているからです。
誰にとってもどんな状況においてもユーザビリティーの高い製品というものは、実際には存在しません。
ユーザビリティーテストは設計が7割
ユーザビリティーテストは、製品やサービスをユーザーに実際に使ってもらうことによって、問題発見や検証を行う手法です。表面的なUI（ユーザーインターフェース）についての問題だけでなく、製品を通した全体のUX（ユーザーエクスペリエンス）や、実装上の問題点も発見することができます。
ユーザビリティーテストには、設計と実施の2つのステップがあります。設計のステップでは、現状の問題点の洗い出しや分析を行い、それを踏まえた上で、テスト実施の際に被験者（ユーザー）に実施してもらうタスクの作成、テストを実施する際の観察ポイントの作成を行います。実施のステップでは、1被験者あたり1時間程度の時間で、設計のステップで作成したタスクの実施や、被験者へのインタビューを行います。
設計
- 現状の問題点の洗い出しや分析
- 被験者に実施してもらタスクの作成
- 観察ポイントの作成
実施
- タスクの実施
- 被験者へのインタビュー
ただ被験者に「操作してみてください」と渡すだけがユーザビリティーテストではないのです。作ったものに対して、身近にいる人を呼んできて「使ってみて」と渡してみると、いくつもの意見や問題点を発見することができるでしょう。しかし「ユーザビリティー」を評価するためには、「特定のユーザー」「特定の利用状況」を加味しなければいけません。
システム管理者が利用ユーザーを追加する機能に対して、「特定のユーザー」を考慮せずにシステム管理を行ったことのない人を呼んできてしまうと、「CSV読み込み」というボタンの意味を理解できずに、観察を途中で中止せざるを得なくなってしまうかもしれません。電車内で今日の天気を簡単に確認できるアプリに対して、「特定の利用状況」を考慮せずに会議室で腰を据えて見てもらい、「もっと細かい時間別の天気が知りたい」という意見をもらってしまうかもしれません。
ユーザビリティーテストでは実施のステップがクローズアップされることが多いですが、実は設計が7割を占めています。設計を疎かにすると、実施でたくさんの問題点が発見できたとしても、それらはピントがずれていたり、本当にその時に知りたかった問題点を逃したりしてしまいます。
