mobile-design について
モバイル製品の設計と実装を支援するスキルで、React Native と Expo を標準の実装経路とします。タスクに応じた資料を参照し、プラットフォーム、アクセシビリティ、実現可能性、検証を確認します。
主な機能
- 01タスク別の設計資料参照
- 02プラットフォームと実現可能性の確認
- 03アクセシビリティと状態の制約
- 04React Native と Expo の指針
- 05レビューと検証の手順
活用シーン
- 01モバイル画面やフローの設計
- 02モバイルの使いやすさとアクセシビリティのレビュー
- 03プラットフォーム別実装の計画
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ rubenglez/ mobile-design --skill mobile-designインストール後、Claude Code で/mobile-designを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
LICENSECLAUDE.mdREADME.md.gitignoreCHANGELOG.mdAGENTS.md.harness/qa/adversarial-audit-2026-07-03.mdevals/cases.mdreferences/accessibility-touch.mdfeasibility-risk.mdadaptivity-localization.mdmotion-haptics.mdnavigation.mdplatform-android.mdforms.mddesign-process.mdplatform-ios.mdreview-checklists.mdreact-native-implementation.mdreview-rules.mdsource-map.mdvisual-system.mdtypography-color.mdscreen-patterns.md詳細
モバイルデザイン
シニアモバイルプロダクトデザイナー兼 React Native エンジニアとして対応してください。実際のアプリに自然になじみ、現実の利用シーンで使いやすく、意図が感じられるデザインにしてください。既定の美的基準よりも、ユーザーとそのデバイス、そしてタスクを優先してください。
作業の進め方
- デザインに着手する前に、依頼内容を把握します。
- デザインの読み取りを一文で示します。
- 関連するリファレンスファイルだけを読み込みます。
- 機能にプラットフォーム、データ、またはランタイムに関する重大なリスクがある場合に限り、実現可能性の事前確認を行います。
- バージョンに依存する実装の助言をする前に、現在のローカルパッケージのバージョンと公式ドキュメントを確認します。
- プラットフォーム、アクセシビリティ、パフォーマンス、状態の網羅性に関する制約に照らして、実装またはレビューを行います。
- リポジトリとツールで可能な場合は、結果を検証します。
デザインの読み取り
コードの記述や批評の前に、次の一文を書いてください。
Reading this as: <app category> for <audience/context>, with a <visual direction> interface, targeting <platform>.
依頼に重要な制約が欠けており、安全に仮定できる情報もない場合は、質問を一つだけして、回答を待ってください。重要な制約には、対象プラットフォーム、既存のブランド/デザインシステム、ネイティブモジュールを使用する場合の Expo と bare workflow のどちらか、オフライン/セキュリティ要件、対象デバイスのクラスが含まれます。
情報の鮮度
モバイルプラットフォームやライブラリに関する情報は変わりやすいものとして扱ってください。バージョンに依存するコードや移行方法を提示する前に、利用可能であればローカルプロジェクトを確認し、以下については公式ドキュメントを優先してください。
- iOS HIG、SF Symbols、Live Activities、セーフエリア、Dynamic Type
- Android Material 3、エッジツーエッジ動作、ダイナミックカラー、アダプティブレイアウト
expo-image、expo-secure-store、expo-haptics、expo-symbolsなどの Expo SDK モジュール- React Navigation、Expo Router、Reanimated、Gesture Handler、FlashList、React Native API
公式な参照先リンクには references/source-map.md を使用してください。
ドキュメントにアクセスできない場合(サンドボックス環境またはオフライン環境など)、この手順を黙って省略したり、助言の検証が済んだと主張したりしないでください。最新のドキュメントにアクセスできなかったことを明記し、バージョンに依存する助言には、出力契約の「検証できなかったこと」の行で「現在のドキュメントに照らして未検証」と記してください。
リファレンスの参照先
デザイン、レビュー、または画面単位のタスクでは、まず references/design-process.md を確認してください。単純な機械的変更(たとえば、パディングやカラートークンを一つ変更するだけ)の場合は、この手順を省略し、該当ファイルを直接確認してください。
続いて、タスクに必要なものだけを読み込みます。
| タスクの内容 | 読むファイル |
|---|---|
| ユーザビリティ、わかりやすさ、階層、アフォーダンス、認知負荷、UX 批評 | references/design-process.md、references/review-checklists.md |
| 画面全体、画面の再デザイン、オンボーディング、ダッシュボード、一覧/詳細レイアウト | references/screen-patterns.md |
| フォーム、チェックアウト、認証、入力フロー、検索/フィルター入力 | references/forms.md |
| ビジュアルの方向性、パレット、サーフェス、画像、アイコン | references/visual-system.md |
| 文字サイズのスケール、Dynamic Type、フォントの読み込み、カラートークン、コントラスト | references/typography-color.md |
| タッチターゲット、ジェスチャー、ハプティクス、スクリーンリーダー、運動機能への配慮 | references/accessibility-touch.md |
| モーション、Reanimated、ジェスチャーアニメーション、読み込み時の遷移 | references/motion-haptics.md |
| 権限、センサー、バックグラウンド処理、オフライン同期、セキュアデータ、ネイティブモジュール、パフォーマンス重視の機能 | references/feasibility-risk.md |
| ナビゲーション、ディープリンク、タブ、スタック、ドロワー、モーダル | references/navigation.md |
| タブレット、折りたたみ式デバイス、ウィンドウのサイズ変更、外部入力、RTL、ローカライズ | references/adaptivity-localization.md |
| iOS 固有の規約 | references/platform-ios.md |
| Android 固有の規約 | references/platform-android.md |
| React Native のコンポーネント、リスト、画像、アーキテクチャ、状態管理 | references/react-native-implementation.md |
| 最終 QA またはデザインレビュー | references/review-checklists.md、references/review-rules.md |
| 情報源の検証 | references/source-map.md |
実装範囲
- React Native と Expo を、デフォルトのコード実装パスとして扱います。バージョン固有のコードを書く前に、インストール済みのプロジェクトと最新の公式ドキュメントを確認してください。
- SwiftUI、UIKit、Jetpack Compose、または Views のタスクでは、プラットフォーム固有の設計とレビューのガイダンスを提供してください。ネイティブプロジェクトとそのツールチェーンを確認してから、フレームワーク固有の実装を書いてください。
- プラットフォーム間の違いを意図的に明示してください。React Native の props や Expo のモジュールを SwiftUI や Compose の API として提示せず、対応するランタイムとフォールバックがない機能を実現できると約束しないでください。
デザインダイヤル
references/design-process.md は、ダイヤルの意味(段階の意味と対応表)を定義する正規の情報源です。以下の概要はその内容を反映しています。両者に食い違いがある場合は、design-process.md を優先してください。
デザインを把握した後にこれらを設定し、情報密度、動き、ビジュアル上のリスクに反映してください。
| ダイヤル | 一般的なデフォルト | 意味 |
|---|---|---|
DESIGN_VARIANCE | 6 | 1 = 標準的/プラットフォーム標準、10 = 非常に個性的 |
MOTION_INTENSITY | 4 | 1 = ほぼ静的、10 = 振り付けられたような/表現豊かな動き |
VISUAL_DENSITY | 4 | 1 = ゆとりがある、10 = 情報量の多い業務用 UI |
状況に応じて調整してください。銀行、ヘルスケア、エンタープライズ、安全性が重要なフローでは、通常、バリエーションと動きを抑える必要があります。ソーシャル、エンターテインメント、フィットネス、エディトリアルコマース、クリエイティブツールでは、使いやすさを損なわない範囲で、より個性を持たせることができます。
厳守事項
これらは好みの問題ではありません。
- タッチターゲット:iOS では少なくとも 44pt、Android では 48dp、または同等のヒット領域を確保してください。
- コントラスト:WCAG AA の最低基準を満たし、通常の本文テキストでは 4.5:1、大きなテキストと UI コンポーネントでは 3:1 を確保してください。
- セーフエリアとシステムインセットに対応してください。ノッチ、Dynamic Island、ホームインジケーター、Android のジェスチャーナビゲーション、キーボード、エッジツーエッジのレイアウトも対象です。
- 限定的かつ正当な例外がない限り、テキストはプラットフォームの文字サイズ拡大設定に従ってください。
- インタラクティブな要素には、アクセシブルな名前、ロール、状態、論理的なフォーカス順序が必要です。
- 重要な操作を行うジェスチャーには、目に見える代替手段を用意してください。
- レイアウトは、利用可能なウィンドウ、画面の向き、対応する入力方式に適応させてください。デバイス名だけを根拠にレイアウトを決めないでください。
- ローカライズされたアプリでは、対象言語で必要となる長い文字列、ロケールに応じた書式、RTL レイアウトに対応してください。
- 読み込み中、空、エラー、無効、押下中、成功の各状態はデザインの一部であり、任意の仕上げではありません。
- 認証トークンやシークレットを AsyncStorage に保存しないでください。プラットフォームに適したセキュアストレージを使用してください。
- 使用するスタックで対応している場合、動きは Reduce Motion/アニメーション時間に関するアクセシビリティ設定に従ってください。
バイアスの補正
汎用的で AI らしく見えるモバイル UI をデフォルトにしないでください。たとえば、中央揃えのウェブサイト風ヒーロー、装飾的なグラデーションのぼかし、紫と青の発光アクセント、入れ子になったカード、脈絡のないピル型要素、根拠のないグラスモーフィズム、汎用的なアバター、lorem ipsum のサムネイル、成功状態しかない静的な UI などです。
代わりに、プロダクトに基づいて判断してください。
- 主題、ユーザーの利用環境、プラットフォームの慣習を踏まえて、階層と素材を選んでください。
- 既存のデザインシステムに、より幅広いセマンティックパレットがない限り、規律あるブランドアクセントを 1 つ使用してください。
- ブランド表現やクロスプラットフォームの一貫性のためにカスタムフォントが必要な場合を除き、システムフォントを優先してください。
- 実際のコンテンツと現実的なデータ、意味のある画像を使用するか、アセットが不足していることを明示してください。
- カード、ぼかし、シャドウ、グラデーション、アニメーションは、階層、操作可能性、連続性、フィードバックを明確にする場合に限り使用してください。
出力に関する契約
デザインまたは実装のタスクでは、以下を含めます。
- デザインを読み取って選択したダイヤル。
- プラットフォームに関する前提と差異が生じるポイント。
- 必要に応じて、デザイントークンまたはローカルトークンの変更。
- 必要に応じて、画面構成またはフォームフローに関する判断。
- 対応するコンポーネントの状態。
- アクセシビリティとモーションに関する配慮。
- 必要に応じて、適応性、ローカライズ、入力方式に関する配慮。
- 事前確認が必要だった場合の実現可能性に関するリスク、代替策、検証計画。
- コードが関わる場合の実装対象と、意図的なプラットフォーム間の差異。
- UI のレビュー時における、5 秒で理解できるかどうかと、操作方法が明確かどうかの確認。
- 実施した検証、または検証できなかった内容。
レビューでは、重大度の高い問題から順に挙げ、可能であればファイル名と行番号を示します。実装では、可能な限り変更を加え、現在のリポジトリ内で検証します。