mcpField
U
ux-mobile-responsiveness-audit

ux-mobile-responsiveness-audit

github.com/uxcel-labデザイン・UI36116 回インストール17 週間前に更新
リポジトリ

ux-mobile-responsiveness-audit について

デザインやプロダクトチーム向けに、画面を生成せず、モバイルとタッチ操作への適応を評価するスキルです。7つの観点を確認し、原則、基準値、重大度、具体的な修正案を示します。

主な機能

  1. 01画面幅への適応とリフローの確認
  2. 02縦横画面での動作評価
  3. 03タッチ対象のサイズと間隔の確認
  4. 04親指の届きやすさと片手操作の評価
  5. 05モバイル入力とジェスチャーの確認
  6. 06指摘の優先順位付けと修正案

活用シーン

  1. 01リリース前のモバイル画面監査
  2. 02ブレークポイント間のレイアウト確認
  3. 03モバイルフォームの入力性評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/uxcel-lab/product-skills --skill ux-mobile-responsiveness-audit

インストール後、Claude Code で/ux-mobile-responsiveness-auditを入力して読み込まれたか確認します。

詳細

モバイルレスポンシブネス監査スキル

このスキルの動作(最初にお読みください)

これは評価型のスキルです — 既存の成果物をモバイル/タッチの標準に照らしてレビューするものであり、生成は行いません。指摘は安全であるため、自動実行され、対象がモバイルまたはレスポンシブである場合は常に、生成系スキルから検証ステップとして呼び出されるように作られています(コンポーネントファミリー、画面、フローは、それぞれのモバイルコンテキストのためにここへ引き継がれます)。

このリポジトリにおいてモバイル/タッチ適応の関心事を担います。兄弟となる監査との重複を避けるため、以下を委ねます:

  • WCAG の比率、スクリーンリーダー/支援技術、キーボード操作、代替テキスト、キャプション → アクセシビリティ監査。このスキルは物理的なタッチエルゴノミクスとレイアウト適応を判断するものであり、支援技術との互換性やコントラストの計算ではありません。
  • 視覚的構成 — 階層、余白の美しさ、強調 → 美的監査。
  • ユーザビリティ、フロー、インタラクションのロジック → ヒューリスティクス監査。
  • コンテンツ構造/ナビゲーションの仕組み → 情報アーキテクチャ監査、タイプスケール → ux-typography。

適用可否のゲート: この監査は、対象がモバイルまたはブレークポイントをまたいで動作することを意図している場合にのみ適用されます。設計が明示的にデスクトップ専用である場合(例: モバイル対応のない複雑な社内管理ツール)、その旨を述べてスキップしてください — モバイルに関する指摘を無理に作り出さないでください。

スコープの規律。 直接呼び出された場合(ユーザーがこの監査を指名した場合)、この関心事のみをレビューしてください — 兄弟監査を引き込まないでください。他の観点と並行して実行されるのは、オーケストレーター(ux-design-review)または生成系スキルが docs/orchestration-policy.md に基づいてこれを呼び出す場合のみであり、その場合は**ティア B — 提供(プラットフォームがモバイルの場合のみ)**に位置づけられます。明示的なスコープが常に優先されます。


このスキルがデフォルトの動作と比べて変えること

デフォルトでは、「モバイルフレンドリーですか?」という問いには曖昧な答え — 「ボタンをもっと大きくしましょう」「レスポンシブであるべきです」 — が返り、しきい値も深刻度も体系的な網羅もありません。このスキルは以下を強制します:

  1. すべての指摘が違反した原則を明示する(リフロー、タッチターゲットのサイズ、親指の到達範囲など)とともに、具体的なしきい値(44pt / 48dp、≥8dp の間隔、本文 ≥16px)を示します。
  2. 深刻度を評価する — デバイス上でタスクを妨げるのか、摩擦を追加するのか、磨き込みなのかによって。
  3. 具体的な修正案を示す — 「モバイル向けに最適化する」ではありません。
  4. 7 つの領域すべてを体系的に網羅することで、「タップターゲットが小さい」以外の問題 — 画面の向きの固定、誤ったキーボードタイプ、ジェスチャーの行き止まり、リフローしないレイアウト — が実際に捕捉されます。

フレームワーク — 何を確認し、違反がどのようなものか

それぞれを順に確認してください。原則、深刻度、修正案を付けて指摘します。

1. ビューポートの適応とリフロー

レイアウトはビューポートに適応する必要があります — 流動的なグリッド、柔軟な画像、リフローして再構成されるコンテンツ — 固定幅のデスクトップレイアウトを小さな画面に押し込むのではありません。(レスポンシブ = ブレークポイントを伴う単一の流動的レイアウト、アダプティブ = ブレークポイントごとに異なるレイアウト。どちらでも構いません。適応しないことが失敗です。)

指摘すべき場合: 横スクロールが発生する、または端でコンテンツが切れる場合。縮まない固定幅(px)のコンテナ。縮小表示された小さなデスクトップレイアウト。一般的なブレークポイント間で要素が重なったり衝突したりする場合。比例してサイズ変更されない画像。狭い画面でも縦に積み重ねず複数列レイアウトを維持している場合。

  • ❌ 390px のスマートフォン上に 1200px のコンテンツフレーム → 読むにはユーザーがピンチズームして横にスクロールしなければならない。
  • ✅ コンテンツが単一の流動的な列にリフローし、画像が拡大縮小し、ビューポート幅を超えるものがない。
2. 画面の向きへの耐性

ユーザーはデバイスを縦向きでも横向きでも持ちます。必須機能は縦向き と 横向きの両方で動作しなければならず、画面の向きの変更は意図的なものであるべきで、動作を壊してはいけません。

問題とすべきケース: 回転させたときにレイアウトが崩れる、見切れる、または無駄な余白ができる。実際の理由もなく主要機能が一方の向きに固定されている。横向きのほうが適しているのに、キーボードを多用する画面や動画画面が縦向きに強制されている。タスクを妨げる場面で自動回転が発動する。

  • ❌ 横向きに回転すると、スクロールできない折り返し位置より下に送信ボタンが隠れてしまう。
  • ✅ 縦向きを基本デザインとし、横向きではリフローしてすべての必須アクションに到達できるようにする。
3. タッチターゲットのサイズと間隔

指や親指は不正確です。ターゲットは確実にタップできるよう十分に大きく、十分に間隔を空ける必要があります。特に隣り合う矛盾するアクション(保存と削除など)では重要です。

問題とすべきケース: インタラクティブなターゲットがプラットフォームの最小値を下回っている — iOS 44×44pt、Material 48×48dp(WCAG の下限は 24px ですが、実務上の目標はプラットフォームの最小値です)。タップ可能な要素間の間隔が 約 8dp/16px 未満。隅のターゲットが中央のものと同じサイズ(隅はタップしにくいため、中央の約 7mm に対して約 12mm と大きめを目指す)。破壊的なアクションと確認アクションが小さく、かつ隣り合っている。

  • ❌ 間隔 2px の 28px アイコンボタン列。「削除」が「保存」にぴったり接している。
  • ✅ 44pt/48dp 以上のターゲット、8dp 以上の間隔、隅や矛盾するアクションには追加のサイズ。
4. 親指での到達性と片手操作

人はスマートフォンを片手で操作し、画面中央を好みます。手がインターフェースを覆い、握り方も絶えず変わります。

問題とすべきケース: 主要なアクションが到達しにくい上部の隅に置かれている。破壊的なアクションが親指の届きやすいゾーンにあり、誤ってタップされる。重要なコンテンツが上端に詰め込まれている。下部の余白がないためコンテンツを快適な中央までスクロールできない。ボタンが右端のみに配置されている。

  • ❌ メインの CTA が右上に固定され、「アカウント削除」ボタンが親指の快適ゾーンである下部中央にある。
  • ✅ 主要なアクションは親指の届く範囲(下部中央/ボトムシート)に配置し、破壊的なアクションは保護するか誤タップゾーンから外し、コンテンツは中央までスクロールできるようにする。
5. モバイル入力の人間工学

モバイルでの文字入力は遅く、ミスが起きやすい(約 41% が両手親指で入力)。入力方式をデータに合わせ、手入力を最小限にします。

問題とすべきケース: 文脈に合ったキーボードが適しているのに汎用キーボードを使っている(電話番号/PIN にテンキーがない、メールに「@」最適化キーボードがない、Web アドレスに URL キーボードがない)。氏名、住所、メール、支払いの自動入力/オートコンプリートがない。選択コントロール(ピッカー、ラジオボタン、トグル)で済むところを自由入力欄にしている。長いフォームが複数ステップに分割されていない。利用可能な場面で OTP の自動入力やカードスキャンがない。

  • ❌ 電話番号欄でフル QWERTY キーボードが開く。住所を自動入力なしで一から入力する。
  • ✅ 数字にはテンキー、メールにはメール用キーボードを使用し、自動入力と選択コントロールで入力を減らす。
6. ジェスチャーの安全性と発見可能性

ジェスチャーは目に見えず、発見可能性、一貫性、アクセシビリティの面で限界があります。ジェスチャーはアクションを補助するものであり、単独で担うべきではありません。

問題とすべきケース: 重要なアクションに、目に見えるコントロールなしで隠れたジェスチャー(エッジスワイプのメニュー、長押し)でしか到達できない。非標準のジェスチャーがシステムの慣例を再定義している。複雑なマルチフィンガージェスチャーが必須になっている(運動機能や器用さに制限のあるユーザーを排除してしまう)。ターゲット内でのタッチ終了時ではなくタッチ開始時に発動する(誤作動)。

  • ❌ 項目を削除する唯一の方法が、発見しにくい左スワイプで、ボタンの代替手段がない。
  • ✅ スワイプは目に見えるコントロールと併せてショートカットとして提供し、単純で慣例的なジェスチャーのみを必須とする。
7. モバイルでの可読性とコンテンツの優先順位

屋外や移動中に使われる小さな画面では、読みやすいテキストと、ファーストビューの容赦ない優先順位付けが求められます。デスクトップ版をただ縮小するのではなく、モバイル向けにコンテンツを適応させてください。

指摘すべきケース: 本文テキストが 16px 未満。モバイルでの 1 行の文字数が約 30~40 文字の範囲外。小さなサイズで表示されるディスプレイ書体。主要タスクを先頭に持ってくるのではなく、すべてを表示しようとしている画面。二次・三次機能がファーストビューにひしめき、スクロール下部やメニューの背後に置かれていない。モバイル版がデスクトップ版とは別製品のように感じられる (パターン、色、コントロールの不整合)。

  • ❌ 12px の本文テキスト、ファーストビューにひしめく 4 つの競合する CTA、デスクトップ専用の配色。
  • ✅ 16px 以上の本文、最初に明確な主要アクションが 1 つ、二次アクションは後回し、デスクトップ製品との一貫性。

トレードオフの注記: モバイルはより少なく、より大きくという方向 (タッチターゲット、文字、主要アクション 1 つ) を求めますが、プロダクトオーナーはより多くを表に出そうとします。解決の方向はデバイスの現実 — 限られたスペースと不正確なタッチ — に合わせ、追加の情報密度は詰め込むのではなく段階的開示に委ねてください。修正がアクセシビリティ監査 (例: ターゲットサイズ、ジェスチャーの代替手段) と衝突する場合は、一度だけ言及し、AT/WCAG の枠組みはアクセシビリティ側に委ねてください。


重大度の評価

重大度意味
Critical対象デバイスで使用不能 — コンテンツが見切れる/横スクロールが発生する、ターゲットが小さすぎて確実にタップできない、重要なアクションが発見困難なジェスチャーでしか行えない、またはコア機能が出荷時に利用できない画面の向きに固定されている。出荷前に修正。
Majorユーザーが負うべきではない大きな摩擦 — ターゲットがプラットフォームの最小値未満だがタップは可能、主要アクションが親指の届く範囲外、キーボードの種類が不適切、本文テキストが 16px 未満、一般的なブレークポイントでレイアウトがうまく再配置されない。
Minor気づく程度の仕上げ — やや詰まった余白、理想的でない横向きレイアウト、軽度の過密、隅のターゲットが拡大されていない。

評価は、修正のしやすさではなく、実際のデバイスでタスクを完了する上での影響で行ってください。たとえ 1 行のキーボード種類の変更でも、素早い入力が妨げられるなら Major になりえます。


監査の出力形式

## Mobile Responsiveness Audit — [Screen / Component]
Context: [device class / breakpoints · orientation · primary task, if known]

### Critical
- [Issue] — what's wrong → fix. (Principle: …)
### Major
- …
### Minor
- …
### Working well ✓
- …

**Top 3 priorities:** the highest-impact fixes for the target device.

最後に優先順位付けされたトップ 3 を添えてください。呼び出し元のジェネレーターがこれに基づいて動作します。


優れた監査の進め方

  1. コンテキストを確定する — デバイスクラス (スマートフォン/タブレット/レスポンシブ Web)、対象のブレークポイント、想定される画面の向き、画面の主要タスク。タッチの人間工学は、デバイスと最も重要なアクションに対してのみ判断できます。
  2. 適用可否を確認する — 本当にデスクトップ専用である場合は、無理に指摘を作らずスキップしてください。
  3. 7 つの領域をすべて確認する — 既定のレビューに対する価値は網羅性にあります。タッチターゲットのサイズだけで止めないでください。
  4. しきい値を使う — 44pt/48dp のターゲット、8dp 以上の間隔、16px 以上の本文、約 30~40 文字の 1 行 — これにより指摘は雰囲気ではなく検証可能になります。
  5. 委ねる — コントラスト/AT/キーボードはアクセシビリティに、構成は美的感覚に、フローはヒューリスティクスに委ね、ここで再導出しないでください。
  6. 列挙ではなく優先順位付けする — デバイス上でタスクが妨げられるかどうかで評価してください。

よくある do/don't パターン

❌ しない✅ する
「レスポンシブにして」/「ボタンが小さすぎる」原則 + しきい値 (44pt/48dp、≥16px) + 修正内容を明示する
あらゆる些細な指摘を同等に扱うデバイス上でタスクを妨げるかどうかで評価し、上位 3 件を提示する
デスクトップのレイアウトをそのままスマートフォンに縮小する流動的な単一カラムにリフローする。ビューポート幅を超えるものはない
主要機能を特定の画面の向きに固定する必須の操作は縦向き および 横向きの両方で機能する
2px の間隔で 28px のターゲット≥44pt/48dp のターゲット、≥8dp の間隔、角を大きくする
主要 CTA が上部コーナー、削除が親指ゾーン主要操作は親指の届く範囲に、破壊的操作は保護する / 簡単に届かない位置に
電話番号フィールドにフル QWERTY状況に応じたキーボード、自動入力、入力より選択
操作への唯一の経路をスワイプの背後に隠すジェスチャーは可視コントロールを補完するものであり、決して置き換えない
WCAG コントラストやスクリーンリーダーの問題を再導出するアクセシビリティ監査に委ねる
タップターゲットのサイズのみを報告する7 つの領域すべてを網羅し、原則としきい値を引用する

出典元のレッスン (Uxcel)

コメント