2014.7.30 / UI

ドロワーというナビゲーションの再考

Tomohiro Suzuki

以前Facebookのアプリケーションで採用されたことを皮切りに、ここ数年で多くのアプリケーションで使われることになったドロワーというナビゲーションについての考察です。
最近ネット上でも話題になっており、安易なナビゲーションへの採用が見直されているされているインターフェイスでもあります。しかしドロワーの必要性について疑うことは良いのですが、表面的にただドロワーを使ってはいけないという情報に左右されていては、安易なドロワーはなくなったとしても、次に安易なタブなどが量産されるということが予測できます。
UIに関わるデザイナーとしては、なぜドロワーが適していないのかということと同時に、どのような状況下であればドロワーが適しているのかは考え続ける必要があるでしょう。

ドロワーの歴史

まず名前の由来としては、たしか2013年にAndroidでナビゲーションドロワーのためのフレームワークが公開されたことが始まりだったのではないかと思います。それまではサイドメニューやサイドナビゲーション、スライドナビゲーションとなどと呼ばれており、デザイナー同士であってもニュアンスは伝わっても固定の名称でドロワーという単語は使っていなかった気がします。
その名前の通り、現実のドロワー(引き出し)のようにジェスチャやタップなどでドロワーを引き出すことで、ユーザーはドロワー内に含まれている情報を扱うことができます。
ビジュアルに多少の違いはあれども、引き出されるという意味で普段は見えない位置に収納されており、ユーザーは可視化されているトリガーをタップ、またはジェスチャにより引き出すことができるナビゲーションをドロワーだと定義し、以後扱います。
また、iOSでのドロワーとAndroidでのドロワーではOSの違いが影響し構造が異なる部分が存在するため、以後iOSのドロワーを基準として紹介しつつ、比較対象となりえる部分ではAndroidでのドロワーも少しだけ登場させます。

最初のドロワー誕生

モバイルアプリケーションのUIとしてドロワーを採用したのは、正確性は定かではありませんがFacebookが最初だったと考えられています。
それ以前のFacebookのアプリケーションではスプリングボードのUIがトップ画面として採用されていました。そのためメインの利用であるニュースフィードの観覧も毎回スプリングボードから移動し、ちょっとした友達リクエストを確認したいだけでもまたスプリングボードに戻るなど、現在よりもタップ回数が非常に多いUIでした。たしかにスプリングボードでは表示項目も大きく、初心者には優しいのかもしれませんが、少し慣れてきた人にとっては非常に手間がかかるUIだったと考えられます。
その後5.0のバージョンでドロワーが採用されることとなりました。Webのサイドナビゲーションにあったものをそのままアプリに取り入れただけではなく、通知などのよく使われる機能はポップオーバーで表示できるようにすることで、ユーザーはフィードを読むという行為に集中することができるようになりました。さらにこのタイミングでネイティブ化されたことで表示速度も改善されたことが、Facebookのドロワーが市場に受け入れられるということにおいて大きな要因にもなりました。
ここから、他の多くのアプリケーションでもドロワーが次々と採用することになりました。

ドロワーの普及

Facebookでのドロワー採用以降、多くのアプリケーションでもドロワーが採用されることとなりました。代表的なアプリケーションとしてはPath、Foursquare、YouTube、Spotify、Airbnbなど一部現在ではUIを変更しているものもありますが、ドロワーの影響を受けたアプリケーションは多く存在します。
そのようなアプリケーションがドロワーを採用する理由としては下記のような表面的なメリットが考えられるからでしょう。

  1. 多くの情報を入れることができる
  2. 画面を広く使うことができる
  3. 今後の拡張性が期待できる
  4. 主に使う機能のみを強調することができる
  5. Androidとの整合性

しかし、一件メリットに見える部分ですが簡単にデメリットにも成り得ます。特にクライアントワークなどであれば、上記の1や3はドロワーを安易に採用しやすい理由であり、その結果デメリットを持ったドロワーが生まれる可能性は高いと言えます。
特にFacebookがドロワーを採用した当時のような、スマホアプリ全盛期ではまずは作り上げることが重視されていたという背景もあり、表面的なメリットのみを求めた結果、下記のようなデメリットを持つドロワーが生まれることになりました。

  1. 多くの情報の中から目的の情報が探すのが困難
  2. 拡張性ができてしまったことにより、不要な機能が増加
  3. ドロワーに慣れて使うためには中の項目を記憶する必要がある
  4. ドロワーを開くために1アクションが必要
  5. 階層構造が深い場合にはドロワーを開ける画面まで戻る必要がある

上記1は特に新規のユーザーほど影響を受けやすい部分です。3の理由とも近いのですが、Facebookのように既にWebで利用していた人が多く存在するサービスと同じような情報量を新規のサービスでも適用することになれば、ユーザーはどの機能を使ったらいいのかがわからず、サービスのコアな利用体験はできない可能性が高まります。慣れればたしかに使いやすいのかもしれませんが、そもそも慣れれば良いという考えは「ユーザーがサービスに慣れるまでなぜ使ってくれるのか」という前提が抜け落ちて考えられがちなため、結局は慣れるまでに多くのユーザーは利用をやめてしまうでしょう。また、1の原因はリリース当初には発生していなくとも、2のような機能拡張による理由で誘発的に発生することもあります。
4と5の問題に関しては、そのアプリケーションの情報構造によっては問題ないこともありますが、タブの場合に比べて単純にアクセスするためにかかるアクション数は増えるでしょう。また、この問題に関してはiOSとAndroidでのOSレベルでの違いも関係している部分もあるため、次の項目で実際にAndroidでは推奨されているドロワーについて見ていきます。

Androidとの違い

ナビゲーションドロワーはアプリの構造を反映して、主なナビゲーションハブを表示します。ナビゲーションハブは、ユーザがアプリの中で最も頻繁に使用する画面・もしくはアプリの機能(画面)を切り替える際に中心となる画面と考えてください。アプリの主要な機能に関わるトップ階層には、最低限ナビゲーションハブで移動できるようにするべきです。
アプリの構造が深い場合、ユーザが頻繁に訪れる浅い階層に、同様のナビゲーションハブの画面を追加できます。

参考:ナビゲーションドロワー | Android Design 翻訳 by チームEGG

上記は、Androidでドロワーを利用したアプリケーションの構造です。Androidでは画面内、または端末の物理ボタンとして戻るボタン(バックボタン)が存在しています。そのため、下層画面であったとしても上記画像の青い線のように、ドロワーにアクセスすることが可能になっています。しかし、iOSでは上記画像の上位階層からしかドロワーにアクセスすることができないアプリケーションが大半です。一部YouTubeなどではiOSの戻るジェスチャの変わりにドロワーを表示というアクションを使用していますが、他の大半のアプリケーションでは階層が深くなるほどドロワーも遠くなります。
そのため、頻繁に深くの階層までの遷移が発生するタイプのiOSアプリケーションではドロワーは不向きであると考えられます。これがタブであれば、たしかに96pxほどはタブバーが占有することにもなりますが、主要機能の切り替えはしやすくはなります。

良いドロワーとは

ここまでで少し扱いが難しいような印象を与えてしまったかもしれませんが、良いドロワーというものも存在します。もちろん検討の可能性があるというだけであり、実際には異なることもありますが、ナビゲーション構造を考える上でのひとつの指標にはなるかもしれません。

同粒度のカテゴリーで分類できる構造の時

ドロワー内に格納される情報の分類がそれぞれ同じ粒度で行なわれている場合です。上記であれば、左の分類に比べ、右は果物という同粒度での分類であるため、ひとつひとつを記憶することはなくとも、少なくともドロワー内に存在している情報全体としては記憶しやすいはずです(左の分類はデザイナーであればよく見かける分類で、記憶しやすいという意味では適切な例ではないかもしれませんが)。
参考:「マジックナンバー7」とメニューの数 — Website Usability Info

上記の例では果物での分類でしたが、実際のアプリケーションとしては上記のNewsStormなどのニュースアプリケーションなどが考えられるます。またはTop Appsという、各国のAppStoreのランキングを見るアプリケーションのカテゴリメニューなどです。ニュースなどでは現在はSmartNewsのようなタブのUIも考えられるかもしれませんが、このような一般的に認知されているカテゴリでの分類であればドロワーの利用は十分可能ではないかと考えられます。

主な利用機能が限られている時

実際の利用状況はわかりませんのであくまで推測ということになりますが、利用する画面が限られており、ナビゲーションによる切り替えが少ない例を紹介します。
上記左はEVOMAILというメール管理アプリケーションのドロワーです。モバイルアプリケーションの特性を活かすのであれば、基本的には外出時のメール確認のみを利用すると考えることができます。あまり使わない機能はドロワー内に格納することにより、メール表示画面での一覧性を高めています。
上記右はFoursquareですが、以前はホームでチェックインできたということもあり、主にホーム画面の利用に特化したアプリケーションでした(現在はチェックイン機能はSwarmに移行)。当初はタブのUIが使われていたFoursquareですが、2年ほど前にUIがリニューアルされました。通知などもホーム画面右上に存在しているため、基本的にドロワー内のメニューを開くことが少なく、ホーム画面内の要素の表示を確保しています。
このように、最初のホーム画面に主な利用が収束されるタイプのアプリケーションであればドロワーは検討できるのではないかと考えられます。もちろん、だからといってドロワー内のナビゲーション数を多くすることは認知的負荷に繋がり、結局タブのほうが良かった…ということになるかもしれませんので、使用には注意が必要です。

ドロワーからタブへの移行

最後に、今後ドロワーからタブに移行する際の注意点について少しだけ紹介します。
アプリUI/UXデザイナー必見!「ハンバーガーボタン」ナビゲーションを使うとユーザーエンゲージメントが半減することが発覚
上記の例ではZeeboxがタブからドロワーに移行した際の記事になりますが、逆にドロワーからタブに移行する際にも同じような結果になることがあります。慣れという問題は予想以上に大きく、UIの変更によって今までユーザーの中で蓄積された経験が変化するのであれば、短期的な計測ではタブに変更したからといって定量的な分析では良い結果が出ないこともあります。
例えばタブに変更したことによってアプリケーションの滞在時間が短くなってしまったなどのことが考えられます。しかし、ただ滞在時間が短くなったという断片的な判断をするのではなく、同時に定性的なヒアリングなど調査を行うことで、アプリケーションの性質にもよりますが実は目的がすぐに達成されたのでアプリケーションを閉じたのかもしれないことがわかることもあります。
大切なのはデータによる判断だけではなく、実際にデザイナー自身がユーザーの声を聞くということです。手を動かして形にすることも大切ですが、それ以前に実際に足を動かしてユーザーのいる場所に向かうのもデザイナーの役割です。ナビゲーションについて考えるきっかけとしては記事などでもいいかもしれませんが、それを実際に適用するかの判断基準を持ち、常に良いユーザビリティを提供するためには何が良いか考えましょう。

お互いの学びと成長を促せるメンバーを募集しています

STANDARD「未来の豊かさにつながる仕組みをデザインする」というミッションを元に、人の役に立つ事業やビジネス、サービスの創出や改善をデザインの力で支援し続けています。

そのために、お互いの価値観を尊重し、学習と実践と内省をしながら成長できる場所であり続けることを目指しています。

あらゆる物事の仕組みを設計するデザイナーとして、ご一緒に考えながら試行錯誤していきたいという方からのご連絡をお待ちしています。

記事一覧へ

Related Articles

About us

私たちはユーザーへの価値とビジネスの成立を実現するUXデザインを提供し、
アプリやWebサービスの新規立ち上げや改善をサポートしています。

STANDARDはUXデザインを軸に、新規事業の立ち上げや既存サービスの改善を支援するデザイン会社です。