|
|---|
マウスカーソルを重ねると下層の項目が開く階層型のメニュー（ドロップダウン）では、カーソルを注意深く移動しないとメニューが閉じたり、隣のメニューが開いたりしてしまうことがあります。
Amazonでは、このような誤動作を防ぐために、カーソルが下層のメニューに向かって移動している間はメニューが少し長めに開き続けるようになっていることが最近、ブログで紹介され、話題になりました（英語のオリジナル記事／日本語の紹介記事）。
Amazonのメニュー表示
操作してみると確かに快適ですが、説明されなければ気がつかない地味な工夫です。
ユーザーの利便性を高めるために地道に改善を積み重ねるのも大事ですが、誰にも気がつかれないのはもったいない話です。効果を定量的に検証できるようにすれば、制作スタッフの貢献度が社内で認知されるようになり、いろいろな提案が通りやすくなるでしょう。
また、改善のつもりが実は効果が薄く、作り手の自己満足で終わることもありますし、そもそも効果が出ていないことに気付かないことすらあります。Web解析で定期的にモニタリングすれば、継続的で確実な改善が可能になります。
そこで今回は、「Amazonのメニューで採用されている工夫を自社サイトに適用するとユーザビリティは改善されるのか？」をWeb解析で検証する方法について考えてみます。
「マウスのズレ」を計測しよう
ドロップダウンメニューのUI的な課題は「メニューを操作する時のマウスのズレによる誤動作」です。ユーザーの行動（マウス操作）を細かく分解しながら、「マウスのズレ」を検証する方法を考えます。
1. 「メニュー利用」のステップを分解
実際にユーザーがメニューを利用するときの行動を分解してみます。良さそうなページを探すためにメニューをいろいろ開いて眺める行為はUIとしての欠陥ではないので、実際にメニュー項目のクリックにまで至ったフローのみを「メニュー利用」として検証の対象にします。
- メニューを表示（ホバー）
- 下層メニューを表示（ホバー）
- 下層メニューをクリック
Amazonメニューのマウスの動き
2. メニュー利用の成功／失敗フローを判定する
それぞれの「メニュー利用」が、「成功フロー」（ズレることなくスムーズにメニューを操作できた）と「失敗フロー」（ズレたために元のメニューに戻る必要があった）のどちらなのかを判定できれば、マウスのズレを定量的に計測できそうです。
Amazonメニューのマウスの動き 成功フロー
第一階層のメニュー項目にマウスカーソルを重ねて（ホバーして）下層のメニューを表示し、その下層メニューを閉じることなく順調にカーソルを移動させ、下層メニュー内のいずれかのリンクをクリックするのを想定通りの成功フローと定義します。最初に想定外のメニューを開いてしまったり、目的のリンクがどのメニュー内にあるかをウロウロと探したりすることもあるので、下層に移動する前にホバーした第一階層メニューの数は考慮しません。
Amazonメニューのマウスの動き 失敗フロー
クリックに至った下層メニュー（３）を表示する前にカーソルがズレて隣のメニューが開いてしまい、元のメニュー（２）に戻ってから再度下層メニュー（３）を表示してクリックした場合を失敗フローと定義することにします。ズレるのは隣接するメニュー項目のみであり、2つ以上離れたメニューが開かれた場合は意図的な探索行動とみなします。ズレた後にそのまま元に戻るのがポイントです。
判定の実装方法としては、たとえば第一階層のメニュー表示（ホバー）時にメニューの位置を取得し、最新の3回分を変数に記録しておきます。メニューがクリックされた時点で1番目と3番目が同一であり、かつ2番目が3番目の隣（プラス1またはマイナス1）であれば、マウスのズレによる失敗フローと判定できます。
この判定は完璧ではありませんが、改善前後の推移を統計的に把握するだけなので、まずはこの程度で進めます。あまり凝ると、実装や集計が大変になります。
3. 判定結果を送信して判定をリセット
下層のメニューがクリック（mouse down）された時点で成功／失敗の判定結果をリンク計測します。解析ツールへデータを送信した後は、ホバーされた直近3つのメニューを変数からクリアしてリセットします。
トラフィックが多いサイトの場合、成功クリックは毎回送信すると膨大になるので、Cookieを使ってセッション中に一度だけ送信するのも良いでしょう。一方、失敗クリックは発生頻度が低く、かつセッション中の失敗頻度も指標として見たいので、毎回計測する（またはセッション中の送信回数に上限を設定する）のがおすすめです。
見るべき指標を定義する
メニュー操作の成功と失敗が計測できたら、目的によってどのような指標を見るべきか考えます。
説得材料：メニュー操作に失敗する人は優良顧客か？
メニューの改善に取り組む前に説得材料が必要な場合は、メニュー操作に失敗している人によるビジネス貢献度を調べると便利です。最終的なビジネス価値を知りたいので、コンバージョン率や単価ではなく売上高（または資料請求数など、サイトの最終ゴール）を指標にします。前述の判定で失敗フローが発生した時にのみ期間を長めにしたカスタム変数に「menu-fail」などの文字列をセットすれば、有効期間内に一度でもマウスのズレを体験した人による売上を楽にレポートできるようになります。
メニュー操作の失敗率は下がったのか？
メニュー改善を実際に実施する場合は、リリースの前後で「メニュー操作失敗率」を比較し、UI改善の効果を検証します。メニュー操作失敗率は、成否に関わらず一度でもメニュー中のリンクをクリックしたセッション（訪問）のうち、失敗フローが発生している割合に注目します。
指標：
| メニュー操作失敗率 | ＝ | 失敗フロー総数 |
| メニュー中のリンクを1回以上クリックしたセッション数（訪問回数） |
※サイトやユーザーによって数値は変わるので、絶対的な数値に大きな意味はありません
レポート結果を分析したら、アクション（意志決定／更なる改善／評価）につなげることが重要です。
AmazonメニューUI検証レポート 例
まとめ
以上、ユーザーの視点でマウス操作行動を分解し、ユーザビリティを定量的に評価する方法について紹介しました。このように分析・対策方法まで具体化してからツールの導入や実装を進めると、アクション可能で無駄のないWeb解析を実現できます。完璧な検証方法ではないので、他の定性的な調査手法も併用しながら上手に活用してみてください。
著者：清水 誠 （しみず・まこと）
Webアナリスト。1995年国際基督教大学を卒業後、凸版印刷やScient、Razorfishにて大手企業へのWebコンサルティングとIA設計に従事した後、ウェブクルーでは開発・運用プロセス改善、日本アムウェイでは印刷物のデジタル化とCMS・PIM導入、楽天ではアクセス解析の全社展開、ギルト・グループではKPIの再定義とCRMをリード。2011年9月に渡米、マーケティング製品の品質改善に取り組む傍ら、執筆活動も続けている。サンクトガーレン社外CMO、電通レイザーフィッシュ社外フェローも務める。
