今回から何回かに分けて、ユーザビリティ検証で気を付けたいこと、やってはいけないことについて書いていきたいと思います。
Webサイトのユーザビリティを検証するというのは、UXデザイナーやマーケティング担当者にとってなかなか頭の痛い問題です。
そもそもユーザビリティに関しては、社内で共通の認識を持つことすら難しいかもしれません。しかしながら、製品利用者にどのように製品を使っているのかを聞き、それに基づいて製品のデザインや機能を改善する。これでは、単にたくさんのやりたくないことを増やすだけです。
UXのテストに対して、担当者は以下のような消極的な発言をするかもしれません。
- ユーザが何を望んでいるか分かっている
- サイトのデザインや開発に多額の投資をしてるのだから必要ない
- 社内のみんなは気に入っている
- ユーザを混乱させたくない
- スティーブ・ジョブズはユーザがどう思うかなんて考えていなかった
- お金と時間がかかりすぎる
弊社では、デザインのあらゆるプロセスにおいてユーザビリティの検証は間違いなく意味のあることと考えており、上記のような意見が正しいとは考えていません。しかも、ユーザビリティの検証は一度実施すれば終わりというものではなく、Webサイトが日々変化/進化していくのと併せて繰り返し実施することが重要です。
ユーザビリティの検証が劇的なデザインの改善をもたらし、収益に直接影響を与えた事例は数多くあります。
ここでは、それらの事例から得られたユーザビリティ検証における注意点と禁止事項についてご紹介します。
１．実際のサイト訪問者を見る
当たり前のことと思われるかもしれませんが、サイト訪問者からのフィードバックは無視されることがあります。 特にそのデータが分析する側の先入観や過去の結果と異なる場合には。主観的な意見や実証的なデータを扱っているかどうかにかかわらず、あなたが求める答えがすぐに得られるとは限りません。むしろ、以前の結果とは矛盾する結果が出てくる可能性もあります。しかし、それらの結果が現時点では正しいものであり、場合によっては以前のデータの粗さやずれを明らかにしてくれるかもしれません。
実際にユーザから得られたデータは、そのデータを基に何かを変える前に分析・調査し、そして考察するものです。
ユーザビリティの検証から得た結果だけを見て、思い込みでデザインを変更すると後々痛い目にあうでしょう。
では、どのようにすれば誤った結論にたどり着かずに済むでしょうか？
まずは先入観をなくし、まっさらな気持ちでデータを見てみましょう。デザインの設計プロセスにおける最初のステップは、あなた自身がかけているバイアスや仮定について認識することです…それらには欠陥があるかもしれません。まずはそうした先入観や仮定をはっきりさせ、それらを検証すべき仮説として組み立てることが我々は有用と考えています。ページデザインの設計プロセス全体を通して、先入観や偏見について継続的に検証していくことは、新しい発見や学びを得られるチャンスとなるでしょう。
こうした検証の一例としては、ユーザとしてウェブサイトを利用しているとき、クリックできる場所だと思ったらクリックできなかった…という体験はありませんか？
デザインを設計した側からすれば思いもよらない場所がクリックされている、ということは多々あります。
日々のアクセス数やコンバージョン率を追っているだけでは気づけないこのような問題も、Mouseflowのヒートマップ機能やセッションリプレイ機能を使うことで簡単に発見することができます。
次回は、
２．すべての訪問者が同じように行動するわけではない
３．デフォルトの小さい（または大きい）サンプルサイズが適切とは限らない
こちらの2つの注意点についてご紹介します。
この記事は、Mouseflow公式サイトの以下の記事を翻訳、加筆修正したものです。
The 7 Dos and Don’ts of Usability Testing
この記事へのコメントはありません。