フレームワーク活用ガイドひとことで言うと#
ユーザーはスマホ・PC・タブレットを行き来する。各プラットフォームの作法を尊重しながら、ブランドと体験の一貫性を保つのがクロスプラットフォームデザイン。「どこでも同じUI」ではなく「どこでも同じ体験価値」を目指す。
押さえておきたい用語#
- プラットフォーム慣習（Platform Convention）
- iOS・Android・Webそれぞれが持つユーザーが期待する操作体系のこと。iOSの戻るスワイプ、Androidのバックボタンなど。
- デザイントークン（Design Token）
- 色・フォント・余白などのデザイン値を変数として定義したものを指す。プラットフォーム間で値を共有する基盤になる。
- アダプティブデザイン
- 画面サイズやデバイス種別に応じてレイアウトを切り替える設計手法。レスポンシブの「流動的に伸縮」とは異なり、ブレークポイントごとに最適化する。
- コンテンツパリティ
- すべてのプラットフォームで同じコンテンツと機能にアクセスできる状態。モバイルだけ機能が少ない、といった格差を解消する考え方。
クロスプラットフォームデザインの全体像#
こんな悩みに効く#
- iOS版とAndroid版でUIがバラバラになり、開発コストが膨らんでいる
- Web版からアプリに移行したユーザーが「使い方がわからない」と離脱する
- デザインシステムを作りたいが、プラットフォーム差異の扱い方がわからない
基本の使い方#
まず「全プラットフォームで統一すべきもの」を決める。
- ブランド要素: ロゴ、カラーパレット、トーン＆マナー
- 情報設計: ナビゲーション構造、コンテンツの優先順位
- ユーザーフロー: 主要タスク（登録、購入、検索など）の手順
- これらは「体験の骨格」であり、プラットフォーム間で一致させる
色・フォント・余白をハードコードせず、変数として定義する。
- 例:
color-primary: #D4563A、spacing-md: 16px - トークンを共有することで、プラットフォーム間のブランド一貫性が自動的に保たれる
- フォントはプラットフォームごとに最適なものを選ぶ（iOS: SF Pro、Android: Roboto、Web: 任意）
統一すべき部分と、各プラットフォームに合わせるべき部分を分ける。
- iOS: 戻るスワイプ、下部タブバー、モーダルのシート表示
- Android: バックボタン、FAB（フローティングアクションボタン）、ナビゲーションドロワー
- Web: ホバー状態、ブレッドクラム、キーボードショートカット
- 「このプラットフォームのユーザーが期待する操作」を尊重する
具体例#
状況: MAU 30万のフードデリバリーサービス。iOS版とAndroid版を別チームが開発しており、注文フローのステップ数が iOS: 5タップ、Android: 7タップ と異なっていた。Web版は機能がモバイルの半分しかない。
課題:
- ユーザーがデバイスを切り替えると「同じサービスなのに使い方が違う」
- 新機能追加のたびに3つのプラットフォームで別々にデザイン
改善策:
| 共通化した要素 | プラットフォーム固有にした要素 |
|---|---|
| カラーパレット・ロゴ | ナビゲーションパターン |
| 注文フロー（5ステップに統一） | 戻る操作（スワイプ/バックボタン） |
| メニュー表示順序 | 決済UI（Apple Pay/Google Pay） |
| デザイントークン48個を定義 | アイコンセット（SF/Material） |
結果: Web版に未実装だった 12機能 を追加してコンテンツパリティを達成。注文完了率はAndroidで +8% 改善、クロスデバイスユーザーの継続率が 67% → 79% に向上した。
状況: 従業員150名のプロジェクト管理SaaS。Web版（React）とモバイル版（React Native）があるが、デザインの不整合が 月平均23件 のバグチケットを生んでいた。
導入したデザインシステム:
- デザイントークン: 72個（色16、スペーシング8、タイポグラフィ12、角丸4、シャドウ4、その他28）
- 共通コンポーネント: ボタン、フォーム、カード、モーダルなど 34種
- プラットフォーム固有コンポーネント: ナビゲーション、ピッカー、通知など 12種
デザインシステム導入後、デザイン起因のバグは月 23件 → 4件 に減少。新機能のデザイン→実装のリードタイムは 平均14日 → 7日 に短縮。デザイナー2名で3プラットフォームをカバーできるようになった。
状況: 顧客数18万人の地方銀行。60代以上の顧客（全体の 35%）がモバイルバンキングアプリを使い始めたが、「ATMと操作が違いすぎて不安」という声が月 80件 寄せられていた。
ギャップの分析:
- ATM: 「振込」→「金額入力」→「確認」の3ステップ
- アプリ: 「メニュー」→「振込」→「口座選択」→「金額」→「確認」→「認証」の6ステップ
- ボタン配置もATMは右下固定、アプリは画面中央とバラバラ
改善:
- アプリのトップ画面にATMと同じ 4つの大ボタン（振込・残高照会・入出金明細・設定）を配置
- 振込フローをATMと同じ3ステップに簡略化（認証はバイオメトリクスで自動化）
- ボタン色とアイコンをATMと統一（緑: 確認、赤: キャンセル）
導入3か月後、60代以上のアプリ利用率は 12% → 28% に増加。問い合わせは月 80件 → 22件 に減少し、窓口担当者の負荷も軽減された。
やりがちな失敗パターン#
- 全プラットフォームでUIを完全に同じにする — iOSにAndroidのバックボタンを入れる、WebにモバイルのタブバーをつけるなどはNG。プラットフォーム慣習を無視すると使いにくくなる
- モバイル版の機能をWeb版より少なくする — 「スマホだから簡易版でいい」は2020年代の発想ではない。コンテンツパリティを目指す
- デザイントークンを導入せずにハードコードする — ブランドカラーを変更するとき、3プラットフォーム×数百箇所を手動で修正する地獄になる
- 1つのプラットフォームだけでテストして終わる — iOSでは完璧でもAndroidで崩れていることがある。リリース前に全プラットフォームで確認する
まとめ#
クロスプラットフォームデザインの本質は「全部同じにする」ではなく「体験価値を統一し、操作は各プラットフォームに適応させる」こと。デザイントークンで共通基盤を作り、ユーザーフローを統一し、プラットフォーム慣習は尊重する。この3層構造が、どのデバイスでも「使いやすい」と感じてもらうための鍵になる。