ここまでは、アクセス解析という「定量的」な数字をベースにした内容でした。
ここからは、アクセス解析では分からないアナログな情報をベースにした内容です。
基本的にウェブ解析は「定量的なデータ」と「定性的なデータ」の二つをMixして行います。
どうしてもアクセス解析の数字という定量的なデータのみで判断しがちですが、それだけでは分からないことがたくさんあります。
例えば先ほどの話で言えば
「滞在時間が短いのは、興味が無かったからか、それとも分かりやすかったからか」
これは、アクセス解析では分かりません。
これからご紹介するユーザテストは、そこを補完してくれる物ですので、ぜひ使ってみて下さい。
ユーザテストとは?
一言でいえば「実際に使ってもらってそれを観察する」です。
やり方は様々にあり、やる内容も単純に後ろから見ているだけの物から、視線をトラッキングするメガネを付けてもらって、どこをみていたかも把握するような物もあります(アイ=トラッキング分析)。
ただ、最初から色々なことをしようとすると木を見て森を見ずになってしまいますので、まずは大ざっぱなところから始めていきましょう。
ユーザテストの流れ
ユーザテストは、一般的には以下のような流れで進めていきます。
- テスター(実際にホームページをテストする人)を探す
- テスト環境を整える
- 実際にテストを行う
- ホームページにフィードバックする
テスターを探す
まずは、テスターになってくれる人を探します。
選ぶポイントは「狙っているターゲットユーザとなるべく共通点が多いかどうか」です。
年代や性別によって、考えることや好みはがらりと変わります。特に性別はクリティカルですので、最低限性別はあわせましょう。
社内の人間でも全く問題ありませんが、商品知識がある人やサイトの構造を知り尽くしている人は不適です。
テスト環境を整える
最初は「パーティションで区切ったスペースに一般的なパソコンを置き、それを後ろから見てメモをする」で十分です。
記録しておきたかったり、あるいは後で共有したいと言うことでしたら、後ろから適当な家庭用ビデオカメラで撮影するといいです。
特に特別な設備は必要ありません。気楽にやってみて下さい。
他の部署の人を自分のデスクに呼んでやってもらうくらいでもいいと思いますよ。
実際にテストを行う
ここでのポイントは二つです。それは
- テスターに分かりやすい目標と状況設定をしてあげること
- 頭の中でつぶやいたことまで、口に出してもらうこと
です。
テスターの方にただ「とりあえず使ってみて下さい」と言うだけでは、意味のある結果は出てきません。
あくまで、ホームページにアクセスしてくる人の動向を知るためのテストなので、必ず
「○○さんは、こういう家族構成の中のこういう立場の人で、大体使えるお金はこれくらいあって、その中でこういう目的でサービスを探している。そしてその中でこのサイトにたどり着いた」
というような状況設定をします。
その方がテスターさんもやりやすいですし、意味のあるデータを得ることもできます。
もう一つは
「頭の中でつぶやいたことを、口に出してもらう」
です。なぜなら、普通パソコンでネットを見ている人は無言だからです。
放っておくと無言でマウスとキーボードだけをいじっている風景を見ることになり、本当に知りたい「アクセス者の気持ち」を知ることができません。
そこで事前のお願いとしてこう言います。
「このサイトの悪いところをあぶりだしたいので、思いついたことを文章にならなくてもいいので、全部口に出して下さい。もう、ふーん、とか、よく分からない、とかそういうものも全部です」
これによって、アクセスしたユーザの気持ちが、格段に分かるようになります。
「えーと」「なるほどなるほど」「ん?」
こういった言葉があるのとないのとでは、得られる情報が全然違いますよね。
また、悪い点を指摘することには人間ためらいがありますので、
「この場にはホームページを実際に作った人間は以内ので、ざっくばらんに」
「10個以上悪い点を見つけてくれたら、これを差し上げます」
など、罪悪感を減らしてあげるのも大事です。
改善すべき点をまとめる(フィードバックする)
このテストで得られた「改善すべき点」を箇条書きレベルでいいので、いったんまとめます。
ここではまだ、それぞれの改善策まで考えて無くて良いので「グループ分け」することを強く考えてみて下さい。
ふたを開けてみれば同じような原因から起こっている物がたくさんあります。
また、重要な物もあればそれほど重要ではない、まぁ後でいいかなというものもあります。
場当たり的に処理していくのではなく、限られた時間の中で効率よく問題点を裁いていきましょう。
なぜかというと…往々にして改善点は山のように見つかり、策を打ったものがさらなる改善点を呼ぶこともあり…優先順位を付けていかないといくら時間があっても足りないからです(笑)
ホームページはテストと変更が簡単なため、やることは本当にきりがありません。
そこが醍醐味でもありますが、その醍醐味にうずもれると大変です。
必要なのは「プライオリティ付け」と「トリアージ」。
この二つの視点を忘れると、あなたとあなたのチームが一種のデスマーチ状態になるかもしれません。
それによって正常な判断力を失ったチャンネルに成功はまずありません。
判断できるサンプル数が集まる前に結果を判断してしまい、後から見てみれば「行って来い」な動きをして、いたずらに疲弊してしまうことも少なくありません。
「井の中の蛙」的な調査に終わらせないことが大事
また、もう一つ大事なのが、調査をする時に自社サイトだけで行ってはいけないということです。結論から言えば「競合サイト」も対象に加えて、合わせてテストすることをおすすめします。
これはどういうことかというと、自社サイトだけでチェックをすると、それは「自社サイトの中での最適化」になってしまうからです。
自社サイトだけ見て出てきた改善点は、所詮自社サイトの中での話です。競合サイトなどと比較しなければ、それが「マーケット全体」として改善すべきレベルなのかそうではないのか判断ができません。
もしかしたら、あなたのサイトはすでにとても良いサイトかもしれません。その場合は出てきた改善点は「90点を95点にする」くらいの意味しかないかもしれません。
しかし逆に、あなたのサイトはとても悪いサイトかもしれません。その場合は「大した改善点が出なかった」と思っても、その改善点は「10点を50点にする」ような大きな改善かもしれません。
競合と比較することで、自社サイトを正しく評価できるようになります。テストの際は、自サイトを含めた複数のサイトでテストを依頼することをオススメします。
コンテンツナビゲーション
コンテンツ一覧・目次
- 第1章:はじめに
- 第2章:読み始める為に必要なスキル
- 第3章:解析の第一歩 – 現状把握
- 第4章:歴史を調べる – 現状把握
- 第5章:指標を確認・決定する – 現状把握
- 第6章:現状の確認 – 問題点の発見
- 第7章:アクセス解析で洗い出し – 問題点の発見
- 第8章:具体的なステップ1 – 問題点の発見
- 第9章:具体的なステップ2 – 問題点の発見
- 第10章:その後 – 問題点の発見
- 第11章:ユーザーテスト
- 第12回:改善案の発案のコツ – 改善案の発案と実行
- 第13回:気をつけたいこと – 改善案の発案と実行
- 第14回:施策の実行 – 改善案の発案と実行
- 第15回:結果はすぐには分からない – 結果の確認と次策
- 第16回:待つしか無いのか?- 結果の確認と次策
- 第17回:他の要因 – 結果の確認と次策
- 第18回:新たな施策を打つ – 結果の確認と次策
- 第19回:情報収集は欠かさずに – 結果の確認と次策
- 第20回:終わりに