はじめに
入社後、ずっとWeb画面を基準にデザインしてきました。そんな中、ビジェンドプロジェクトに参加することになり、ビジェンドデザインシステムを基盤にWeb画面のデザインを続けました。1年以上の時間をかけて、自然とWeb中心の感覚が身につきました。どのくらい余白があれば息苦しくならないのか、フォントは何pxなら読みやすいのか、ボタンはどこに置けば自然に手が伸びるのか……
そんな中、班長ノートのモバイルアプリプロジェクトが新たに始まり、ありがたいことに担当デザイナーに任命されました。ビジェンドのコンポーネントに慣れた状態でモバイルプラットフォームに向き合ったとき、単に画面が小さくなっただけではありませんでした。Webとモバイル、2つのプラットフォームを比較しながら、実際に「これは違う」と感じた瞬間を整理しました。
フォント
本格的な画面制作に入る前に、デザイントークンとタイポグラフィを先に整理しました。Web制作では本文に12pxを使うこともありましたが、班長ノートのモバイル制作では、ラベル・チップを除き、13pxを最小サイズに設定しました。
一見すると不思議です。スマートフォンは目から30〜40cmの距離にあり、モニター（50〜70cm）よりも近いからです。近くで見れば、よりよく見えるのではないでしょうか。
原則としてはそのとおりです。しかし、モバイルでテキストがより小さく見える理由は解像度にあります。モニターの1pxとスマートフォンの1pxでは、物理的な大きさが異なります。スマートフォンは画面が小さい一方で解像度が極めて高いため、1pxが実際に占める面積ははるかに小さくなります。つまり、pxの数値が同じでも、モバイルではより小さな点としてレンダリングされます。これを補正するため、モバイルではsp（Android）、pt（iOS）の単位を使用し、端末の解像度に合わせて自動的にスケーリングします。
ガイドライン上、iOS Human Interface Guidelinesは最小17pt、Android Material Designは最小12spを推奨しており、実務では本文に14〜16spが最も多く使われています。プラットフォームのガイドラインはあくまで最低値にすぎないため、実際の対象年齢が高い場合は、基準をさらに大きく設定する必要があります。つまり、基準は「誰が読むのか」から始めるべきです。
セーフエリア
Web画面をデザインする際、レイアウトの基準となるのはブラウザのビューポートです。スクロールや画面サイズによって変わりますが、基本的にはビューポートの領域内にコンテンツを配置すればよいのです。
モバイルでは、画面があるからといってその領域をすべて使えるわけではありません。ノッチ（Notch）、ダイナミックアイランド、ステータスバー、ホームインジケーターなど、これらの領域はデザイナーが直接制御できない部分です。システムが使用する空間であり、ここにコンテンツを配置すると隠れたり、タッチできなかったりする問題が起こります。このように、コンテンツの配置時に避けるべき領域をセーフエリア（Safe Area）と呼び、モバイルデザインでは必ず考慮する必要があります。
デザイナーはモバイル画面をデザインする際、ステータスバー（Status Bar）とホームインジケーターの領域をあらかじめ確保する必要があります。特に下部固定ボタン（Fixed Footer）を設計する際にホームインジケーター領域を無視すると、実機上でボタンがインジケーターと重なって見えたり、切れてしまったりして、使いにくさにつながります。Webではビューポート内に収めればよいという感覚が通用しましたが、モバイルではセーフエリア内に収める必要がある、という考え方に切り替えなければなりません。
実際の制作でも、この点を明確なルールとして定めました。下部ナビゲーションバーがない詳細ページの場合、下部のセーフエリアを48pxに固定し、その上にコンテンツとボタンを配置することを基準としました。
モバイル端末は、メーカーやモデルごとにノッチのサイズ、ホームインジケーターの高さなど、環境がそれぞれ異なります。端末にぴったり合わせて制作するよりも、セーフエリアに余裕を持たせて始めることが、さまざまな環境に安全に対応する方法の一つです。
ナビゲーションの位置
Webでは、GNB（Global Navigation Bar）は上部に、LNB（Local Navigation Bar）は左側のサイドバーに配置するのが一般的です。長年にわたって蓄積されたパターンであるため、ユーザーも当然のものとして受け入れています。
しかし、モバイルアプリは異なります。主に親指で操作するため、主要なメニューを画面下部に配置し、これをBottom Navigation（ボトムナビゲーション）と呼びます。スマートフォンを片手で持ったとき、親指が自然に届く領域は画面下部です。反対に、上部の角は片手操作では最も届きにくい領域です。
よく使うナビゲーションを上部に置くと、ユーザーはそのたびに手を動かしたり、スマートフォンを持ち直したりしなければなりません。この概念をThumb Zone（サムゾーン）と呼び、モバイルUXではレイアウト全体に影響します。よく使うアクションは下部に、重要度の低い情報は上部に配置するのが一般的です。CTAボタンを画面下部に固定するのも同じ理由です。Webの上部中心のナビゲーションパターンをモバイルにそのまま適用すると、使いやすさが低下します。プラットフォームごとに、ユーザーの物理的な操作方法が異なることを常に考慮する必要があります。
ホバー
Web画面をデザインする際、ホバーは必ず設計すべき要素です。ボタンにマウスを合わせると色が変わり、リンクに合わせると下線が表示され、カードに合わせると影が濃くなるように、ユーザーに「ここはクリックできます」と伝える最も簡単な方法です。
しかし、モバイル環境にはマウスカーソル自体がないため、ホバーは存在しません。指でタッチした瞬間にすでにpressed（押下）状態へ移行するため、ホバーを経るタイミングがないのです。モバイルでは、別の方法でインタラクティブ要素を表現します。
-
Pressed状態：タッチ時に背景色や透明度を変化させてフィードバック
-
Ripple効果（Android）：タッチした位置から波紋が広がる視覚的フィードバック
-
Haptic Feedback：振動によってタッチを物理的に知らせる
Webでホバーによって解決していたことを、モバイルでは別のインタラクション言語に置き換える必要があります。さらに、ホバー自体が存在しない環境であるため、押せる要素であることをUIそのもので明確に示さなければなりません。背景色や枠線でタップ可能な領域を視覚化したり、アイコンだけを単独で使うのではなく、テキストラベルを一緒に配置したりするのも、その方法の一つです。
情報の流れ
Web画面は広いものです。2段、3段のレイアウトを使えば、1画面にかなり多くの情報を収められます。たとえば、テーブルの横に詳細パネルを追加することで、情報を横方向に展開できる構造です。
モバイルは縦に長く、横幅が狭いため、横に展開するスペースがありません。そのため、モバイルの情報は深さ（depth）によって設計されます。リスト画面 → 詳細画面 → 詳細設定画面のように、階層に沿って内側へ進む構造です。Webでは1画面にすべて表示していたものが、モバイルでは2〜3段階に分かれることがあります。
1画面に収められる情報量が限られるため、何を先に見せ、何を隠すのかという優先順位の決定が、はるかに重要になります。Webではどのように配置するかが問題でしたが、モバイルでは何を先に見せるかが重要な問題になります。
ただし、情報を細かく分けすぎるとdepthが深くなり、かえってユーザーが現在位置を見失いやすくなります。一般的に3depth以内で設計することが推奨される理由もここにあります。情報を分けつつ、ユーザーが道に迷わないよう構造を疑いながら作業することも、モバイル設計における重要な感覚です。
ボタンの位置
Webでは、ボタンはほとんどの場合、コンテンツの流れの中にあります。フォームを入力して一番下に送信ボタンを配置したり、アクションが必要な領域のタイトル横に編集ボタンを配置したりします。ページをスクロールするとボタンも一緒に上へ移動し、ほとんどのボタンを隠さずすべて表示します。
モバイルでは、これとは異なるパターンがよく登場します。
-
Fixed Footer Button：画面最下部に固定されたCTAボタンで、スクロールに関係なく常に同じ位置にあります。ユーザーがどこを見ていても、主要なアクションにすぐアクセスできます。
-
Floating Action Button（FAB）：画面上に浮かぶ円形のボタンです。コンテンツの上に重なり、常に表示される構造です。
これらのパターンはWebでも使えますが、モバイルではるかに自然に機能します。前述したThumb Zoneとつながる理由です。下部固定ボタンは、親指が最も楽に届く位置にあるからです。
実際に制作する中で、このボタンを固定するのか、コンテンツの流れの中に置くのかは、画面ごとに繰り返し悩む判断でした。コンテンツが短い場合は固定ボタンのほうがかえって不自然になり、スクロールが長くなると固定ボタンがあったほうが使いやすくなります。求人詳細画面のようにスクロールが長い画面では下部に固定し、内容が短い画面では流れの中に置くというように、画面ごとに異なる方法を適用しました。
もう一つ考慮したのは、ボタンの危険度です。スペースが狭かったり、誤って押されたときに問題が起きたりするボタンは、Thumb Zoneから意図的に離れた場所に配置し、「もっと見る（more）」ボタンを通して、もう1段階進むように設計しました（エラー防止のためです）。
まとめ
ここまでWebとモバイルの違いを一つずつ見てきましたが、結局のところ、2つのプラットフォームでは考え方そのものがかなり異なっていました。Webが空間をどのように配置するかという問題だとすれば、モバイルは何を選択するかという問題に近いものでした。
プラットフォームが変われば、ユーザーの物理的な操作方法も、情報を消費する方法も、画面を見る距離も変わります。その違いを理解しなければ、Webでうまく機能していたパターンをそのまま持ち込んでしまいます。今回の制作を通じて、プラットフォームを変えるときは、感覚も一緒に変えなければならないことを実感しました。
参考・出典
eykim