thumb-first-design

Thumb-First · Design

モバイルのデザイン判断 — モバイルに適したパターンが「何か」と「なぜそうなのか」を扱い、コーディング方法は扱いません。実装が CSS、SwiftUI、React Native のどれであっても、判断は変わりません。これは Thumb-First スイートのデザイン判断レイヤーです。

クイックスタート

機能のモバイルデザインを計画する： /thumb-first-design plan または「これのモバイル UX を設計して」「モバイルではどのように動作させるべき？」 既存のモバイルデザインを監査する： /thumb-first-design audit または「このモバイル画面をレビューして」「これは優れたモバイルデザイン？」

このスキルはパターンと使いやすさを判断します。実装コードは作成しません。レスポンシブ CSS には responsive-craft を使用してください。モバイルウェブ／PWA の技術的な問題（セーフエリア、ビューポート、サービスワーカー）には、兄弟スキルの thumb-first-platform を使用してください。React Native／Expo には、ネイティブモバイルのスキルを使用してください。この判断監査とプラットフォーム監査をまとめて実行し、1 つのレポートに統合するには、/thumb-first を実行してください。

---

基本原則

これらは長く受け継がれる原則であり、この分野を切り開いた人々の知見を統合したものです。デバイスの世代交代やプラットフォームの変化を経ても通用します。

1. 最も制約の多い持ち方を基準にデザインする (Hoober) — タスクに合わせて、持ち方は数秒ごとに変わります。「49% が片手で使う」というよく引用される数字は、操作しやすい範囲にコントロールを埋め込んでよいという許可ではありません。ユーザーが取りうる最も操作しにくい持ち方にも対応し、どのようにデバイスを持ってもインターフェースが機能するようにします。実践例： コントロール、ナビゲーション、主要なアクションといった操作領域は下部の帯に配置します。コンテンツは上部まで広げてもかまいませんが、操作要素は置かないでください。

2. 親指の可動域はレイアウトグリッドではなく、コストマップ (Hurff) — Natural／Stretch／「Ow」は、場所の「コスト」を示すものであり、要素の配置場所を指示するものではありません。コストの高い領域は、頻度の低い操作や破壊的な操作に適しています。画面サイズが大きくなるほど、操作に必要な負担は非線形に増加します。デバイスのクラスごとにマップを作り直してください。

3. モバイルではフォーカスが求められる (Wroblewski) — 小さな画面は特徴です。「この画面を割く価値が本当にあるものは何か」という問いを突きつけるからです。レイアウトを決める前に、何を削り、何を優先するのかを決めてください。優先順位付けこそがデザインの仕事です。

4. コンテンツそのものをコントロールにする (Clark) — コンテンツを囲む操作部品よりも、コンテンツを直接操作する方法を優先します。ただし、目に見える手がかりのないジェスチャーは、熟練者しか気づけない機能になります。ジェスチャーの利便性と発見しやすさはトレードオフであり、その緊張関係が完全に解消されることはありません。

5. モーションは装飾ではなく、コミュニケーション (Modern Craft) — トランジションは状態、階層、因果関係を伝えます。モーションはレイアウトとともに設計し、最後の仕上げとして追加しないでください。何がどこから来て、どこへ移動するかも情報です。

6. ナビゲーションのクロームは現在、方向性が定まっていない — iOS 26（Liquid Glass、フローティングタブバー）と Material 3 Expressive（ナビゲーションドロワーの非推奨化）は、移行の途上にあります。プラットフォームのナビゲーションは変化の最中にあるものとして扱い、変化し続けるものを確定した標準として提示せず、注意点として示してください。

7. 選択肢が分かれる判断は明示し、黙って既定値を選ばない — モバイルデザインの選択に複数の妥当な答えがある場合（ナビゲーションのパターン、シートかモーダルか、ジェスチャーか目に見えるコントロールか）、トレードオフとともに 2〜3 個の選択肢を示し、ユーザーに選んでもらいます。references/design-forks.md を参照してください。

---

デザイナーレンズ

このスキルでは、単一のチェックリストにまとめるのではなく、名前の付いた8つのレンズを通して検討します。それぞれ、明確で本人に帰属する見解を持つ、実在の実務家です。重み付けは状況に応じて変わります。最も重視するレンズは、何を設計するかによって異なります。

レンズ	見解の発信者	次のような作業で主導する…
人間工学の現実主義者	Steven Hoober	手の届きやすさ、操作の配置、グリップに関する前提
親指ゾーンのマッパー	Scott Hurff	レイアウトのコスト、大画面でのトレードオフ
焦点を絞る人	Luke Wroblewski	コンテンツの優先順位付け、フォーム
直接操作	Josh Clark	タッチモデル、ジェスチャーとコントロールの使い分け、見つけやすさ
ナビゲーションの分類学者	Frank Rausch	ナビゲーション構造、モーダル、ドロワー、シート
実証主義の懐疑者	Raluca Budiu / NN/g	スキャン、オーバーレイ、通説や前提の検証
現代的なクラフト	Allen / de With / Nelson	モーションと操作感、ネイティブアプリ級の作り込み、複雑なアプリの情報密度
プラットフォームの規範	Apple HIG / Material 3	現行の慣習、システムが予約しているジェスチャー

各レンズの詳しい見解、レンズ間の意見の相違、重み付けの表はreferences/designer-lenses.mdにあります。どちらのモードでも、開始時に読み込んでください。

---

モードの選択

モードは2つあります。$ARGUMENTSから判定するか、質問してください。

判定

• $ARGUMENTSに「audit」、「review」、「critique」、「evaluate」、「feedback」が含まれている → 監査
• $ARGUMENTSに「plan」、「design」、「build」、「new」、「how should」が含まれている → 計画
• ユーザーが既存の画面、コンポーネント、アプリを示して評価を求めている → 監査
• ユーザーが新しいモバイル機能に着手する、またはどのように動作させるべきか分からない → 計画
• 判断が曖昧 → 質問してください。

AskUserQuestionが利用できる場合：

• 計画 — コードを書く前に、機能のモバイルUXを設計する
• 監査 — 既存のモバイルデザインをベストプラクティスに照らしてレビューする

それ以外の場合：「（1）新機能のモバイルデザインを計画する、または（2）既存のモバイルデザインを監査する、のどちらをご希望ですか？」

ユーザーが「監査」を選んだものの、レビュー対象を提供していない場合は、ワークフローを振り分ける前に、スクリーンショット、ライブURL、コード、説明のどれをレビューするのか尋ねてください。監査ワークフローはこれらのいずれからでも実施できますが、対象が1つ必要です。

---

振り分け

モード	読み込むワークフロー	直ちに読み込むもの
計画	workflows/plan.md	references/designer-lenses.md
監査	workflows/audit.md	references/designer-lenses.md

その他のリファレンスは必要に応じて読み込みます。

• references/reach-and-ergonomics.md — 操作の配置、親指の届きやすさ、片手操作、大画面
• references/navigation.md — ナビゲーションパターンの選択。タブバー、ドロワー、ボトムシート、モーダル
• references/forms-and-input.md — フォームフィールドやデータ入力がある画面
• references/touch-gesture-motion.md — ジェスチャー、タッチターゲット、トランジション、触覚フィードバック、操作感
• references/content-and-attention.md — コンテンツの優先順位付け、スキャン、一覧性、オーバーレイ
• references/design-forks.md — 複数の選択肢に妥当性がある場合
• references/output-format.md — 監査結果の提示（デフォルトはHTMLレポート。references/report-template.htmlに合わせて調整）

落とし穴 — Claude がモバイルデザインで失敗する点

モバイルデザインの失敗は、コードではなく判断の失敗です。すべての提案をこのリストに照らして確認してください。

1. 「すっきり見える」という理由でハンバーガーメニューをデフォルトにする — 非表示のナビゲーションは見つけにくくなります。タブバーは遷移先を表示でき、常にこちらのほうが優れています。ハンバーガーメニューは、ナビゲーションが本当に深い場合の最後の手段であり、デフォルトではありません。

2. 画面上部に主要な操作を配置する — これはデスクトップの習慣です。現代のスマートフォンでは、画面上部は親指が最も届きにくい領域です。主要な操作や頻繁に使う操作は、手が届きやすい下部の領域に配置します。

3. 平均的な持ち方を想定してデザインする — 平均的な持ち方などありません。片手で快適に操作できることだけを考えてデザインすると、いつでも両手で支えたり操作したりしている約51％の人に不便を強いることになります。最も制約の大きい持ち方に対応してください。

4. ボトムシートをナビゲーション先として扱う — シートは、背後の画面が引き続き関連する、一時的で範囲の限られたタスクに使います。ページではありません。フローを作るためにシートを重ねることは、絶対に避けてください。

5. 視覚的な手がかりのないジェスチャーを追加する — 誰にも気づかれないスワイプ操作は、熟練者だけが使える機能です。すべてのジェスチャーには、広く知られた慣習に基づくか、視覚的な手がかりを設ける必要があります。できればジェスチャーを使わない代替手段も用意してください。

6. 複数列のフォームや、ラベルの代わりのプレースホルダー — モバイルフォームは常に1列にします。フォーカス時に消えるプレースホルダーでは、ユーザーがラベルを最も必要とするタイミングでラベルがなくなります。ラベルは常に表示します。

7. 動きを最終的な仕上げとして扱う — レイアウトを決めた後に付け足した動きでは、要素がどこから来たのかを伝えられません。レイアウトと同時に画面遷移を決めてください。画面遷移は状態と因果関係を伝えます。

8. デスクトップの情報密度をモバイルに持ち込む — デスクトップ画面の内容をスマートフォンに詰め込むのは、モバイルデザインではありません。モバイルでは、何を優先し、何を後回しにし、何を削るかを決める必要があります。

9. 対象を明確にしないまま「モバイル」向けにデザインする — 「モバイル向け」のデザインを依頼されると、Claude は iOS のパターン（戻るスワイプ、シートの表示位置、トップバーの操作など）を暗黙にデフォルトとしますが、これらは Android には当てはまりません。プラットフォームが明示されていない場合は、前提を明示し、iOS と Android の違いを指摘してください。また、iOS 26 と Material 3 のどちらも移行の途中である点を記し、どちらも確立済みのものとして扱わないでください。

10. 見せるための画面だけを最適化する — マーケティング用の画像では見栄えのよいデザインでも、片手での操作中、キーボードを開いているとき、中断されている最中、あるいは再訪ユーザーにはうまく機能しない場合があります。現実の、注意がそれやすく、画面をちらっと見る状況に合わせてデザインしてください。

それぞれの理由と、失敗を見抜く視点については、references/designer-lenses.md と各トピックのリファレンスを参照してください。

---

リファレンス一覧

ファイル	内容	読み込むタイミング
designer-lenses.md	8つのレンズ — 立場、意見の相違、状況に応じた重み付けの表	どちらのモードでも開始時
reach-and-ergonomics.md	持ち方のデータ、親指の可動範囲、アクションの配置、大画面での操作範囲	アクションを配置するとき、または操作範囲を評価するとき
navigation.md	Rauschのナビゲーション分類、タブ／ドロワー／シート／モーダルの判断、iOS 26 + Material 3の状態	ナビゲーションを選択またはレビューするとき
forms-and-input.md	Wroblewskiのフォーム原則、入力タイプ、フィールドの削減、キーボード	データ入力画面全般
touch-gesture-motion.md	タッチターゲット、ジェスチャーの発見しやすさ、コミュニケーションとしてのモーション、触覚フィードバック	ジェスチャー、トランジション、または操作感を扱うとき
content-and-attention.md	優先順位付け、スキャンのパターン、一目でわかるデザイン、オーバーレイの増えすぎ	コンテンツのレイアウトと階層
design-forks.md	選択肢とトレードオフを伴う、判断の分かれるモバイルデザイン上の選択	唯一の正解がない選択肢があるとき
output-format.md	監査結果の提示方法 — HTMLレポート（デフォルト）とターミナルでの代替表示、色／図／セクションのルール	監査結果を提示するとき（ステップ5）
report-template.html	標準の自己完結型HTML監査レポート（作成例）— 作り直さずに調整して使用	HTMLレポートを作成するとき

ワークフロー一覧

ワークフロー	目的
plan.md	調査 → 優先順位付け → パターンの選択 → モバイルデザインの概要
audit.md	レンズに基づく評価 → 判断の分かれる選択肢の提示 → 優先順位付けされた指摘事項