android-mobile-frontend-design

Android モバイルフロントエンドのデザイン

使用する場面

• 次のようなリクエストでは、このスキルを使用します：Android モバイルフロントエンドのデザイン、Android 画面をゼロからデザインする、Android モバイル画面を再デザインする。
• 主な成果：ブランドを前面に出し、ローカライズとオーバーフローに配慮したガイダンスを通じて、Compose と Views の両方で Android モバイルフロントエンドをゼロから設計し、既存画面を改善し、UI の問題を修正します。
• 階層、リズム、画面構成、ナビゲーションのクローム、余白、サーフェスモデル、ビジュアルの方向性、オーバーフローへの対応、ローカライズに配慮したモバイル UX など、デザインの意図を優先する作業には、このスキルを使用します。
• 画面をより上質に、現代的に、洗練された印象に、分かりやすく、落ち着いた雰囲気に、ブランドらしく、またはモバイルネイティブにしたいという要望には、実装の詳細に取りかかる前にこのスキルを使用します。
• 作成・改善・修正のルーティング表、Compose と Views の引き継ぎルール、ローカライズとオーバーフローのストレスチェックリストが必要な場合は、references/patterns.md を読んでください。
• 新規画面のデザインブリーフ、OrbitTasks の再デザインレビュー、オーバーフローやローカライズの修正作業について、ドキュメントのみの手順を確認する場合は、references/scenarios.md を読んでください。
• 対象範囲が広がる場合は、次のスキルに引き継いでください：
• android-compose-foundations
• android-material3-design-system
• android-compose-accessibility
• android-viewsystem-foundations
• android-testing-ui

作業モード

create

• 画面がまだ存在しない場合、または大まかなアイデアしかない場合に使用します。
• 色やコンポーネントに飛びつくのではなく、ユーザーの目標、主要なタスク、状態モデル、モバイルでの階層から始めます。
• 画面の主要なパターンを早い段階で決めます：リストと詳細、フィード、フォーム、ダッシュボード、オンボーディングフロー、確認フロー、設定画面。

improve

• 画面は機能しているものの、ありきたり、ごちゃついている、古びている、分かりにくい、またはビジュアルが弱いと感じられる場合に使用します。
• まず、維持すべきものを確認します：タスクの順序、ユーザーのメンタルモデル、ブランド上の制約、すでに有用な意味を持つ要素。
• リクエストで明示されていない限り、プロダクトの意図は変えずに、階層、余白、アフォーダンス、アクションの強調を再設計します。

fix

• テキストの切れ、不自然な余白、アクセスできないアクション、分かりにくい階層、インセットの崩れ、RTL の不具合、弱いローディング状態、窮屈なコントロールなど、具体的な UX 上の欠陥がある既存画面に使用します。
• 全面的なビジュアル刷新を提案する前に、明瞭さを取り戻すために必要な最小限のレイアウトとインタラクションの判断を修正します。
• 「切れている」は、UI が切り抜かれている、トリミングされている、途中で省略されている、隠れている、またはその他の理由で視覚的に崩れている状態として扱い、主要な障害モードの一つとして対処します。

ワークフロー

1. まず作業モードを選択します：create、improve、またはfix。
2. モバイルの観点から画面の役割を定義します。誰が使うのか、何をすばやく完了する必要があるのか、一目で何を理解する必要があるのか、何に安心感や落ち着きを感じる必要があるのかを明確にします。
3. スタイリングの前に情報の階層を決めます：主要なアクション、最も目立つコンテンツブロック、二次アクション、補足メタデータ、復旧時の状態。
4. 画面の役割に合ったモバイルシェルを選びます。デバイスのサイズとタスクの頻度に応じて、トップアプリバー、ボトムバー、レール、シート、FAB、セグメントコントロール、タブ、リストと詳細の分割表示を使い分けます。
5. ブランドらしさを意識しながら、Android で使いやすいサーフェスモデルを構築します。密度、角の表現、奥行き、色の使い方、タイポグラフィの強調によってプロダクトらしさを表現しつつ、タッチ操作のしやすさを損なわないようにします。
6. 現実のモバイル環境の制約に照らしてレイアウトを検証します。長い文字列、翻訳されたラベル、複数行のテキスト、RTL、狭い幅と広い幅、キーボード、システムバー、カットアウト、分割画面、タブレット、折りたたみ式デバイスを確認します。
7. 実装スキルに引き継ぐ前に、操作への到達しやすさ、タッチターゲット、階層、コントラスト、スキャンの速さを検証します。
8. 実装を適切な担当先に振り分けます：

• デザインが確定しており、作業が Compose の構造やレイアウトに関する場合は、android-compose-foundations。
• 作業がトークン化、テーマ設定、カスタムデザインシステムの変換に関する場合は、android-material3-design-system。
• セマンティクス、フォーカス、支援動作に専用の作業が必要な場合は、android-compose-accessibility。
• 対象の画面が XML／ViewBinding／Fragment UI の場合は、android-viewsystem-foundations。
• デザインのスクリーンショット検証や操作検証を行う準備ができている場合は、android-testing-ui。

優れた UI の品質基準

モバイル Android UI における「優れている」とは

• 最初に表示される画面領域で、この画面の目的、最も重要なこと、ユーザーが次にすべきことの3つがすぐにわかります。
• 既定のコンポーネントを組み合わせただけではなく、意図を持って設計された画面に感じられます。間隔、文字のスケール、色の強調、奥行き、動きがすべて同じプロダクトの個性を支えています。
• 主要なアクションが、うるさくならずに明確に伝わります。
• 厳しい条件下でも UI の魅力が保たれます。翻訳、フォントの拡大、キーボード、ジェスチャーナビゲーション、分割画面、大画面へのサイズ変更によって、使い心地が損なわれません。
• 派手なグラデーションやガラス表現、装飾的なクロームを盛り込むのではなく、自信に満ち、摩擦に配慮しているからこそ、プロダクトが上質に感じられます。

実践的なデザインルール

• Android の 4dp グリッドを基準に一貫した間隔のリズムを使いつつ、明瞭さが増す箇所では十分な余白を設けます。
• それぞれ異なる役割を持つタイポグラフィを構築します。オーバーライン／キッカー、見出し、セクションラベル、本文、メタデータ、アクションテキストが互いに混同されないようにします。
• 各ビューポート領域で、ひとつの要素を主役にします。見出し、フィルター行、カード、CTA がすべて同じ強さで競い合うなら、デザインを導く要素がありません。
• 弱いカードや区切り線をたくさん使うより、数を絞った存在感のあるサーフェスを優先します。
• 状態、アクション、信頼を明確にするために色を使います。アクセントカラーを背景一面に使わないでください。
• 動きは構造を示し、文脈を保ち、状態の変化を確認するために使います。装飾だけが目的なら取り除きます。

画面の種類ごとのベストプラクティス

• リストとフィード： 1秒以内に項目の階層を把握できるようにし、行の密度を意図的に設定します。意思決定に影響するコンテンツより、二次的なメタデータを控えめにします。
• フォーム： ラベルを常に表示し、入力チェックと必須項目を明確にします。キーボード操作を進めても、実行中のタスクが隠れないようにします。
• ダッシュボード： デスクトップ向けの情報密度を安易に持ち込まないでください。概要、判断、詳細確認へと明確につながる流れにコンテンツをまとめます。
• オンボーディングと空の状態： 画面ごとにアイデアをひとつ、主要な操作をひとつに絞り、詳細より先に価値を伝える文言を使います。
• シートとダイアログ： 集中して判断を行う場面や、文脈に沿ったフローに使います。ナビゲーションが破綻したまま画面全体を隠す場所として使わないでください。

デザインの方向性

装飾ではなく、まずモバイルでの利用を起点にする

• 片手で操作する必要があること、画面をスクロールしないと見えない位置に置けること、画面の動きやキーボード表示、狭い画面幅でも見える状態にしておく必要があることを決めます。
• モバイル UI は、デスクトップ UI を無理に縮小したものではなく、意図を持って設計されたものにします。小さな画面では、デザインレビューよりも早く、階層設計の弱さが露呈します。
• ブランドを前面に出すことは、単に目立たせることではありません。汎用的な Material の土台ではなく、意図が感じられ、記憶に残り、製品らしさがあるインターフェースにすることです。

明確なビジュアルの方向性を選ぶ

• 画面の種類ごとに、主となる方向性を 1 つ選びます。
• confident utility：情報量が多く、明快で、動作が速く、読みやすさを重視し、色使いは控えめです。
• calm guidance：余白を広く取り、セクションのリズムを明確にし、やさしく強調します。親しみやすいオンボーディングや空の状態に適しています。
• premium trust：レイヤーを重ねたサーフェス、洗練された動き、豊かなタイポグラフィを用い、お金、健康、取り消せない操作に対する信頼感を高めます。
• expressive brand：より強い色使い、記憶に残る形、特徴的なレイアウトを取り入れつつ、タッチ操作への配慮と読みやすさを保ちます。
• 関連する画面全体で方向性を一貫させます。高級感のあるダッシュボードと、平坦で汎用的な詳細画面が並ぶ場合、デザインシステムに一貫性がない可能性があります。

作成モードの詳細

• 次の項目から始めます。
• 画面の目的
• ユーザーの状態と緊急度
• 主要な操作を配置する場所
• コンテンツの順序
• 読み込み、空、エラー、オフライン、成功の各状態の設計
• 主要な操作に合わせて画面の構成を選びます。
• フローを完了させるための画面下部の操作エリア
• 繰り返し行う主要な操作である場合に限り、フローティングアクション
• 文脈に応じた、中断可能な操作にはシート
• 画面の中心がコンテンツの種類の切り替えである場合に限り、タブまたはセグメントコントロール
• 画面ごとに、強力な主要操作を 1 つに絞ります。すべてが強く主張すると、何も主導できません。

改善モードの詳細

• 次の点を監査します。
• 最初に視線が向かう場所
• 現在、主要な操作が配置されている場所
• 余白によってグループ分けが伝わるか
• サーフェスが平坦すぎるか、雑然としているか、細かく分割されすぎているか
• 操作する前に、ユーザーに読ませる量が多すぎないか
• すべてのコンポーネントの視覚的な重みが同じで、画面が汎用的に感じられないか
• 動き、色、書体が、画面の把握に役立っているか、単にノイズを加えているだけか
• 次の点を維持します。
• 製品のロジック
• 役に立っている既存のユーザー操作の慣れ
• 現在も有効な既存のコンポーネント契約
• すでに効果を上げているデザイントークンへの投資
• 強調の順序を変え、弱いセクションをまとめ、ラベルを明確にし、余白を活用して視認性を高めます。雑然とさせずに、行動喚起を見逃せないものにします。

修正モードの詳細

• 次の問題を診断します。
• テキストの切り抜けや省略
• 長いテキストに対応できないボタン、チップ、タブ、スナックバー
• キーボードやシステムバーの背後に隠れる操作
• シートの高さの崩れや、安全でない固定高
• コントラスト不足や小さすぎるタッチターゲット
• 情報量の多い画面をスキャンしにくくする、不自然な余白
• 次に何をすべきか説明していない空、読み込み、エラーの各状態
• すべてが同じサイズ、重み、緊急度であることによる視覚的なアンバランス
• リズムの弱さ、角丸の不統一、エレベーションの不統一、意図しない色使いによる「安っぽい」印象の UI
• まずレイアウトの問題を解決し、その後で見た目を整えます。英語では高級感があっても、ドイツ語やアラビア語で崩れる画面は完成ではありません。

ローカライズとオーバーフローに関するベストプラクティス

ローカライズを考慮したデザイン

• 長い文字列への拡張は例外ではなく、デフォルトとして想定します。
• ラベル、チップ、CTA テキストは、英語の文字列の長さに依存せず、翻訳後も適切に表示されるように設計します。
• 内容を明確に伝える必要がある場合は、ボタン、フィルター、バナー、オンボーディングの文面、空の状態で、まず複数行表示を検討します。
• 疑似ローカライズは、QA ツールとしてだけでなく、デザインツールとしても扱います。疑似ローカライズした文字列で階層構造が崩れるなら、そのデザインは脆弱すぎます。
• 単一の全体言語や単一の書式スタイルを前提とせず、アプリごとの言語やロケールの切り替えに対応します。
• 狭いセルやサマリー行を設計する際は、ロケール固有の数字、日付・時刻形式、通貨の幅、読み進めるリズムを尊重します。
• 翻訳によって失われる特定の語順に、視覚的な強調を依存させないようにします。

RTL を考慮したデザイン

• 左右の前提をハードコードせず、安全に方向性のあるレイアウトを反転します。
• RTL のコンテキストでも、アイコン、シェブロン、進行状況の表示、テキストの配置が正しく保たれるようにします。
• 反転すると崩れる非対称なパディングや、左端を基準にした視覚的な工夫に頼らないようにします。
• 同じ画面内に方向が混在するコンテンツがある場合、画面全体が一方向に動作すると想定せず、読みやすさを重視して設計します。

オーバーフローと切り取りへの対策

• 長い文字列、フォントの拡大、複数行のコンテンツに対する安全性が実証されていない限り、高さ固定のテキストコンテナは使用しません。
• 装飾的なレイアウト上の判断によって、CTA ラベル、チップ、タブ、シート、スナックバー、ツールバーのタイトル、ボトムシートのハンドルが切り取られないようにします。
• 気づかれないまま切り捨てるより、安全な折り返しや適応型の再配置を優先します。
• 省略記号は、隠れた内容が本当に重要でない場合、または展開、詳細表示、ツールチップ相当のヘルプなど、明確な回復手段がある場合にのみ使用します。
• キーボード、IME のインセット、切り欠き、タスクバー、システムバーによって、主要な操作や入力中のフィールドが隠れないようにします。
• 大画面や折りたたみ式デバイスでは、ヒンジ、折り目、不自然なデッドゾーンに重要なコンテンツを配置しないようにします。
• エッジツーエッジのレイアウトでは、ジェスチャーインセットと競合する領域に、タップやドラッグが重要な UI を直接配置しないでください。

アダプティブデザインとエッジツーエッジのベストプラクティス

• デフォルトでエッジツーエッジに設計します。スクロール領域や背景コンテンツはシステムバーの背後に配置できますが、タップが重要な UI はインセットとジェスチャーの競合を考慮する必要があります。
• target SDK 35+ および新しいデバイスでは、エッジツーエッジを任意の装飾ではなく、Android の通常の使用体験の一部として想定します。
• ウィンドウサイズクラスとアダプティブな構造を使用し、レイアウトが間延びしたスマートフォン UI にならずに、レール、複数列のセクション、リストと詳細の配置へと再構成できるようにします。
• 大画面では、少なくとも Android の大画面向け品質基準の「最適化」レベルを満たす必要があります。レターボックス表示を前提とせず、無駄な空白を残さず、スマートフォン専用のナビゲーションを前提としないでください。
• 折りたたみ式デバイスやマルチウィンドウの状態は、リリース後に驚かされるものではなく、レイアウトのテスト対象です。

Compose と View システムのガイダンス

Compose

• 柔軟な階層構造、アダプティブな構成、表現力のあるスペーシング、再利用可能な UI プリミティブが必要な再設計では、Compose が最適です。
• コンポーザブルなセクション、より簡単なアダプティブ分岐、最新のモーションや視覚的な洗練によって画面が改善される場合は、Compose を使用します。
• デザインの意図が固まり、残る作業がコンポーネントのアーキテクチャとレイアウトの実装になったら、android-compose-foundations に引き継ぎます。

Views と XML

• View システムの画面にも優れたデザインが必要です。Compose の画面だけが高品質に感じられると思い込まないでください。
• 改善を計画する際は、Fragment、RecyclerView、ViewBinding、ConstraintLayout の実情を考慮します。
• 1 つのデバイスプロファイルでしか正しく見えない、静的で寸法を固定した XML より、レスポンシブまたはアダプティブな View システムのレイアウトを優先します。
• 画面の方向性が明確になり、残る作業が XML や Fragment の実装になったら、android-viewsystem-foundations に引き継ぎます。

ガードレール

• 常にモバイルファーストを優先します。正当な理由なく、スマートフォンの画面にダッシュボード型ウェブ画面の密度やポインター操作を前提とした設計を持ち込まないでください。
• ブランドを前面に出すスタイルでも、ローカライズ、オーバーフロー、アクセシビリティに対応できるようにしてください。
• タッチターゲットは操作しやすく、見つけやすい状態を保ちます。ビジュアルのミニマリズムを、操作領域を小さくする言い訳にしてはいけません。
• 後付けではなく、最初からエッジツーエッジのレイアウトと実際のインセットを考慮して設計します。
• ハードコードされた単一のキャンバスではなく、適応型の構造によってスマートフォン、タブレット、フォルダブル、マルチウィンドウの状態に対応します。
• 既存の画面を改善する際は、プロダクトのメンタルモデルを維持します。依頼されていない限り、ワークフローを再設計しないでください。
• 装飾的なモーション、装飾的なサーフェス、過剰なクロームよりも、明確な階層と復旧しやすい UX を優先します。
• スペーシング、タイポグラフィ、奥行き、色の強調のうち、少なくとも 1 つは画面に印象を残すものにします。このスキルが目指すのは「無難だがありきたり」な仕上がりではありません。

アンチパターン

• 小さなコントロールや密集したトップレベルナビゲーションを使い、スマートフォンの画面を圧縮されたウェブダッシュボードのように設計すること。
• テキストの長さが変わるとすぐにクリッピング、切り詰め、重なりが起きる固定幅や固定高を使うこと。
• 英語のみのスクリーンショットを、デザインが完成した証拠として扱うこと。
• 主要なアクションを画面の下端より下、キーボードの背後、または視認性の低いクロームの中に隠すこと。
• 画面が雑然として読み取りにくくなるまで、すべてのセクションをカード、区切り線、または枠付きサーフェスにすること。
• RTL や狭い幅で崩れる左右対称の仕掛けに頼ること。
• 構造的に堅牢なデザインを作る代わりに、コピーを短くしてレイアウトの不具合を解決すること。
• 対象を絞った修正で本当の問題を解決できるのに、見た目を一から作り直すこと。
• 見た目の情報量の多さを、プレミアムな品質だと取り違えること。
• 静止状態では見栄えがよくても、IME、フォントの拡大、長文コンテンツによって脆くなる画面をリリースすること。

例

正常系

• シナリオ：明確な階層、主要なアクション、適応型シェル、ブランドを前面に出したビジュアルを備えた、新しい Android モバイル画面をゼロから作成します。
• コマンド：bash skills/android-mobile-frontend-design/scripts/run_examples.sh

エッジケース

• シナリオ：既存の OrbitTasks Compose 画面を改善し、長いローカライズ文字列、キーボードインセット、RTL のミラーリングがあっても、コントロールがクリッピングされないようにします。
• コマンド：cd examples/orbittasks-compose && ./gradlew :app:assembleDebug

障害からの復旧

• シナリオ：全面的な再設計に進む前に、既存の XML 画面のテキスト切り詰め、窮屈なスペーシング、弱い空状態やエラー状態を修正します。
• コマンド：cd examples/orbittasks-xml && ./gradlew :app:assembleDebug

完了チェックリスト

• 作業モードが create、improve、fix のいずれかとして明示されています。
• 実装の詳細に入る前に、情報の階層と主要なアクションの配置が明確になっています。
• デザインの方向性はブランドを前面に出しつつ、モバイルネイティブでプラットフォーム上の使いやすさも保っています。
• ローカライズ、RTL、オーバーフロー、キーボード、インセットに関するストレスケースを明示的に検討しています。
• Compose と Views の振り分けが明確で、実装作業が適切な隣接スキルに引き継がれています。
• 作成、既存画面の改善、または不具合の修正にあたり、重大なデザイン上の判断を未解決のまま残さずに活用できるガイダンスになっています。

Official References

• https://developer.android.com/develop/ui/compose
• https://developer.android.com/develop/ui/compose/designsystems/material3
• https://developer.android.com/develop/ui/compose/designsystems/custom
• https://developer.android.com/develop/ui/compose/system/material-insets
• https://developer.android.com/develop/ui/compose/layouts/adaptive/use-window-size-classes
• https://developer.android.com/develop/ui/views/layout/responsive-adaptive-design-with-views
• https://developer.android.com/training/basics/supporting-devices/languages.html
• https://developer.android.com/guide/topics/resources/localization
• https://developer.android.com/guide/topics/resources/app-languages
• https://developer.android.com/guide/topics/resources/internationalization
• https://developer.android.com/guide/topics/ui/accessibility/apps
• https://developer.android.com/docs/quality-guidelines/large-screen-app-quality