※記事内に商品プロモーションが含まれる場合があります
- 未経験からUI/UXデザイナーを目指しています
- アプリとWebのUIデザインって、何がどう違うのかよくわからん
- Webのデザインはやったことあるんだけど、アプリはやったことない
- WebとアプリのUIデザインの違いについて解説するよ
- アプリはWebと違って、HIG・Material Designといったガイドラインや審査基準があるよ
- アプリのUIデザインをするときの、気をつけるポイントなどをまとめてみたよ
はじめに
先生、アプリとWebのUIデザインって、何か違いがあるんですか？Webと同じ感じでデザインすればOK？
基本的なデザインの考え方は一緒じゃが、いくつか気をつけねばならんポイントがあるぞ。
一番大きいのは、プラットフォームの違い、開発言語の違いで、
Webの感覚でデザインすると、実装がめちゃ大変、みたいなこともよくあるぞ。
WebはHTMLとCSSがベースで、ブラウザで見てますけど、アプリは違うんですか？
アプリは、iOSならSwift、AndroidならKotlinとJavaがメインの言語じゃ。
iOSはAppleStore、AndroidはGoogle Playで配信されるから、
各プラットフォームのルールに依存する形になるんじゃ。
ふーん… なんかややこしいですね。。
未経験からUI/UXデザイナーを目指していると、採用などで、
「アプリのデザインの経験はありますか？」と聞かれることがたまにあります。
アプリのデザインは一見Webのデザインと似ていますが、実装言語やプラットフォームなど、微妙に異なる特徴があります。
未経験からUI/UXデザイナーを目指す方は、大体はWebをベースに勉強しますし、
デザインの基本的な考え方（目的・課題に対する解決）は一緒なので、
アプリのデザインの経験がなくても問題なく転職はできます。
ただ、「Webとアプリのデザインはちょっと違う」ということを知っておくと、
採用案件の見方や面接での会話などで、ちょっと役に立つ場合があります。
このページでは、アプリとWebのUIデザインの違いについてまとめてみました。
よければご参考ください。
ぼくは未経験から事業会社のUI/UXデザイナーに転職しましたが、当時はWebのデザインや実装の勉強しかしておらず、入社後にアプリのデザインをやることになった時に初めて、ちゃんとアプリを意識したデザインを学びました。
アプリのデザインは「やることになったら勉強する」で基本はいいと思いますし、UI/UXデザイナーはまずはWebがしっかりとできることが大前提です（Webの方が圧倒的に需要があります）。それをふまえた上で、読み進めていただければと思います。
Webとアプリで大きく違うところ
実装言語
WebとアプリはUIの見た目や操作感だけでなく、動かす技術の土台が根本から異なります。
2026年現在だと、それぞれメジャーな実装言語は下記のような感じです。
- Web
HTML、CSS、JavaScript - iOSアプリ
Swift、SwiftUI（AppleのiOS向け標準UIフレームワーク） - Androidアプリ
Kotlin、Jetpack Compose（Googleが提供するAndroid用の宣言的UIフレームワーク） - 両OS共通
Flutter（Google製）、React Native（Meta製）などのクロスプラットフォームツール
Webの場合は、「HTMLがコンテンツと構造、CSSがスタイリング、JavaScriptが挙動」みたいな感じで、
ファイルを分けて実装をすると思います。
一方でアプリは、例えばSwiftだと、Swiftの中でレイアウト構造から挙動、データ連携、スタイリングまで指定します。
Swiftには「SwiftUI」や「UIKit」という、Appleがすでに用意しているインターフェース構築フレームワークがあり、
それを使いながらアプリを作っていきます。
デザイナーがアプリの実装言語を触ることはほとんどありませんが、
「WebとアプリではUIを作っている言語がそもそも別物」という点は、まず押さえておきたいところです。
ぼくもSwiftを少しかじってみていますが、HTMLやCSSと全然違い、
「システム構築」っぽい感じの実装です。（伝わるか微妙ですが。。）
ちなみに「両OS共通」のFlutterやReact Nativeは、1つのコードでiOSとAndroid両方のアプリを作れるツールです。
ソースコードの管理がラクな反面、OS標準のコンポーネントを使えないので、インタラクションがぎこちなかったり、Swiftでサクッと実装できるUIも、React Nativeだと実装がやや大変、みたいなことが多々あります。
OSとの連携
実装言語とあわせて押さえておきたいのがOSとの連携です。
SwiftやKotlinで書かれたネイティブアプリは、OSと直接つながっています。
アプリなら、例えば下記のような機能に当たり前にアクセスできます。
- プッシュ通知
アプリを開いていなくても、能動的にユーザーへ情報を届けられる - バッジ通知・ホーム画面ウィジェット
アプリを開く前から、未読数や最新情報を伝えられる - Touch ID / Face ID
指紋や顔で、ワンタッチでログインできる - GPS・カメラ・マイク
地図連携・QRコード読み取り・音声入力などのUIが作れる - オフライン対応
音楽や電子書籍などをダウンロードしておけば、ネット接続なしでも使える
アプリの場合、プッシュ通知で大事な情報をリマインドする体験を築いたり、
「現在地を使う」ボタンを置いて住所入力の手間をグッと減らすこともできます。
アプリUIは、OSの標準機能を前提とした、シームレスな体験設計ができるのがポイントです。
一方でWebは、ブラウザのサンドボックス内で動く仕組みのため、
OSのハードウェア機能へのアクセスに制限があります
プッシュ通知・バッジ通知・ホーム画面ウィジェットは使えず、
生体認証（指紋・顔認証）によるシームレスなログインも基本的にはできません。
「同じサービスなのに、アプリ版の方がなんか快適だな」と感じる理由は、だいたいこのあたりにあるかなと思います。
厳密に言うと、「PWA（プログレッシブウェブアプリ）」という仕組みを使えば、Webでもプッシュ通知やホーム画面へのアイコン追加などができます（iOSのSafariもWebプッシュに対応しています）。
ただ、できることの幅はまだネイティブアプリに及ばない部分が多いです。
プラットフォーム
Webとアプリでは、「作ったものをどうやって世に出すか」というプラットフォームの違いがあります。
Webは、サーバーにアップすれば誰でも自由に公開できます。
公開に誰かの許可は必要なく、URLさえあれば、検索エンジンやSNS経由で世界中からアクセスできます。
一方でアプリは、iOSならApp Store、AndroidならGoogle Playという公式ストアを通じて配信されます。
ストアに出すには審査を通る必要があり、デザインも各プラットフォームのルールに沿っているかを見られます。
（審査については、後ほど解説します）
そしてこの配信方法の違いは、ユーザーからすると、
「検索で訪れるWeb」と「自分の意志でインストールし、日常的に使うアプリ」という、
利用体験の違いにもつながります。
Webとアプリだと、「誰が・どんな状況で使うか」という前提がだいぶ変わってくるので、
UIの設計のし方にも違いが出てきます。
Webは誰でも公開できる側面、いわゆる「ダークウェブ」のようなものや、エロサイトのようなものまで無数にあります。
また、Googleなどの検索エンジンにインデックスされるよう、SEOを意識した作りにすることが多いです。
対してアプリは、プラットフォームがApple、Googleに完全に牛耳られているため、公序良俗を乱すアプリは、基本的に審査の段階で排除されます。代わりに、SEOのような概念はありません。
操作方法
Web（SP）とアプリは、ぱっと見、画面の作りや操作方法が一緒のように見えますが、
実は下記のように、細かい違いがあります。
- 表示領域
SP Webはブラウザのアドレスバーと下部ツールバーが表示領域を圧迫する。アプリは全画面を使える - ハプティクスフィードバック
操作に応じた振動フィードバックはアプリ固有の演出手段。SP Webでは原則使えない - キーボード表示時のレイアウトシフト
テキスト入力時にキーボードが画面を押し上げる挙動。例えば下部固定の入力フォームをタップした際、アプリだとキーボードと一緒にフォームも押し上げることが可能だが、Webは連動して動かすことが基本できない（頑張ればできるが、実装がややこしい）。 - OS標準のジェスチャー
長押しでアクションを実行するなど、OSレベルのジェスチャーをアプリは難なく活用できる（Webも頑張ればできなくないが、実装が複雑）。
アプリの画面UIをデザインする際は、これらの違いをふまえながらデザインをする必要があります。
とはいえ、Webとアプリとでデザインの共通点もあります。
例えばiOSアプリでは、44×44ptが最小タップ領域の目安とされています（参考：Apple Human Interface Guidelines – Buttons）。
「指で押しやすいサイズを確保する」という感覚はSP Webの設計と共通なので、このあたりの経験はアプリのUIにもそのまま活かせます。
アプリにはOSのデザインガイドラインと審査がある
上でも述べたように、アプリには、App Store、Google Playにおける審査があります。
審査でリジェクトされると、アプリを公開したり、アップデート内容をリリースすることができません。
審査の項目はいろいろあるのですが、その中にはデザインに関する内容もあります。
Apple、Googleはそれぞれ、下記のデザインガイドラインを公開しており、
基本的にはこれに準じてデザインしていれば問題ないとされています。
あくまでも「ガイドライン」なので、「ガチガチに守らないといけない」というわけではなく、逸脱していても問題なく審査が通るケースもあります。審査する側も人間（担当者が付く）なので、ここら辺は人のさじ加減というか、担当者の性格やタイミングで変わる部分もあります。
ガイドラインは、初めは読んでも「？？」だと思いますが、ざっと目を通し、雰囲気を掴んでおくだけでも十分だと思います。
実際にどういう内容でリジェクトされるのか、どこまでなら大丈夫なのかは、実務の中でナレッジを貯めて対応していくのが一番確実なので、そこで感覚を磨いていくのが良いかなと思います。
HIG（Human Interface Guidelines）
Appleが定めたiOSのデザインガイドラインです。
使用フォントはSF Pro（日本語はヒラギノが適用されます）が基本で、
モーダルの設計思想・ナビゲーションバーの位置・ボタンのスタイルなど、
Appleが「iOSらしい体験」として定義したルールが細かく決められています。
AppleはiPhoneだけでなく、iPadやApple Watchなどのデバイスも展開しているので、
それらのデバイスも加味した形でガイドラインがまとめられています。
HIGから少し話が逸れますが、Apple Review GuidelinesのSection 4（https://developer.apple.com/app-store/review/guidelines/#design）では、「Webをそのままラップしただけのアプリ」「他社UIをコピーしたデザイン」「テンプレート生成アプリ」がリジェクト対象として明記されています。
「Webがあるから、それをそのままWebviewでアプリで表示しちゃおう」というのはリジェクト対象になります。アプリで作る場合は、アプリネイティブの画面・機能を一定用意しなければなりません。
MD（Material Design）
Googleが定めたAndroidのデザインガイドラインです。
使用フォントはNoto Sans（日本語）とRoboto（英数字）が基本で、
こちらもHIGと同様、ボタンスタイルやボトムシートなど、デザインルールが決められています。
Google Playの審査はAppleより緩めで、Material Designへの準拠は「推奨」であって必須ではありません。
コンテンツポリシー・プライバシー・機能性が審査の中心で、純粋なUIデザインの出来で落とされることは少ない印象があります。
デザイナーとしては、独自色の強いUIを提案するときに「ガイドラインから外れすぎていないか？」を頭の片隅に置いておくと良いでしょう。
HIGとMDを見比べるとわかりますが、同じデザインパーツでも、形状や余白の取り方など、違いが結構あります。
よく「Androidアプリも、iOSアプリと同じデザインにしたい」みたいなオーダーを聞きますが、これは時に、Androidの標準パーツをゴリゴリにカスタマイズしなければならず、実装コストが大きかったり、そもそもできなかったりします。
iOSとAndroidは無理にデザインを揃えようとせず、それぞれのガイドラインの中で程よくバランスを保つことが大切です。
アプリUIを初めて担当するときに意識すると良いこと
Webデザインの経験は、アプリのUIデザインにも活かすことはできますが、
Webの感覚のまま設計すると、詰まりやすいポイントもあります。
そこでぼくなりに、アプリUIデザインを担当する際に意識しておくと良いかなと思うことを、４つほどまとめてみました。
① ナビゲーションの設計思想が変わる
Webはディレクトリ構成、すなわち「パンくず」の構成がページの階層設計に直結していました。
TOPを起点として、下層をどうしていくか、みたいな考え方ですね。
一方アプリは、まずはタブバーを考え、そこを起点に下層の画面を形成していきます。
このタブバーの構成がアプリの「顔」となる部分で、アプリでどのような体験を提供したいのか、その根本思想がここに反映されます。
アプリは立ち上げた際、必ずしもホーム（TOP）からスタートしない、という特徴があります。
例えばLINEはトーク画面がデフォルトでオープンしますし、iOS標準のメモアプリは前回開いていた画面からスタートします。
「TOP＞下層ページ」みたいな画面遷移を前提としない設計ができるのも、アプリの特徴だったりします。
② 画面遷移の概念が変わる
Webはページ単位でURLが変わり、ブラウザの「戻る」ボタンで履歴をたどる設計です。
例えば「A→B→C」と画面遷移した場合、A、B、C、それぞれの画面を「それぞれ表示」します。
一方アプリは、画面が「スタック（積み重なり）」として管理され、
前の画面に戻るときは、積み重なった画面を1枚（または複数枚）取り除いて戻るイメージになります。
タブバーを持つアプリ（Instagram、X、メルカリなど）は、
タブがそれぞれ別々のナビゲーションスタックを持っています。
例えばSpotifyで、「ホームタブでミックスリストを開く」→「検索タブに移り検索→リストを表示」→「ホームタブに戻る」としても、ホームタブではミックスリストを開いた状態が維持されています。
アプリのUIデザインをする際は、「どこに遷移するか」とセットで、
「どの画面が積み重なっているか」まで考えておくと、
体験を整理したり、実装的に無理のないUI/UX設計を行えると思います。
③ コンポーネントはOSのものを優先的に使う
Webではコンポーネントをあまり意識しない（または０→1で作る）かと思いますが、
アプリでは、まずOSが用意している標準コンポーネントでUIを実現できないか確認するのがおすすめです。
標準コンポーネントは、ユーザーが見慣れたUI/UXで体験が自然になりますし、
実装コスト、保守コストもかなり下がります。
（AppleやGoogleも、標準コンポーネントの使用を推奨しています）
担当するアプリの実装状況や方針、成長フェーズにもよりますが、
標準コンポーネントを問題なく使用できるのであれば、
HIGやMDからコンポーネントを探し、積極的に使っていくと良いでしょう。
Webのように自由なレイアウトや凝った演出をそのまま持ち込むと、カスタム実装が多くなり、コスト高なアプリになってしまう側面があります。
④ 他社アプリでやっているデザインを真似る
デザインに困ったら、とにかく他社アプリで採用しているUIを真似てみましょう（完全パクりではなく、あくまでも真似です）。
他社アプリで実現できているUIは、大体は実現可能です。
正直、アプリの実装や技術的なことはあまりわからなくても、
「他社アプリでやっている」という事実があれば、一旦はOKで、エンジニアさんも検討してくれます。
また、他社アプリをよく観察し、真似ることで、自分のアプリUIデザインのスキルも上がります。
デザインは結局、「上手い人のデザインを真似る」のが、スキル上達の一番の近道ですので、
臆せずどんどんどんどん真似ていきましょう。
ぼくも昔、アプリ画面のトレースを50本ほどやって、アプリUIデザインの感覚をつかみました。
その時の記事がこちら↓
UI/UXデザイナーがトレース100本ノックをやってみた（バナー/アプリ）
有名サービスで見るSP WebとアプリのUIデザインの違い
実際に、有名サービスのWeb（SP）とアプリの画面UIをいくつかピックアップし、
そこから見受けられる違いやデザイン意図を考察してみました。
キャプチャは、左がWeb、右がアプリです。
あくまでも考察なので、間違ってたらごめんなちゃい。
Amazon（商品詳細）
Webは検索エンジンから直接詳細ページを開く場合があるので、ヘッダーにロゴを入れてブランド認知をしています。
アプリは「Amazonアプリを立ち上げ」ているので、ロゴがなくてもブランドは認知済みとみなし、省略ができます。
Webではお届け先を常時表示していますが、アプリでは非表示です。
アプリの方が使い慣れた（利用頻度の多い）ユーザーが多く、
毎回見せる必要がないとみなして優先度を下げているのかもしれません。（Webは初回利用ユーザー向けに表示、など？）
また、アプリは検索バーにカメラ（画像検索）を標準搭載しています。
端末機能に直接アクセスできる強みを活かし、リッチな体験を築いています。
Suumo（物件詳細）
Webの物件詳細の下部には、パンくずや関連コンテンツへのリンクが載っています（おそらくSEO対策がメインです）。
一方でアプリは、関連するおすすめ物件だけが並ぶ、すっきりとした設計になっており、
物件選びに専念できるUIになっています。
また、Webは会社ロゴの入った共通フッターを持っています。
物件詳細だけでなく、多くのページでこの共通フッターが表示され、
ブランドの統一感や、サイト内の回遊性向上に役立てています。
Airbnb（TOP）
物件のカセットをタップした際の挙動が、Webだと「バツッ」と切り替わる感じなのに対して、
アプリだとフワッと、途切れのないアニメーションで切り替わっています。
Webは新しい画面のデータ取得・描画が終わるまで一瞬「空白」になりやすく、
途中のアニメーション（画像がそのまま拡大するような滑らかな引き継ぎ演出）は組まれていません。
一方アプリは、画面遷移が「ナビゲーションスタックへのpush」という形で処理され、
OS標準のアニメーションが最初からセットで付いてくるため、
データ取得中も前の画面の要素を活かしながら途切れなく遷移できます。
厳密には、Webも頑張ればこうしたなめらかなインタラクションを実現できる（SPAを使うなど）のですが、
このあたりはアプリの方が楽に実装でき、かつ体験が優れており、アプリに軍配が上がります。
よく「アプリでサクサク検索！」とか「アプリだと快適」みたいな謳い文句を聞きますが、あれはこのあたりのことが起因しています。
実際、Webよりもアプリの方が快適なインタラクションを実現できるので、UI/UXデザイナーとしても、アプリUIの方がデザインしてて楽しいと感じることが多い気がします。
まとめ
- 「ユーザー中心に、目的への解決策を設計する」というUIデザインの基本的な考え方は、Webもアプリも共通
- Webはブラウザでの検索、アプリはインストールして日常使い、という使われ方の違いがある
- アプリには審査基準があり、デザインガイドラインへの準拠が求められる
- アプリでは、システムジェスチャー・ハプティクスなど、アプリ特有の体験設計ができる
お疲れ様でした。どうもありがとさん
