ryonakae/mobile-ui-design

Mobile UI Design

Overview

モバイルアプリ UI を実装するときに、見た目だけでなく操作性、情報設計、ブランド世界観、OS らしさまで一貫して判断する。 Web UI の定石をそのまま持ち込まず、タスク達成、可読性、タップしやすさ、状態遷移、文脈に合った表現を優先する。

基本原則

• 主要タスクを先に特定する。最も頻繁で重要な操作を曖昧にしない。
• 可用性・アクセシビリティ > OS 慣習 > ブランド表現 の順で判断する。
• iOS と Android の差分は消しすぎない。同じ目的でも最適な見せ方や操作の期待値は異なる前提で考える。
• Flutter や React Native でも、実装都合ではなく利用者の期待に合わせて iOS らしさ / Android らしさ / ブランド優先の度合いを決める。
• 装飾で問題を隠さない。情報階層、状態設計、文言の明確さが先で、ビジュアル演出は後から乗せる。
• 実装技術が明示されたら、その技術の公式 docs や一次情報を確認してから API 名、コンポーネント名、制約を確定する。取得手段は固定しない。

進め方

1. 画面の目的、利用者、頻度、失敗コスト、利用文脈を整理する。
2. references/core-principles.md を使って、優先順位と OS 差分の扱いを決める。
3. ナビゲーション、入力、状態表示、確認操作の選択が必要なら references/pattern-selection.md を使う。
4. タイポグラフィ、色、余白、トーン、ブランドの落とし込みが必要なら references/visual-language.md を使う。
5. 実装後または改善提案時は references/review-checklist.md を使ってレビューする。

避けること

• Desktop や Web サイトの構成をそのまま縮小して持ち込むこと
• 主要アクションより装飾を目立たせること
• 余白やアニメーションで高級感を出そうとして操作密度を壊すこと
• プラットフォームの慣習を無視して、毎回独自 UI を発明すること
• すべての画面を同じテンプレートに押し込めて、タスク差分を消すこと
• 空状態、エラー状態、読込中、権限拒否などの非ハッピーパスを後回しにすること

レビューの扱い

• スクリーンショットや動画があるなら、コードだけで結論を出さず必ず視覚的にも確認する。
• 視覚的な材料がない場合は、コード、仕様、文言、状態分岐からレビューし、視覚確認できていないリスクを明示する。
• レビュー結果は、まず「タスク達成を妨げる問題」、次に「OS 期待との不整合」、最後に「視覚的な粗さ」の順で整理する。

Reference Files

• references/core-principles.md モバイル UI の基本原則、優先順位、OS 差分、ブランド統合の考え方を読む。
• references/pattern-selection.md ナビゲーション、フォーム、一覧、詳細、モーダル、状態設計の選び方を読む。
• references/visual-language.md タイポグラフィ、色、余白、アイコン、文言、ブランド世界観の作り方を読む。
• references/review-checklist.md スクリーンショットレビューとコードレビューの観点を読む。