ユーザビリティの原則と現場で使えるユーザビリティテストの方法
2011年06月03日 公開
今回は、Web制作の現場でも使えるようなユーザビリティテストの方法をご紹介します。
アクセス解析を使ったものではなく、あくまでもサイトの構造の問題点を洗い出す方法です。
そのため、それにいたる細かい基本部分についてもかなり大胆に触れてます。
試験をする前に、どのような観点からサイトを見て行く必要があるのかと言うユーザビリティの原則から、試験方法、試験の結果からの問題解決にむけて、私がこれまで行ってきている仕事の一部をご紹介します。
Webユーザビリティについて：目次
書き出したらとまらなくなりましたが、これでも結構情報削りすぎたかなぁというのはあります。
- 私の仕事について
- 方法を学べばユーザビリティテストは出来る
- 最大の原則はユーザーに考えさせない事
- たった一人でも試験をするほうが100倍ましになる
- ユーザーの視点を理解する箇所
- 法則1「長いテキストを最初からよし見ようとは思わない」
- 法則2「長たらしい説明よりもまずキーワードをクリックする」
- 法則3「一度うまくいったらそれ以外の方法を模索しない」
- 法則4「ユーザーは現在地とそのサイトのボリュームを知らない」
- 法則5「最初に何の情報があるのかと気になっているのがユーザーである」
- ユーザーの視点を持つと言う事はクリエイティブを忘れる事
- 実際の試験方法
- 結果から問題点を割り出す方法
- ショートテストは回数が多ければ多いほどいい
- お仕事もお受けしてます
私の仕事について
私が一体何をして生きてるのとたまに聞かれるのだけど、私はそんな大それた仕事は特にしていない。
これまで培ってきた10年と言うWebユーザー暦を生かして、Webサイトの問題点を見つけ、その改善案を作成している。
今回はそんなWebサイトの問題点を見つけて、そしてどのように改善する事でよりよいサイトになって行くかと言う部分をご紹介するわけですが、おそらくユーザビリティに携わる人の多くは、そんな自分の飯の種を明かす事が愚かであると思われる人も少なくない。実際に私が行っている仕事とは以下のようなものだ。
- Web屋さんや、中小企業のWebサイトのオーナーから、新規で立ち上げる前のサイトや、既に運用中のWebサイトのURLが送られてくる
- 送られてきたWebサイトが、使いやすいかどうか、問題点があるかを試験する
- 問題点を見つけてその解決策を書いたレポートの作成する
- 費用にもよりますが専門的なサイトだと専門的なユーザーに実際にWebサイトを使ってもらい、その利用履歴から問題点と解決策を作成する
- お金を頂く。お寿司を食べる。
目次にもどる
方法を学べば低価格でユーザビリティテストはできる
2001年より個人的に行っているユーザビリティテストレポートは、口コミの広がりもあり、おかげさまでコンスタントに依頼が増えて行きました。世の中の多くの人が試験に数十万から数百万かけてやってるところも有りますが、私はわずか1万～3万でやってたのもあります。
もちろん個人なので大企業様の試験は忘れもしない2008年に一件だけでしたがその後何度かリピートしていただけて、さらに紹介にもあずかり、とても感謝しています。
なんせサラリーマンだったので、大々的に宣伝もできませんでしたが、もう一人になってしまったため、隠してもしょうがないかなと言うものひとつの公開理由です。
わずかな価格で試験ができると言うのは売りでしたが、実は多くの企業やWeb屋も、試験してくれるユーザーさえ見つかれば、謝礼に通常5000円～15000円くらい支払う事で試験はある程度できます。
これによって、そのWebサイトの対象者となりそうなユーザーを何十人と集め、そして試験をする従来の方法とは全く異なり、小数人数でも、従来よりはるかに効果的な試験結果を得る事が可能になりました。
試験自体はとても簡単です。
一番の問題は試験の結果から、どのような問題があるのかと言う関連付けですが、このあたりはある程度の修行が必要かもしれません。
で、実際のところ趣味の領域で始めた事が、とりあえず目に見える範囲のお客様と、口コミによってある程度お仕事をもらえるという点において考えると、私がこのブログでその方法を書いたごときで、私の仕事が激減するかどうかを考えた場合、そうはならないかなと言うのが一番大きな部分です。
目次にもどる
最大の原則はユーザーに考えさせない事
私がユーザビリティの話をするときは３つの基本的なチェック項目があります。
- ユーザーの視点を理解しているか
- 道しるべと現在地について適切か
- ユーザーを惑わすテキストが無いか
これは既に1998年代からほぼ変わる事がない普遍的なものであり、おそらくこれからもしばらく変わる事はないと考えています。
では、その３つの項目は、どこから生まれたのでしょうか。
Appleなどを手がける、ユーザビリティコンサルタント。スティーブ・クルーグ氏がユーザビリティについて話すときに、第一原則として紹介する1文があります。
それこそが「ユーザーに考えさせない事」です。
私がペーペーだった10年前に、ひとつの原則が学べた事が幸運だったと思います。
とにかく、Webサイトにアクセスした時に、そのサイトが一体何なのかと言うのが考えずにわかるのかどうか。それがリンクなのかわかるのか。ユーザーが求める情報に、ユーザーは深く考える事無くたどり着けるのかどうか。
「考えさせない」というのは、それら全てに共通する事です。
目次にもどる
たった一人でも試験をするほうが100倍ましになる
実際に私は自分で言うのもなんですが、優れたWebデザイナーではありません。
長年やっているテストから、自分がクライアントのサイトを作るとき、人より多くの試験結果を知っているというのが、単に私の強みであるという点を除いては、優れたWeb屋でもないと思っています。
ユーザーが使いやすいかどうかと言うのは非常に重要で、ちょっとした変更ひとつでお問い合わせも増えますし、滞在時間を延ばす事も可能になり、さらには注文を増やす事もできます。
試験を難しく考える必要はありません。膨大な費用がかけられないケースのほうが多いでしょう。
しかし、たった一人でもいいから試験してもらうほうが、試験して無い状態よりも、はるかに良いものが出来るのは事実です。それがあなたの友人、近所の人、配偶者、誰でもかまわないのです。
どんなテストユーザーであっても、やらないよりやったほうがはるかにましなのです。
目次にもどる
ユーザーの視点を理解しているか
仮に一般ユーザーを公募する場合は特に気にする事は無いのですが、私たちのようなWeb屋が試験をする場合、最も重要なのが「ユーザー」の視点になれるのかどうかです。
制作者側が考える視点を以下の例で試すとどうなるでしょうか。
制作者が寄せる期待
ここはこうして読んでくれるだろう。
こうして書いておけばこれが何なのかわかるだろう。
実際の動き
それは稲妻のように読まれます。
多くの場合、自分に興味が無い、テキストが集合しすぎている場合、そこに情報が「まるで最初からなかった」かのごとくモザイクがかけられ、視界から消え去ります。
目次にもどる
法則1「長いテキストを最初からよし見ようとは思わない」
これはWebサイトのみならず、ブログもそうです。
この記事も、興味のない人からしてみると、長いと読みません。もしかしたらこの上にある画像に目を留めて、始めて「見てみようかな」と考える人もいるでしょう。
また、「大きなテキストだけ」をざっと見て、あとから見ようかどうかを判断する人もいます。
しかしたいていの場合、皆さんは「Webサイトの半分以上のテキストは別に読まなくても何とかなる」という真理を知っています。
- 朝新聞を読む人は大きな見出しの記事を先に読む。時間が無い場合見出しのみ流し読みする
- RSS購読する人は記事の内容よりもまずタイトルだけを流し読みする
- Webサイトでは説明よりも興味のあるテキストが使われたリンクを先に見つける
不要なテキストは、ユーザーの目的や、サービスを利用する意欲、購入する意欲などを剥ぎ取るノイズとなります。完成されたWebサイトは「どのようにして不要な情報を削除するか」という点にかかっています。
これまでの経験上、最初に制作されたテキストを半分にしても、さほどユーザーにとって影響する事はあまりないのです。
目次にもどる
法則2「長たらしい説明よりもまずキーワードをクリックする」
特にWebユーザーが何か情報を探すときは、細かい説明文を読むよりもはるかに早いスピードでその情報にたどり着ける方法を知っています。
それが「とりあえずクリックしてみる事」です。
クリックする事のストレスはまた別の話になります。ふだんから良く利用する機能が、毎度毎度そのクリックをしないと見れない機能とかは単なる問題点であり、ユーザーの事を全く考えてないと言う事になります。今で言うとはてなブックマークのコメントを見るために1クリック増えたという改悪がそれにあたるかもしれません。
そうではなく、まだなにもわからない状態のWebサイトを利用する場合です。
そのリンク先がなんであれ、周りにそれに対する説明が書いてあるにもかかわらず、さらにもっと素敵なショートカットリンクがあるにもかかわらず、そんなものはおいといて「とりあえずクリック」するのです。
そして自分が探していた情報ではないものにぶち当たったなら、わずか数秒で戻るボタンを活用するのです。
サイトに適した言葉をつかったリンクを作成しましょう。
目次にもどる
法則3「一度うまくいったらそれ以外の方法を模索しない」
iPhoneのホーム画面で、右のページに移動するためにはタッチパネルの右から左へスワイプすると言う事を多くの利用者は知っています。
例えば以下のような場所をタッチしても同じ効果が得られますが、実際にスワイプを知っている人にとって、それ以外の方法を調べる必要も無いのです。
あるWebサイトの製品のドライバを探しているユーザー試験をした場合の事です。
Webサイトのヘッダーには大きく「ダウンロード」というリンクがあります。
しかし、そのユーザーはまず、製品を探しました。
「えっと、自分の製品は○○だからまず、○○をクリック・・・うわいっぱいあるなぁ・・・めんどくさいですね少し・・・」
「製品カテゴリ：○○」→「製品名」→「製品が見つかった」
「あれ、でもドライバが無いですね・・・どうしよう。あ、ダウンロードというリンクがありますね」
「ダウンロード」→「製品IDを探す」→「ダウンロードページにたどり着く」
試験の結果「製品ページにはドライバのダウンロードページへのリンクは必須」と言う事が発覚します。
以降、彼は、ドライバをダウンロードするときには、必ずこの方法にのっとって探します。
検索窓に製品IDを入れて検索するだけで1クリックでダウンロードページにたどり着いたとしても、自分が一度うまくいった方法で満足するのがユーザーの心理と言うものなのです。
目次にもどる
法則4「ユーザーは現在地とそのサイトのボリュームを知らない」
ユーザーにとって、現在地を知るすべが一つあるとすれば、それはパンくずリストだと勘違いされる事が多いですが、それは違います。パンくずリストは現在地を知るものではなく、ボリュームを知る事が出来るただの部品です。
こんなやつ
これは昔から浸透してた「お約束」のひとつで、多くのユーザーは、コレが今いる現在地を知るすべだと言う事を知っています。しかし、パンくずリストの本来の意味はただの「部品」であると言う事が重要であり、現在地は別の大きなテキストが標識となります。ホーム > ほっとパンツ > ジーンズ生地 > 2011年モデル
例に出して見ましょう。
これはパンくずリストに頼りきりのページです。
以下のように直すだけでユーザーに考えさせるステップをひとつ取り払う事が出来ます。
大きなテキストが現在地をあらわす事で、そのページの現在地を確認できます。
このテキストがある事で始めてパンくずリストが生かされるのです。
これらが必要な意味は、ユーザーに大して、適度に「戻る道」を教えていると言う事です。
カテゴリーごとに、他にも商品があるのかなという想像力を働かせる事によって、そのWebサイトのボリュームを知ってもらう事が出来るのです。
あなたはコンビニに行った時、コンビニの大きさから、その中の商品の量を無意識に把握する事が出来ます。
デパートならデパートのサイズを見れば、それなりにどれくらいの商品を扱っているのかを想像できるのです。
しかし、Web上のショッピングサイトには、それを想像してもらう要素を「作らない限りわからない」という事実があります。
また、コンビニの入り口は一つですが、Webサイトの入り口は無限です。
もしかすると、Googeから、急にお酒コーナーに案内される事だって有ります。
そのお酒コーナーから、以下に簡単に、あまり考える事無くそのサイトのボリュームや現在地を伝える事が出来るのかを考える必要があるのです。
目次にもどる
法則5「最初に何の情報があるのかと気になっているのがユーザーである」
どのページ（深層にあるような末端ページも含めて）を作るるにしても、必ず最後に確認しておかなければならない事があります。
それは、ユーザーが一番初めにそのページに訪れた時に、どんな場合でも「そこにはどんな情報があるのか」という意欲を持っているという事実です。
Webサイトとは、最初に持っている「どんな情報があるのか」から解決していくのが絶対的なルールです。
- 商品を売りたい
- サービスを使ってほしい
- 広告を踏んでほしい
- 我社を知ってほしい
- パンフレットを請求してほしい
- 私を知ってほしい
これはいわゆる制作者や、発注元が抱える「Webサイトを作る目的」に他なりません。
ユーザーとの最初のズレの多くは、最初のユーザーの不満に答える事が出来ないケースです。
Webサイトはどんな情報があるのかという「欲求」を最初に満たす必要があります。
Google検索を利用している人はYahooを利用している人に比べて買い物をするユーザーが少ないと言われていますが、情報を探す人の多くがGoogleを利用している人が多いというだけで、別にそんな事を気にして設計する必要はありません。
必要なのは探しに来たユーザーに対して、適切にその情報を提供できているのかと言う事です。それが満たされる事が無い場合、「なんかよくわからないから」という理由で数秒で戻るボタンでユーザーはいなくなります。
どのページにもそのサイトがなんのサイトなのかがわかれば、他のページへ案内する事が可能です。特定のルートで案内されたページの場合特に気をつけてほしいのはそこです。
トップページから
『PC周辺機器』→『プリンタ』→『カラープリンタ』
というリンクを経由してたどり着いたユーザーであれば、そのページが、なんのサイトで、なんのページなのかを理解しています。
しかし、検索経由でたどり着いたユーザーの視点を考る事を忘れてしまうと、そこに「どんな情報のサイトなのか」というユーザーの最初の欲求を満たす事が出来ないケースが、非常に多いのです。
これも必ずチェックするべき項目となります。
目次にもどる
ユーザーの視点を持つと言う事はクリエイティブを忘れる事
こうした法則は、どのWebユーザビリティの教科書にも書いてある事です。Webサイトのテストを行うときは、これを再度、何度でも思い出してから実行しなければなりません。
これは、制作側になると、かならず忘れる事だからです。
また、デザイナーさんはなるべく試験に参加しないほうがいいです。
なぜなら新しいUIや、特にデザインによって滞在時間を延ばしたりというクリエイティブな事をしている人たちは、クリエイティブがゆえにデザイナーになれたのです。
つまり独創的な価値観や視点を持っているからこそすばらしいのです。
今までの経過から、こうしたクリエイティブ性の高い人のほとんどが、その人がこれまで培ってきた経験と、好き嫌いによってあらゆる判断が下されるため、「flashの時点でダメ」や「プルダウンメニューの時点でダメ」といった意見が多数出ます。
残念ながらユーザビリティの試験を行う際は、「好き嫌い」はどうでも良く、「多くのユーザーがそうだから」という概念もどうでもよくて、「試験した結果こうなった」という事実だけが大事なのです。
目次にもどる
実際の試験方法
これはヤコブ・ニールセン、スティーブ・クルーグ氏などの方法をさらに軽量化してます。彼らはビデオによる撮影があります。
現在はビデオ録画よりもデスクトップ自体の撮影が可能になっているため、キャプチャーソフトを利用する事もあります。
特にCamStudioは、音声記録も出来るので一般ユーザーを公募した時に重宝します。
画面動画キャプチャーソフト CamStudio 日本語版 | twk @ ふらっと
Vector：劇場版 ディスプレイキャプチャー あれ - お勧めソフトPickUP
ウィンドウを動画キャプチャーしてチュートリアル用のFlashを作成「Wink」
ここで以下の事を実際にWebサイトを利用してもらい質問していきます。
- ぱっと見てどんな印象だったか
- このサイトはどんなサイトだと思いますか（回答にいたる時間もメモる）
- 最初にどこに興味をもったか
- 最初になにをクリックしようと考えたか
- 制作側が用意した目玉コンテンツへのアクセスをする気があるか（たいていの場合、スルーされる事が多い）
- これらを、単一のページでも試験して行く
次に制作側がしてほしいアクションを出来るかどうかを試してもらう。
例えば資料請求であったり、自分のプロフィールや、ポートフォリオとしての作品を見てもらったり、実際に購入してもらったりと行った事です。
- それをする為に行った全てのクリックに対して理由をもらう
- 悩むテキストがあったかどうかをたずねる
- 全く見なかったテキストがあったかをたずねる
- なにか不快に感じた事があるかをたずねる
- 総合的に評価してもらう
目次にもどる
結果から問題点を割り出す方法
問題の割り出しにはいくつかの考え方がありますが、私なりの方法を紹介します。
その前に、あまり参考にするべきではない点が二つ。
- 特に気をつけてほしい点は「ユーザーの好き嫌い」
なぜなら人それぞれ好き嫌いがあるからです。
好き嫌いが一番現れるのが「機能性」です。
例えば「flashを使ってメニューを作ったほうがもっと良くなります」「ショートカットメニューは左に統一したほうが使いやすいと思います」といった事です。
これらはそれぞれのユーザーによって別の回答がある事がほとんどであまり問題点として鵜呑みしないほうが良いです。
- 多少悩んだけど解決できた場合
他のサイトとカテゴリ名が少し違うだけでユーザーは間違う事が多いですが、ある程度考えてそれを解決できたようであれば、そこまで深い問題ではないと言う事です。
これらを踏まえた上で修正すべき点を上げると次のような場合です。
- サイトが何なのかわからない
- してほしい事をしてもらえない
- 使用している言葉に疑問を持たれた
- 最終的にサイトマップまで見にいった
問題とはそのWebサイトにとってまるで隠し金山のような存在であり、発見出来た問題を、どのように解決していくかを再度考え直す事が出来るのです。
サイトが何なのかわからない
そもそもWebサイトの存在意義を問われます。
この問題に直面した場合は、今より必ずよくなりますのですぐに取り掛かりましょう。
わかりにくい、説明が多すぎる、説明が極端に少ない、使っているキーワードからそのサイトのイメージを連想できないケースが多いです。
専門用語が多すぎる場合にもこのような事が起こります。
初心者にわかる言葉を利用しましょう。エキスパートでも初心者にわかる言葉をみて不快に思う人はいないものです。
してほしい事をしてもらえない
資料を請求するための方法が複雑すぎる。入力してもらう項目が多すぎる。そこにたどり着くための道が複雑すぎる。こうしたケースの場合にも緊急オペが必要です。
多くのWebサイトはそのページにたどり着くまでに1クリックで行けるようになっています。
そもそも何をしてほしいか理解されなかった場合も、何らかの改善が求められます。
使用している言葉に疑問をもたれた
例えば制作側にはわかるけど、ユーザーが考えなければならない言葉があります。
こういうケースの場合は、極力簡単なほうを選ぶように吟味しましょう。
サイトマップまで見に行った
サイトにとって、サイトマップはとても重要な役割を果たします。しかし、サイトマップを利用するユーザーのほとんどが、そのサイトの構造が複雑すぎて、トップページから自分が目的としているページへ行く方法がわからない人がほとんどです。
例えば大きなお店にいって、急いでいるときは、総合案内へ一直線へ向かいます。
Webサイトでいう総合案内は、「検索窓」であり「サイトマップ」ではありません。
つまり、サイトマップのアクセスログが多い時点で、ページ内で案内しているリンク達は、仕事をまったくしていないという事になります。
もしもサイトマップまで利用させてしまった場合は、トップページの構造から見直しましょう。
私のこれまでの経験から言わせてもらうと、トップページの半分にflashによるどうでもいい宣伝ムービーがあり、そのためにトップページのコンテンツが減少させられていたり、トップページにあまりにも情報量が多すぎて、目的の物が探しにくくなっているという両極端なケースが多いです。
今一度確認しましょう。
目次にもどる
ショートテストは回数が多ければ多いほどいい
こうしたショートテストのすばらしいところはコストが余りかからないという点に有ります。
50人で最後の最後に一回だけ試験するよりも、3人で何回かテストを行ったほうが、問題点が見つかります。
と言うのも、問題点を一度修正して、初めて次のステップへ行けるユーザーが増えるため、そこまで行く事でようやく気付く問題点と言うものが眠っているからです。
もしもまだ一度もそんなテストを行っていないと言う事であれば、ためしに少しWebをかじった事のあるユーザーにお願いして見るといいでしょう。
自分たちが考えている以上に、Webサイトには気付かない問題が眠っているものです。
ただし。
ここに書いたものはあくまで一部です。
これは当然の事ですが、「やりたくなくてもやらざるを得ない場合」も多々有ります。
Web屋をやってればそんな事は100も承知だという事でも、上が決めた事はやらなければならないという問題が、大きな問題です。
そういうときに反論する事は出来ないでしょう。
ユーザビリティテストとは、そのためのテストでもあります。テストの結果は真実です。
結果さえあれば、経営者も理解してくれる事が多いのです。おためしあれ。
それでは、また。
追伸
※現在こちらは締め切っています。別途ご相談があればお見積りいたします。
※ウェブアプリは専門外です。あらかじめご了承願います。