ユーザビリティテスト
概要
ニーズ
- 現状サイトの課題について組織内で共有したい企業様。利用者が実際にサイトを使ってとまどっている様子を可視化することでインパクトのある課題共有が可能です。
- Webサイトのリニューアル方針策定前にユーザ視点での具体的な課題を洗い出したい企業様
詳細
ユーザビリティの重要性
インターネットやスマートフォンの普及とともに、Webサイトの競争要因は機能やコンテンツだけでは差別化しにくくなってきています。また企業サイトの多くで、サイトが使いにくい、分かりにくいといった理由から発生しているユーザの離反行動 や機会損失が発生しており、ユーザビリティへの取り組みによって大きく改善する余地が存在しています。
WEBサイトの問題抽出手法
ユーザビリティテストとは、あらかじめ想定したタスクを被験者に実行させ、その過 程を「思考発話法」によって観察・検証することにより、サイト利用者にとっての 「使いにくさ」「分かりにくさ」などのユーザビリティ視点に基づき、ユーザの離 脱行動や機会損失の原因となっている問題点を抽出し、効果的かつ具体的な解決策 を導くための手法です。
投資対効果(ROI)向上
これらの対策を実行することにより、訪問者の購買率、コンバージョン率、顧客満足 度などを改善し、最終的にWEBサイトの投資対効果(ROI)を高めます。
テストによる課題点をふまえた最適なユーザ導線の改善設 計をご提示します。
ユーザビリティテストによる改善課題抽出
D4DRのユーザビリティテストにおいては、現状のサイトの問題点の指摘 に留まらず、具体的にサイトをどのように改善すればよいのか、その対策 を含めてレポートとして作成いたします。
インフォメーション・アーキテクチャとユーザ導線の最適化
個々の改善ポイントをふまえて、サイトリニューアルに向けた全体構成や ページレイアウト、最適なユーザ導線など、より使いやすくユーザのメン タルモデルに沿ったインフォメーション・アーキテクチャ(情報構造)の設計 をいたします。
サイトリニューアルに向けたRFPの策定
D4DRでは、上記の改善レポートやインフォメーション・アーキテク チャの成果物を、サイトのリニューアル要件としてRFP(提案依頼書)のかたちでとりまとめ、制作会社へのコンペ実施などをご支援することが可能です。
Webの構築・運用において必 要不可欠なユーザビリティの仮説検証
サイトリニューアル
サイトリニューアル時におけるユーザビリティテストの実施は、改善前の現状問題点を抽出する段階で実施するとともに、ウェブサイトを公開する前の段階で、実際に制作さ
れたプロトタイプ段階のサイトをターゲットユーザを使用して評価するユーザビリティテストが有効です。
サービス公開前に、実際にターゲットユーザにウェブサイト使用してもらうことにより、思わぬ使い勝手の悪さや、デザイン上、構造上の問題点を発見でき、これらの問題点の事前の修正が可能となります。その結果、公開後に発生する売上の機会損失や、サイトのロイヤリティの低下を最小限に食い止めることが可能となります。
仮説検証
WEBサイトが公開直後で「完全」な状態であるということはまずありえません。顧客と のコミュニケーションに活用する重要なチャネルとして、継続的な改善が必要なことは 言うまでもありません。
ユーザビリティテストを継続的に実施することにより、問題仮説抽出、目標設定をもと に実際に短期改善を実行し、その結果を確認していく「仮説検証プロセス」を導入する とともに、検証するユーザシナリオの対象となるターゲットセグメントの範囲を広げる ことで、より多くのユーザ層や利用シーンに対応していく「WEBサイトの成長シナリオ」を描くことができます。
なぜユーザビリティテストによって重大な問題抽出が可能なのか?
被験者の選定
被験者の選定にあたっては、WEBサイトを利用する顧客層のなかから主要セグメントに絞って被験者を選定するとともに、当該セグメントのユーザ属性、利用目的、利 用シーン、行動特性、リテラシーなどをもとに検証するユーザシナリオを定義します。
被験者の有効母数
被験者の人数は、5名で全体の85%の問題を発見可能と考えられています。(ヤコブ・ニールセン)。
思考発話法による観察記録
募集した被験者(ユーザ)に、いくつかの定められたタスクを実行するよう依頼し ます。被験者(ユーザ)はタスクを実行しながら、認知過程を発話します。インタ ビュアーは、被験者(ユーザ)の行動と発話を観察・記録し、その結果を分析します。
反証主義による問題抽出
あらゆる使用場面(シナリオ)をテストすることは、事実上不可能ですので、 まず前提として現在のインターフェイスは“Usable”であると仮定(ゼロ仮説)します。そして、重要なシナリオについてユーザテストを実施し、徹底的に問題点(反証)を探します。問題点が見つかれば積極的に修正し、問題点が見つからなければ仮説は成立するのでインターフェイスは“usable”であると結論付けます。