POSTD PRODUCED BY NIJIBOX

POSTD PRODUCED BY NIJIBOX

ニジボックスが運営する
エンジニアに向けた
キュレーションメディア

POSTD PRODUCED BY NIJIBOX

POSTD PRODUCED BY NIJIBOX

ニジボックスが運営する
エンジニアに向けた
キュレーションメディア

FeedlyRSSTwitterFacebook
Randy Fisher

本記事は、原著者の許諾のもとに翻訳・掲載しております。

おそらく皆さんは、「ハンバーガーメニューの使用についての別の意見か。まさにそれが必要なんだ」と思いながらこの記事を読んでいるでしょう。Appleは 「あなたが使っていないといいのだが…」 と言い、Googleの製品デザインのガイドラインには 「賛成だ。しかしこのようにデザインしよう」 とあり、Jacob Nielsenは 「代わりにピザにしてみよう」 と言い、例はまだまだ続きます。しかし、ちょっと待ってください。誓ってもいいのですが、この記事は違います。これは、あなたが自身のサイトをデザインする時に、興味深い考察が得られるような特定の質問に焦点をあてたものです。アイトラッキング・ソフトウェアと25人の親切な参加者の協力により、次のような質問に対する洞察を得るために実験を行うことができました。

ユーザがデスクトップ上で、ハンバーガーメニューを見た時と従来のメニューを見た時とでは、ユーザの行動に変化はあるのでしょうか?

正直に言うと、私たちは結果に驚きました。

最近、ハンバーガーメニューアイコンは、FacebookやSnapchat、全てのGoogleアプリなど、モバイルアプリやレスポンシブなwebアプリで利用され、どんどん普及しています。ハンバーガーメニューにはしばしば、他のメニューオプション以外の”その他”が含まれていて、限られたスクリーンのスペースを最大限に活用するため、重要性の低いメニューは隠されています。

しかし、それは今ではデスクトップ用のWebサイトでより多く使われているということに気付きました。Googleの新しいEメールお助けWebサイトであるInbox、将来有望な検索エンジンDuckDuckGo、Webサイトのデザイン・ホスティングサービスSquarespaceは、どれもサイトでハンバーガーメニューを使っています。GoogleはMaterial Design Guidelinesの中で、デスクトップ用WebサイトにNavigation Drawerを常設することさえも勧めています。それが使わるべきであるか、あるいはどう使われるべきかについてどのような意見を持っていようとも、これがユーザインターフェイスデザインにおいて、幅広く認識されている記号であるということは、この時点では否定することはできません。

ほとんどの調査上でモバイル上でのWeb閲覧ががデスクトップでのWeb閲覧を上回るようになってため、モバイルの慣習がデスクトップに受け継がれていくのは理に適っているように思えます。しかし、これはどんな場合にも良いことでしょうか? これを行うことによって、発見しやすさが妨げられるということはないのでしょうか? それは行動を変えるのでしょうか? もし変わるなら、良い方向と悪い方向のどちらに変わるのでしょうか?

私は何年も前にその記号を、コンテキストメニューの選択肢の”入れ物”としてデザインしました。それは、オブジェクトの上をマウスの右ボタンでクリックする時、私たちが今日使っているコンテキストメニューとある程度は同等のものです。(それは)非常に”道路標識的な”シンプルさで、機能的に覚えやすく、結果として生じる表示されたメニューリストの見た目によく似るということを意味していました。
ハンバーガーメニューの作成者、Norm Cox

実施したこと

視線についてのデータを集めるために、アイトラッキング・ソフトウェアを使って、25人のユーザに一連の作業をしてもらいました。テストに使用したサイトはGoogle Inboxですが、2つの異なるバージョンがランダムに提示されるようにしました。バージョン1は、最近デザインされた、ハンバーガーメニューを用いたGoogle Inboxそのものです。バージョン2は、ハンバーガーメニュー内に隠れていたメインメニューが水平方向に表示されるもので、私たちが別に作成しました。ユーザには以下の作業を行ってもらいました。

  1. メッセージを開く
  2. 新しいメッセージを作成する
  3. (レイアウトを変更するために)設定にアクセスする
  4. 会話スレッドを見つけてアクセスする(画面には表示されていない)

それぞれのセッションは10分程度で、その後、ユーザにフォローアップの質問をしました。ユーザが見たものや考えたことに対するリアクションが、ハンバーガーメニューの適切な使用方法や目的に合うものであったかを正確に判断するためです。

分かったこと


ユーザに特定のメニューのオプションを探すよう依頼した際、水平方向のナビゲーションバーを使ったバージョンのほうが、早く見つけることができました。上記の画像を見ると、ナビゲーションバーの周辺に視線が集中しているのが分かります。多くの人が言うように、固定のナビゲーションバーの画像は、最も簡単で使いやすいように思われます(メニューオプションが表示されているという観点から)。

「固定のナビゲーションバーはインターフェースにはふさわしいとは思えないので、ハンバーガーメニューのほうが優れている」と言う人たちがいます。オフセット検索バーは、メール内だけではなくて、Web全体を検索するものだと思った、とコメントした人がいました。また、ハンバーガーメニューが優れていると考える人たちは「そのほうがサイトの見栄えがより専門的な感じがする」とも言っていました。

視線のパターンを見ると、それぞれのビューが裏付けているように思える、ある予想外のパターンが分かります。ハンバーガーメニューのページでは、ユーザの視線が主に垂直方向に動いているのです。

一方、固定のナビゲーションバーのページでは、視線は水平方向に動いているようです。

この視線の動きの裏には、何か隠れた意味があるのでしょうか。現時点では確かなことは分かりませんが、Webページのコンテンツを見るユーザの行動に明らかな違いがあるということが、この例からはっきりと分かります。

考察したこと

ここで1つ興味深いことをお伝えしたいのですが、テストに参加したユーザに、ハンバーガーメニューをどんな所でよく見かけるかと質問したところ、ほとんどの人が、モバイルアプリで見かけると回答しました。さらに、なぜモバイルアプリでハンバーガーメニューが使われると思うかと質問したところ、ほとんどの人から、小さなデバイスで画面のスペースを有効に使うための方法だから、という回答が多く得られました。それならばなぜ、画面のスペースの確保が問題にならないデスクトップで、ハンバーガーメニューが用いられるのでしょうか?

その答えは、ソフトウェアの目的によって違う

あなたのウェブサイトの役目は何でしょうか? プロダクト、サービスを売っているのでしょうか。観衆にコンテンツを配信しているのでしょうか。明確な目的や特殊なニーズの解決のために使われるツールやデジタルプロダクトを提供しているのでしょうか。

あるプロダクトを使っているとき、おそらくはっきりと簡潔なゴールを念頭においてWebサイトを閲覧しているでしょう。5/3 Bankのような銀行のサイトを例にとってみます。そのページに来るユーザは、残高照会、預金転送、支払いといった明確なタスクをなるべく早く効率的に遂行したいと考えています。たいていこれらのオプションは意図的にデザインの最前面に提示されているため、簡単に見つけることができます。
webサイト例:CNN、500px、5/3 Bank、Facebook

別の例を挙げましょう。プロダクト販売のためにSquarespaceで作ったサイトがあるとします。人々に購入をしてもらいたいわけですから、そのための最善の方法は、ユーザが共感せざるを得ないストーリーを体験できるよう、手助けすることです。サイト内を探索し、適切なコンテンツを発見できるよう誘導する以外の、より良い方法は何でしょうか。Lisa Gevelberが、MicroMomentsに関するThinkWithGoogleの記事にこう書いています。「消費者は欲しいときに、欲しいものを得たいのです。つまり、これまでになく第一印象が重要ということです。特にモバイルにおいては」。よって、「ユーザが自分に合う情報を見つけ出し、プロダクト購入に至るまでページに留めさせたい、ならばコンテンツを前面に見せつつ、同時に隠すことも必要だ」という考えも出てくるでしょう。ハンバーガーメニューを使って、ユーザが自発的に必要なものを見つけ出せるようにしたいと考えることもあるでしょう。
Webサイト例:Squarespace、MTV、Leo Burnett、IGN

以上は、とても複雑なWebのビューに関する2つの見方であり、状況(と、そのユーザ)はそれぞれにユニークです。次に進めるためには、コンテクストと、ユーザがどのように私たちのテクノロジーを体験しているかを認識し、その体験のためにデザインすることが非常に大切です。

Web開発業界は進化し続けるインターネットと共に、光速で前進しています。ハンバーガーメニューを普遍的なルールにするかどうか決めなければ、という段階は過ぎ去りました。私たちは、ただトレンドを追うのではなく、特定のツールとレイアウトを選ぶのはなぜなのか、ということを真剣に考えなければなりません。意見交換を続け、それがどんなところに着地するのか注目していきましょう。

Jereme Magsaysay

非凡なサマーインターン、Jereme Magsaysayの尽力なくしてこのプロジェクトは成り立ちませんでした。感謝します。

監修者
監修者_古川陽介
古川陽介
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 グループマネジャー 株式会社ニジボックス デベロップメント室 室長 Node.js 日本ユーザーグループ代表
複合機メーカー、ゲーム会社を経て、2016年に株式会社リクルートテクノロジーズ(現リクルート)入社。 現在はAPソリューショングループのマネジャーとしてアプリ基盤の改善や運用、各種開発支援ツールの開発、またテックリードとしてエンジニアチームの支援や育成までを担う。 2019年より株式会社ニジボックスを兼務し、室長としてエンジニア育成基盤の設計、技術指南も遂行。 Node.js 日本ユーザーグループの代表を務め、Node学園祭などを主宰。