• Tweet
• 

日本国内でも「モバイルファースト」の考え方が少しずつ浸透しつつあります。今回の翻訳記事はモバイルファーストの提唱者Luke Wroblewski氏の著書「Mobile First」の第４章です。モバイルファーストの考え方が、実例を見ながら理解できる内容となっています。今回の翻訳記事はA List Apart日本語翻訳サイトへも提供しています。

モバイルのコンテンツや動作を設計する時は、明確なラべリングや、範囲と深度のバランス、そしてメンタルモデルを考慮した情報アーキテクチャが重要になります。それに加えて、私たちがモバイルサイトを構築する際は、下記に注意をしなければなりません。

• ユーザーがモバイル端末をどう使用するか、なぜ使用するかを考慮し設計すること。
• ナビゲーションよりもコンテンツを重視すること
• 探索・回遊させるために選択肢を提供すること
• 明瞭で焦点をはっきりさせること
• モバイルの行動様式を踏まえて設計すること

第4章より前のパートでは、モバイルサイトを設計する際に注意すべきモバイルの制約と機能性について語りました。確かにデスクトップサイトにもデスクトップサイト”ならでは”の使い方を決める制限や可能性があります。しかし、デスクトップで実現していることをそのままモバイルに転用することはナンセンスです。それよりも、モバイルならではの機能や、顧客のニーズに沿う機能が何かを考えることが必要です。

人がモバイル端末をどう使用するかを分析しその共通点を見つけることで、モバイルの典型的な利用方法や理由を明らかにできます。Josh Clarkは「Tapworthy」という本で、3つの重要な行動様式（micro-tasking, “I’m local,” and “I’m bored.”：マイクロタスク、ローカルにいること、退屈している状況）を挙げています。これらはGoogleが分析したモバイル端末利用者の行動の3類型（urgent now, repetitive now, and bored now：今すぐできること、今繰り返せること、今退屈していること）と一致しています。これらの行動様式をどう名づけるかは別にして、モバイル端末の使用方法を下記のように分類できます。

• 探す/見つける（緊急性が高い情報、ローカル）：今答えが必要なこと―現在居る場所と関係していることが多い。
• 探究心/遊び心（退屈な状態、ローカル）：時間つぶしや短時間の気晴らしをしたいとき。
• 確認/状態（繰り返し/マイクロタスク）：常に自分に関わることの最新情報を得ておきたい。
• 編集/作成（緊急の変更/マイクロタスク）：今すぐしたいことがあって、待てない。

これらの行動こそが、人がモバイル端末を使う理由です。なので、これらに沿って顧客のニーズを満たすようサイトを構築するのがよいでしょう。例えば、Flickr写真共有モバイルウェブでは4つの基本的な機能を持っています。”Recent Activity” “Uploads from your contacts”の機能では、友人の最新情報を得られます。また、”today’s interestingness” では、興味ある出来事の最新情報を得られたり、”Photos taken neaby”では近くで撮影された素敵な写真を見て楽しむことができたり、上記の行動様式に従っていると言えます。（図4.1）

図4.1:FlickrとBasecampのモバイルサイトでは、人々がモバイル端末を使用する理由が考慮されています。

Basecampのモバイルサイトも同じく、ユーザーニーズを満たすために、新しいメッセージやToDOリストの確認・編集・作成をする機能を重要視しています。FlickrやBasecampを使われる理由は様々でも、各々サイトではどうすればモバイル端末で使ってもらえるか、そのためにはどうしたらよいかを考えてきたのです。

モバイルユーザーの行動様式に従ってサイトを構築すれば、自然と実際のニーズに一致したウェブサイトになります。モバイル端末はどこにいてもアクセスできるものなので、今居る場所でどう役に立つかを考えなければなりません。人々が実際にやろうとしていることに基づいてサイトを構築すれば、そのサイトは現実的に使われるサイトになります。私は最近、このような例に実際に遭遇しました。：「Mobile in Higher Ed blog」の中で、Dave Olsenはanxkck comic（図4.2）に次のように答えています。

･･・（以下に示した）図の右側を眺めながら、次のように考えた「これは自分達のモバイルサイト用に計画されたコンテンツそのもののようだ。」．．．デバイスやネットワークの制約にしたがって不必要なものを取り除くことが、よりよい、もっと役立つユーザー体験の手助けになる。

私には、これよりうまくいい表すことができませんでした。

図4.2：人々が大学のウェブサイトにほしいコンテンツと、実際にあるコンテンツとを比較してパロディ化したA comic from xkcd

ナビゲーションよりコンテンツ

一般的にモバイル端末においては、コンテンツはナビゲーションに優先します。例えば、在庫情報やニュースや株価情報などの頻繁に更新される情報をチェックしたり、地元の情報を調べたりするときは、欲しい情報にすぐにアクセスしたいのであって、サイトマップをまず見たいのではありません。

ほとんどのモバイルサイト（今まで見てきたFlickrとBasecampのような）では、コンテンツではなく、ナビゲーションオプションのリストから議論を開始してしまいます。モバイル端末では速さが重要で、通信パケットの費用はユーザーの負担になりますから、できるだけ早くユーザーが目的とするコンテンツを提供することが大事なのに、です。

YouTubeやESPNのモバイルサイトはまさにコンテンツを重視した作りです。シンプルなヘッダーは何のサイトなのかが分かるようになっていて、1回だけの操作でナビゲーションが機能します。ページの残り部分は、ESPNではタイムリーなコンテンツで、またYouTubeでは人気のある暇つぶしコンテンツで満載です。（図4.3）

図4.3：ESPNやYou Tubeのモバイルウェブではナビゲーションよりもコンテンツに焦点があてられています

回遊と探索

しかし、ちょっと待ってください。もしもコンテンツがナビゲーションよりも優先するのなら、モバイルサイト内をユーザーはどうやって進んだらよいのでしょうか？目的にたどり着くための道筋は必要ないのでしょうか？もちろん必要ですが、コンテンツに辿り着くために、コンテンツを見失ってしまうくらい膨大なナビゲーションバーが必要な訳ではありません。

例えば、Facebookではコンテンツを前面や中央に置いて見やすくしているのは素晴らしいのですが、トップページの3本のナビゲーションバーがあるために、スクリーン上ではひとつのカテゴリのアップデートしか見られません。Google Financeのモバイルサイトでも、モバイル向けのコンテンツをタイムリーにみることができるのですが、5本のナビゲーションバーの下に挟まれています。不必要なナビゲーション機能でスクリーン上の貴重なスペースが占められています。ここはコンテンツのために使用されるべきでしょう。（図4.4）

図4.4：FacebookとGoogle Financeでは、モバイルウェブ上でナビゲーション機能に多くの貴重なスペースが割かれています。

Facebookは最近モバイルサイトをデザイン変更し、ナビゲーション機能を少なくしています（図4.5）。Top NewsとMost Recent filtersを見てみてください。ナビゲーション機能を半分に（10から5に）減らしています。なかなか良い改善ですね！

図4.5：Facebookは最近のデザイン変更で、ナビゲーション機能を減らしました。

YouTubeとESPNの例では、コンテンツがナビゲーションにかなり優先していますが、残った画面スペースを活用することでサイト内を探索し回遊できるようにしています。YouTubeでは、サイトを見て回るために全画面のリンク集を設けています（図4.6）。この方法は、ナビゲーションオプションを意識的に探さないといけない上、ページの前後関係を見失ってしまいます。更に、ヘッダーにあるグリッドアイコンが「ナビゲーションメニューへ」を意味していることを知っていなければなりません。

図4.6：You Tubeのモバイルウェブにある、ヘッダーからアクセスできるナビゲーション専用画面。

ESPNでは、ヘッダーに役割のはっきりした「Menu」ボタンがあり、タップすると下位階層までフォローしたナビゲーションリストが表示されています（図4.7）。この方法なら、ページ遷移することなくどのページに行こうか考えることができます。また、ESPNではほとんどのページのフッタ部分にナビゲーションを設置しています。

図4.7：ESPNのモバイルウェブでは、ヘッダーと各ページのフッタにナビゲーションがあります。

スクリーン下部のナビゲーションは片手でも使いやすいし、スクリーンの最後にたどり着いたときに、次に何をするかのアイディアや選択肢を提供することにもなります。YouTubeにはこのフッタの回遊用ナビゲーションが欠落しているので、ページ下部までたどり着いた後に次のアクションを起こすことができません。（図4.8）

図4.8：You Tubeのモバイルサイトのフッタは行き止まりです。サインアウト？フィードバックの送信？

フッタのメニューはサイトの回遊・探索に役立ちますが、他にすでにあるメニューと同じものにするべきではありません。ただし、最上段のメニューボタンを、フッタにあるナビゲーションリストにページ内リンクさせるのはいいでしょう。私は最近ではBagcheckモバイルサイトでこのアプローチを使用しています。

図4.9：Bagcheckのヘッダーにあるアンカーリンクによって、フッタのナビゲーションメニューにジャンプできます。

フッタにこのリストを置くことで、サイト内を回遊・探索ができます。特に直接コンテンツページに来た人にとっては、そのサイトが提供している他のコンテンツが分かりやすいこの方法が役立ちます。

Bagcheckのフッタにあるメニューには、すでに見たコンテンツに戻りたい時のために、ページの先頭「トップ」に戻るリンクも設置しています。

この設計は、必要最低限のナビゲーションしか使用してないし、コンテンツを見終わった後にもサイト内を回遊・探索することができます。同等のメニューを二つ存在させない方法でもありますし、複雑な技術も必要としません。つまり、”ファンシー”なJavascriptやオーバーレイヤーや、ナビゲーションページなどを用意する必要がなく、フッタにアンカーリンクするだけよいのです。

Bagcheckには、もっと掘り下げてコンテンツを見たい人のためのナビゲーションも入っています（図4.10）。これらのナビゲーションによって、望む人はより詳しい情報を閲覧できますし、そうでない人はすぐ下のグローバルナビゲーションでサイトを回遊することができます。

図4.10：前後関係を踏まえたナビゲーションメニューで、関連コンテンツを探索することができます。

前後関係がわかりやすいナビゲーションは”タスク処理”的な機能にも有効です。Gmailモバイルウェブ（図4.11）では、メニューはスクリーンの上部から表示できます。このメニューは現在表示されているe-mailのメッセージと直接リンクしています。（なので、フッタにリンクがあるのは効果的ではありませんね。）

図4.11：Gmallモバイルサイトは前後関係の明確なため、e-mail上での迅速な作業が可能です。

前のページへ「戻る」

ジャンルを超えて、デザインを学ぶのもとても面白いです。例えば、多くのiPhoneのネイティブアプリケーションにはヘッダーに卓越した「戻る」リンクがあります（図4.12）。（Appleのモバイル端末には物理的な「戻る」ボタンはありませんし、ネイティブアプリケーションの表示システム上にそれに類似するような機能も存在しません。）

図4.12：「戻る」ボタンはiPhoneのネイティブアプリケーションの共通機能です。

しかし、ヘッダーの「戻る」ボタン機能をモバイルウェブに使うのは止めておきましょう。多くの機器（Android, Blackberry, Windows Phone 7 等）には、物理的な戻りボタンがついています（図4.13）。Appleのモバイルウェブブラウザでさえも、アプリケーションツールバーに「戻る」機構が入っています（図4.14）。モバイルサイトのヘッダーに他の戻りボタンを追加することは単に混乱の元になるだけです。サイトを使用している人は、「これらの戻りボタンは2つとも同じことをするのですか？」と尋ねるべきです。

図4.13：Androidの機器 には、ハードウェアとしての「戻る」ボタンがついています。

図4.14：Appleのモバイルウェブブラウザには固定の「戻る」ボタンがボタンツールバーに入っています。

そこで、モバイルサイトを設計する際には、ネイティブアプリのような「戻る」は入れないでおきましょう。もし上の階層へ戻る近道を作るなら、「戻る」以外の呼び名を検討することです。

フッタに固定

iPhoneのネイティブアプリケーションでは、スクリーンの最下段に常に固定して表示されるナビゲーションバーを使用しているものが多くあります。これらのメニューは親指を使ったキー操作がしやすいという特徴があります。ただし、iOSのネイティブアプリケーションではウェブブラウザがスクリーンに入り込むことはないので、モバイルサイトにそのまま導入するのは注意が必要です。

Yahoo Mailのモバイルサイトでは、2つのブラウザメニューと2つのサイトメニューのために、メールを見るスペースがわずかしか取れません（図4.15）。

図4.15：Yahoo Mailモバイルサイトでは、ブラウザウインドウの下段に常に固定して表示されるナビゲーションメニューが使われています。

スクリーンの下にある物理的な操作機構は、スクリーンの下部固定されたサイトメニューに対する課題を突きつけています（図4.16）。つまり、物理的な操作機構の部分とサイトメニューが極めて近くにあるために、押し間違えを起こしてしまいます。

図4.16：たいていの機器には、スクリーンの下に物理的な操作部があります。

ネイティブのモバイルアプリケーションを開発する際にはメニュー位置を調整できますが、モバイルサイトにおいては、物理的なボタンがスクリーンの下にあるかどうかを知った上で設計する必要があることになります。なので、この種の固定ナビゲーションは、変化していくウェブブラウザメニューやモバイル端末の物理的な操作機能があるために、モバイルサイトのナビゲーションとしては拙いものと言えるでしょう。どうしても固定メニューが必要なら、Twitterがモバイルウェブをデザインしなおしたように、最上段に置いたほうが良いでしょう（図4.17）。

図4.17：Twitterの最新モバイルウェブでは、モバイル端末間の違いを考慮しナビゲーションメニューを最上段で使っています。

明快さを保ち焦点を絞る

この本の前半で述べたように、ユーザーがモバイル端末(スマートフォン)を扱うときは「片手間」に行うことが多いのです。心地よくデスクに向かってウェブサイトに集中することはありません。それどころか、彼ら周りには彼らの注意を逸らす現実世界の様々な娯楽が存在します。このような状況では我々がユーザーの注意を全面的に得ることはできません。必要なのは、操作する上で明快かつ焦点の定まったサイトデザインです。多過ぎて邪魔なナビゲーションオプションではありません。

Yahoo!MailのEメール作成画面は、無関係な動作を省いた素晴らしい例で、ユーザーが本来の目的（この場合はEメールの作成）に集中できます。この画面にあるナビゲーションは「キャンセル」のみです（図4.18）。 残りのインタフェースは目下の目的に一点集中しています。

図4.18：Yahooのメール作成画面（左）とESPNのライブゲーム画面（右）におけるナビゲーションオプションの数の比較。

一方で、リアルタイムで更新するESPNのNBAゲームは、ゲーム内容を表示した画面を押しのけるナビゲーションオプションであふれています。目下の目的は実況観戦であって、メニューオプション間を移動することではありません。

モバイル画面のナビゲーションオプションを最小限に抑えることは誤操作を防ぐ効果もあります。 ナビゲーションの選択肢を減らすことで、現行の目的を果たそうとしているユーザーが誤って別の目的に移動する可能性を減らします。

モバイルサイトの構築

モバイルのwebエクスペリエンスを管理する際には、モバイルサイトの操作性をいかにユーザーのニーズに合わせるかを検討しなければいけません。

• 探す/見つける、 探究心/遊び心、確認/状態、編集/作成といったモバイルの使用例は、自社のサイトがどのように使用されるかを予想し、サイトの構成を適切に調整するための助けになります。

• 最初はコンテンツに焦点を合わせ、次にナビゲーションについて検討し、ユーザーが求める情報や目的に瞬時にたどり着けるものにします。

• ナビゲーションオプションを最適に配置することで、ユーザーはより詳しく検索したり、サイト内の他のコンテンツを検索することが可能になります。

• モバイルが使われる理由となるような主要なタスクに合わせてナビゲーションの数を減らすことで、ユーザーが果たそうとしている目的が明快になり、それに焦点を合わせることができます。これはユーザーが急いでいる時や使用環境があまり良くない場合に役立ちます。

• そして、ユーザーがソファーに腰掛けてスマートフォンを手にくつろいだ時間を過ごすとき、この簡潔なデザインが称賛されるのです！