web-design-guidelines

Web Design Guidelines

このスキルは、**「このインターフェース全体の質はどの程度で、何が操作の妨げになっており、何を最初に修正すべきか？」**という質問に使います。

これは、このリポジトリにおける幅広いインターフェース監査／デザインレビューの中心となる指針です。 ベンダーのルールを取得するだけのものではなく、隣接する専門スキルの代わりでもありません。

幅広いページやフローをレビューする前に、references/review-modes-and-categories.mdを読んでください。 作業がこのスキル、web-accessibility、responsive-design、ui-component-patterns、design-system、react-best-practicesのどれに当てはまるか判断する際は、references/handoff-boundaries.mdを読んでください。 最終的なレビューパケットを作成する前に、references/ui-audit-packet-template.mdを読んでください。

このスキルを使う場面

• ランディングページ、ダッシュボード、サインアップフロー、設定ページ、マーケティングサイトのインターフェース全体の質をレビューする
• 「UIをレビューして」「UXを監査して」という依頼を、散発的な意見ではなく体系的な監査にまとめる
• 情報の階層、明瞭さ、余白、一貫性、コンポーネントの状態の質、CTAの強調、タスクの妨げとなる要因を総合的に評価する
• 画面やフローが実装、リリース、関係者レビューに進める状態か確認する
• 幅広いインターフェースのヒューリスティックや実践的な実装ガイドラインに照らしてページを評価する
• 複数の観点から得られた所見を、担当範囲の引き継ぎ先を明記した優先順位付きのUI監査パケットにまとめる

このスキルを使わない場面

• 主な作業が、アクセシビリティの修正、キーボード／フォーカスの動作、ラベル、セマンティックHTML、またはWCAGの手動・自動検証である → web-accessibilityを使う
• 主な作業が、ビューポートへの適応、はみ出し、ブレークポイント戦略、またはコンテナーを考慮したレイアウトの挙動である → responsive-designを使う
• 主な作業が、再利用可能なプリミティブ／スロット／バリアントのAPI設計、または制御コンポーネントと非制御コンポーネントのアーキテクチャである → ui-component-patternsを使う
• 主な作業が、システムレベルのトークン管理、ビジュアルランゲージ、またはコンポーネントライブラリの基盤である → design-systemを使う
• 主な作業が、Reactのレンダリング、ハイドレーション、状態変化の頻度、バンドル／ランタイムの動作、またはパフォーマンスのデバッグである → react-best-practicesまたはperformance-optimizationを使う
• デザイン上の判断を加えず、自動ツールの出力を貼り付けるだけの作業である → ツールを直接実行してからここに戻り、結果を解釈して優先順位を付ける

基本的な考え方

幅広いUIレビューは、次の手順で進めると効果的です。

1. レビュー対象を定義する
2. 所見を安定したカテゴリーに分類する
3. インターフェース全般の問題と、専門分野で対処すべき問題を分ける
4. ユーザーの操作の妨げとなる度合いとリリースのリスクに基づいて優先順位を付ける
5. 簡潔な監査パケットを1つ作成する

チェックリスト、リンター、またはベンダーのガイドラインだけですべてに答えられるかのように扱わないでください。 ルールの情報源やヒューリスティックを材料として使い、そのうえで判断してください。

手順

ステップ1：レビュー対象を設定する

UIを評価する前に、どの種類の画面やフローをレビューするのか特定してください。

次のいずれか、または複数に分類します。

• マーケティング／ランディングページ — ストーリーの階層、CTAの強調、読み取りやすさ、信頼性の裏付け、視覚的な信頼感
• アプリケーション画面／ダッシュボード — 情報密度、タスクフロー、状態、ナビゲーションの明瞭さ、復旧のしやすさ
• フォーム／オンボーディング／チェックアウトフロー — フィールドの明瞭さ、順序、エラー防止、進捗のフィードバック、確認
• 設定／管理／CRUD画面 — ラベル、破壊的操作の明瞭さ、デフォルト値、成功／エラーのフィードバック、テーブル／フィルターの複雑さ
• コンポーネント群 — 繰り返し使用されるコントロール全体での一貫性と状態の挙動。ただし、コンポーネントAPI全体の設計は対象外です

簡単な設定：

Review surface:
- Type: application screen + multi-step form
- Primary job: create a new workspace
- Main user risk: hidden next step, weak error recovery, inconsistent button hierarchy

依頼が多くのページにまたがる場合は、まず代表的なフロー、または優先度の高い画面を選んでください。

ステップ 2：レビュー方法を選ぶ

レビューの範囲を絞るため、主な方法を 1 つ選びます。

方法：

• リリース準備状況の監査 — リリース前の幅広いレビュー。重大度と修正の優先順位を示します
• 仕上げ／一貫性の監査 — 余白、階層、コピーの強調、コンポーネント／状態の一貫性を確認します
• フローの摩擦に関する監査 — タスク完了の障害、手順の曖昧さ、エラー処理、行き止まりを確認します
• ヒューリスティック監査 — 視認性、明瞭さ、コントロール、一貫性、復旧など、幅広い操作性のヒューリスティックに照らして評価します
• ルールを重ねた監査 — Vercel Web Interface Guidelines などの外部チェックリストや情報源を、幅広い監査に重ねて適用します

推奨される既定値：

Primary mode: launch-readiness audit
Secondary lens: rule-overlay using Vercel Web Interface Guidelines

ステップ 3：安定したカテゴリーごとにレビューする

ランダムな意見を並べないでください。指摘事項をカテゴリーごとにまとめます。

次のカテゴリーを使います：

• 階層と一覧性 — 視覚的な優先順位、セクションの順序、余白、グループ分け、見出し／CTA の強調
• 明瞭さと言葉遣い — ラベル、CTA の文言、補助テキスト、エラーテキスト、専門用語、次のステップの分かりやすさ
• 一貫性とコンポーネントの動作 — 繰り返し使われるパターン、ボタンのスタイル、アイコンの使い方、フィールドの扱い、ホバー／フォーカス／無効／読み込み中の状態
• 操作フィードバックと復旧 — 成功／エラー／読み込み中の状態、空の状態、確認、取り消し／キャンセル、進行状況の視認性
• ナビゲーションと現在地の把握 — 方角の把握、セクションラベル、パンくずリスト／タブ、現在地の認識、終了経路
• レスポンシブ対応の基本 — モバイルでの読みやすさ、タッチターゲットの妥当性、はみ出し、積み重ね、密度の変化
• アクセシビリティの基本 — コントラストの妥当性、視認できるフォーカス、セマンティック構造、キーボード操作の到達性、色だけに意味を持たせないこと
• パフォーマンスと信頼の手がかり — ファーストビューのメディアの遅延、ぎこちない操作、レイアウトのずれ、重いアセット、一貫性のない読み込み動作

重要な問題がないカテゴリーは、無理に指摘を作らず、その旨を簡潔に述べます。

ステップ 4：問題をこのレビューで扱うか、専門分野に回すかを判断する

このスキルが担当するのは幅広いインターフェース監査であり、あらゆる専門的な修正ではありません。

よくある振り分け先：

• アクセシビリティのみ、またはアクセシビリティを中心とする修正 → web-accessibility
• ビューポート／コンテナへの適応とレイアウトのはみ出し → responsive-design
• 再利用可能なコンポーネントやプリミティブの API の再設計 → ui-component-patterns
• トークンシステム／ライブラリ全体のデザインガバナンス → design-system
• React コードでのレンダリング／実行時／パフォーマンスのデバッグ → react-best-practices または performance-optimization

次のルールを使います：

• 診断と優先順位付けはここで行います。
• 1 つの専門分野が明らかに中心となる場合は、専門的な修正計画を別の担当に振り分けます。

例：

Finding: icon-only buttons are inconsistent and two lack accessible names.
- Keep here: note inconsistency and review impact
- Route out: accessibility remediation details to `web-accessibility`

ステップ 5：外部ルールの情報源は手法全体ではなく、追加の基準として使う

外部のルールを使うことはできますが、追加の基準としてのみ使います。

有用な追加基準：

• Vercel Web Interface Guidelines — アクセシビリティ、フォーカス、フォーム、モーション、パフォーマンス、レスポンシブ動作に関する実用的なウェブ実装チェック
• ユーザビリティのヒューリスティック — 視認性、ユーザーの言葉との一致、コントロール、一貫性、エラー防止、復旧
• ツールの出力 — Lighthouse、axe、デザインリンター、ビジュアルリグレッションのメモ、提供されている場合は分析データ／ヒートマップ

「ルールファイルを取得したので監査は完了です」とは言わないでください。 代わりに、次のように述べます：

Overlay evidence:
- Vercel guideline overlap: focus visibility, form semantics, state clarity
- Heuristic overlap: consistency, error prevention, user control
- Tool overlap: contrast and performance warnings

ステップ 6：カテゴリーの数ではなく、摩擦の大きさで優先順位を決める

ユーザーへの影響に見合った重大度を使います。

推奨される尺度：

• 重大 — タスクの完了を妨げる、ユーザーが離脱する可能性が高い、または強い不信感を生む
• 高 — 主要なフローで混乱、繰り返しのミス、フィードバックの欠如を招く
• 中 — 明瞭さ、一貫性、効率を損なうが、フロー全体を完全に妨げるわけではない
• 低 — 仕上げ上の問題、小さな不一致、まとめて対処する価値のある整理

必要に応じて、修正工数も示します：

• 工数小／効果大
• 工数中／効果大
• 大規模な再設計／構造的なフォローアップ

ステップ 7：簡潔な監査レポートを作成する

出力は、意見を述べるだけでなく、次の行動に役立つ内容にしてください。

推奨形式：

# UI Audit Packet

## Surface
- Screen/flow:
- Review mode:
- Primary user job:

## Top findings
1. [Severity] ...
2. [Severity] ...
3. [Severity] ...

## Findings by category
### Hierarchy and scanability
- ...

### Clarity and language
- ...

### Consistency and states
- ...

## Recommended next moves
- Quick wins:
- Follow-up redesigns:
- Route-outs:

## Route-outs
- `web-accessibility`: ...
- `responsive-design`: ...

ユーザーが簡潔なレビューコメントを求めている場合は、カテゴリを維持しつつ、各箇条書きを短くまとめてください。

例

例 1：幅広いローンチ準備状況のレビュー

入力：「ローンチ前にこの登録フローをレビューしてください。情報の優先順位、CTA、状態、モバイル、アクセシビリティの基本を確認したいです。」

望ましい回答の形：

• 対象をオンボーディング／フォームフローに分類する
• ローンチ準備状況の監査を主なモードとして選ぶ
• 指摘事項を、情報の優先順位、明確さ、状態、レスポンシブ対応の基本、アクセシビリティの基本に分類する
• 最優先の阻害要因を示す
• キーボード／フォーカスの修正が専門的なフォローアップになった場合に限り、web-accessibility に引き継ぐ

例 2：他の担当領域への引き継ぎを含む品質向上レビュー

入力：「一貫性の観点から、このダッシュボード UI を監査してください。ボタン、バッジ、読み込み状態、モバイルレイアウトにばらつきがあるようです。」

望ましい回答の形：

• 品質向上／一貫性の監査を選ぶ
• コンポーネント／状態の不整合はこのスキルの範囲内に保つ
• 繰り返し発生するモバイルのはみ出しの問題は responsive-design に引き継ぐ
• タスクをデザインシステム全体の作り直しに広げない

ステップ 8：最終回答で担当範囲を明確にする

幅広いレビューは、担当範囲の重複を防ぐ一文で締めくくってください。

例：

• 「このレポートではインターフェース全般の品質を扱っています。キーボード／フォーカスの詳細な修正は web-accessibility に引き継いでください。」
• 「主なレスポンシブ表示のはみ出しはここで特定しましたが、レイアウトの適応計画は responsive-design の担当です。」
• 「コンポーネントの不整合はここで指摘しました。再利用可能なプリミティブ／API の再設計は ui-component-patterns の担当です。」

出力チェックリスト

完了する前に、以下が含まれていることを確認してください。

• レビュー対象
• 選択したレビューのモード
• カテゴリ別の指摘事項
• 優先順位
• 必要に応じた、他の担当領域への明確な引き継ぎ
• 散在する所見ではなく、簡潔な監査レポート

ベストプラクティス

1. 無作為な見た目の細部ではなく、ユーザーのタスクやページの目的から始める。
2. 指摘事項をカテゴリ別に整理し、引き継ぎやすくする。
3. アクセシビリティとレスポンシブ対応は幅広いレビューの一環として扱う。ただし、専門的な修正が中心になる場合は、担当外として引き継ぐ。
4. 弱い箇条書きを 25 個並べるより、重要な指摘を 5 個挙げる。
5. 外部のルールセットは判断の代わりではなく、補助的な基準として使う。
6. すぐに対応できる改善と、構造的な再設計のフォローアップを区別する。
7. ローンチリスクとユーザーの負担を具体的に表現する。

参考資料

• Vercel Web Interface Guidelines
• NN/G: 10 Usability Heuristics for User Interface Design
• W3C WAI: Web Accessibility Evaluation Tools List
• Roast My Web: UI Audit Checklist: Template + Report Outline