frontend-design-audit

フロントエンドデザイン監査

確立されたユーザビリティ原則に基づいて、フロントエンドのインターフェースを監査し、改善します。

このスキルでできること

シニア UX デザイナーとしてインターフェースを最初から最後までレビューし、包括的なデザイン監査を行います。既存のコードを15の確立されたデザイン原則に照らして調査し、コンポーネントレベルとシステムレベルの両方で問題を特定して、重大度を評価し、具体的な修正方法を提示します。

これは表面的なリンティングや簡易的なアクセシビリティチェックではありません。個々のコンポーネントの問題、ページ間の一貫性、デザインシステムの整合性、インタラクションパターン、情報アーキテクチャ、そしてユーザーの利用体験全体を評価します。すべての指摘には、具体的なユーザビリティ原則を示します。重大度はすべて、標準化された0〜4の尺度に基づいて評価します。すべての推奨事項は、実行可能で、コードに即した具体的なものにします。

---

対象ユーザー

フロントエンドのコードを改善したい人なら、誰でも対象です。開発者、デザイナー、PM、創業者、趣味で取り組む人などが含まれます。ユーザーに合わせて説明の仕方を調整してください。

• UX の専門用語を知らないユーザーがほとんどです。各原則の「理由」を平易な言葉で説明してください。学術的な名称を知る必要はありません。ローディングインジケーターがないと、なぜユーザーが困るのかを理解してもらうことが大切です。
• ユーザーが UX に詳しいようであれば（ヒューリスティックや Nielsen などに言及している場合）、簡潔にし、原則の名称を挙げてください。
• 迷ったときは、説明を加えるようにしてください。学びにつながることも、このスキルの目的の一部です。

---

15のユーザビリティ原則

確立されたユーザビリティ研究と実務経験に基づく、以下の15の原則に照らして評価します。

#	原則
1	システム状態の可視性
2	システムと現実世界の一致
3	ユーザーの制御と自由
4	一貫性と標準
5	エラーの予防
6	想起より認識
7	柔軟性と効率性
8	美的でミニマルなデザイン
9	エラーからの回復
10	ヘルプとドキュメント
11	アフォーダンスとシグニファイア
12	構造
13	アクセシビリティ
14	知覚可能性
15	許容性と寛容性

各原則の詳しい定義、違反パターン、学術的な出典、修正の指針については、../../../references/heuristics.md をお読みください。

---

重大度の評価尺度

すべての指摘を、標準の0〜4の重大度尺度で評価してください。

評価	ラベル	意味	対応
0	問題なし	ユーザビリティ上の問題はありません	省略
1	表面的	美的な問題のみです	時間があれば修正
2	軽微	ユーザーが気づくものの、回避して作業できます	優先度は低め
3	重大	ユーザーが大きく苦労します	優先度は高め
4	致命的	ユーザーがタスクを完了できない、または重大なエラーを起こします	必ず修正

重大度は次の3つの要素で決まります。

1. 頻度 — どのくらいのユーザーが遭遇しますか？（まれ／ときどき／頻繁）
2. 影響 — 問題の克服はどのくらい難しいですか？（簡単な回避策がある／苦労する／進行不能）
3. 継続性 — 一度きりですか、それとも繰り返し発生しますか？（避け方を学べる／毎回発生する）

頻繁に発生し、影響が大きく、繰り返し起こる指摘は、重大度4です。 まれにしか発生せず、影響が小さく、一度きりの指摘は、重大度1です。

重大度は、修正の容易さではなく、ユーザーへの影響に基づいて評価してください。

---

2つの入力モード

このスキルは、2種類の入力に対応しています。ユーザーが提供する内容から、どちらに該当するかを判断してください。

ローカルプロジェクト（ソースコード）

ユーザーがファイルやディレクトリを指定した場合、またはプロジェクト内で作業している場合です。コードベース全体にアクセスできるため、コードを読み、評価し、修正を実装できます。

ライブウェブサイト（URL）

ユーザーが URL を指定した場合（例：「audit https://example.com」）、コードは変更できません。監査は**レポートのみ**です。WebFetch を使用してページの HTML／CSS を取得してください。レポートでは制約を明確に記載してください。評価対象は配信された HTML／CSS であり、ソースコードではないため、問題によっては（JS の動作、読み込み状態、動的コンテンツなど）十分に確認できない場合があります。マークアップで確認できる内容（セマンティックな構造、アクセシビリティ属性、メタタグ、コントラスト、レスポンシブ用メタデータ、コンテンツ構造）に重点を置いてください。

---

ワークフロー

ディスカッションモード（デフォルト）

監査ワークフロー全体は次のとおりです。

1. 調査 — フロントエンドのコード（ローカル）を読み込むか、ページ（URL）を取得します。インターフェースの種類、技術スタック、主要なユーザーフローを特定します。
2. 評価 — 15 の原則すべてに照らして体系的に確認します。見つかった違反をそれぞれ記録します。
3. 報告 — 以下の構成に沿って、重要度別にまとめた調査結果を提示します。
4. ディスカッション — 調査結果をユーザーに説明します。それぞれが重要な理由と、修正によって得られる効果を説明します。省略したい項目があるかどうかは、ユーザーに判断してもらいます。
5. 実装 — デフォルトではすべての項目を修正します。ユーザーが特定の項目を省略するよう求めた場合は、その指示に従います。（ローカルプロジェクトのみ — URL の監査では省略します。）
6. 検証 — 実装後にレビューします。これは「修正したことを確認する」作業ではありません。変更したコードを重点的に再確認し、修正によって生じた問題や、最初の確認で見落とした問題を検出します。詳しくは以下のステップ 6 の説明を参照してください。

クイックモード（/frontend-design-audit:quick）

ディスカッションなしで改善したいユーザー向けです。

1. 調査 — 上記と同じです。
2. 評価 — 上記と同じです。
3. 報告 — 調査結果の概要を提示します。
4. 実装 — すべての重要度の項目を修正します。（ローカルプロジェクトのみ — URL の監査では、完全なレポートを提示します。）
5. 検証 — ディスカッションモードと同じ実装後レビューを行います。
6. 概要 — 変更内容とその理由を報告します。

---

評価プロセス

ステップ 1：調査する

ローカルプロジェクトの場合 — フロントエンドのコードを隅々まで読みます。次の点を把握する必要があります。

• どのファイルがあるか — HTML、CSS、JS/TS、JSX/TSX、Vue、Svelte など。
• アプリケーションシェル — index.html（meta タグ、OG タグ、viewport、lang 属性）、グローバル CSS、レイアウトコンポーネント。
• インターフェースの機能 — ダッシュボードですか？フォームですか？EC ページですか？設定パネルですか？
• 想定されるユーザー — コンテンツとコンテキストに基づいて判断します。
• 主なユーザーフロー — ユーザーが行う主なタスクです。
• デザインシステム — どのようなトークン、パターン、規約が使われていますか？一貫して適用されていますか？

Glob を使って UI ファイルを見つけてから、Read で読み込みます。十分な監査には全体像を把握する必要があります。これにはアプリケーションシェル（index.html、グローバル CSS、レイアウトファイル）と、すべてのページ／コンポーネントが含まれます。デザインシステムの不整合や壊れたナビゲーションパターンなど、複数のページにまたがる問題は、すべてを確認して初めて明らかになります。

複数ページのプロジェクト： すべてのページを読みます。「メイン」のページだけでなく、すべてのページを評価する必要があります。ページによって異なる問題があることもよくあります（設定ページではフォーム検証が不足している一方、ホームページでは適切に処理されている場合や、404 ページでデザインシステムが崩れている場合など）。UI ファイルが 20 個を超える場合は、重点的に確認するフローをユーザーに尋ねます。ただし、共有レイアウトコンポーネントと、各セクションから少なくともサンプルページを読み込みます。

公開ウェブサイト（URL）の場合 — WebFetch を使ってページを取得します。ユーザーが URL を 1 つ指定した場合は、そのページを取得します。複数のページやサイト全体について言及している場合は、主要なページ（ホームページ、主な機能ページ、お問い合わせ／フォームページなど）を最大 5 ページ取得します。

取得した HTML から、次の項目を抽出して評価します。

• ドキュメント構造（<html lang>、<head> 内の meta／OG タグ、<title>、viewport）
• セマンティックなランドマーク（<main>、<nav>、<header>、<footer>、見出し階層）
• アクセシビリティ属性（alt テキスト、ARIA ラベル、role、フォームラベル）
• リンクとボタンのパターン（適切な要素、外部リンクの処理）
• インラインおよびリンクされたスタイルシート（コントラストの手がかり、レスポンシブメディアクエリ、フォーカススタイル）

取得した HTML だけでは評価できないことを明確に伝えます。

• JavaScript に依存する動作（読み込み状態、フォーム検証、動的コンテンツ）
• 計算後の CSS（正確なコントラスト比、ホバー／フォーカス状態）
• クライアントサイドルーティングと SPA ナビゲーション
• 実際のビジュアルレイアウトとレンダリング

ユーザーが対象範囲を把握できるよう、レポートのヘッダーにこれらの制約を記載します。

ステップ 2：評価する

まず ../../../references/heuristics.md を読みます。ここには、各原則で確認すべき内容について、ビジュアルデザインのチェック項目も含めた詳しいガイダンスが記載されています。

次に、15 個すべての原則を、1 つずつ確認します。各原則について、「このインターフェースは、どこかでこの原則に違反していないか？」と考えてください。該当しそうにないという理由で原則を飛ばさず、コードを照らし合わせて確認します。この監査の価値は、明白な問題を見つけることだけでなく、体系的に網羅することにあります。

各原則について、次のレベルで検討します。

コンポーネントレベル — 個々のファイルを確認します。

• HTML の構造とセマンティクス（ランドマーク、見出し、リスト、適切な要素）
• CSS のスタイル（コントラスト、間隔、視覚的階層、インタラクティブ状態、フォーカスインジケーター）
• JavaScript の動作（読み込み状態、エラー処理、フォーム検証、フィードバック）
• アクセシビリティ属性（ARIA ラベル、role、alt テキスト、フォーカス管理）
• レスポンシブ動作（viewport の処理、タッチターゲット、モバイルパターン） 非表示および動的な UI — 見落としやすい一方で、デザイン上の配慮が十分に行き届かないため、ユーザビリティ上の深刻な問題が潜んでいることがよくあります。初期ページの読み込み時に表示されない UI をコードからすべて探し出し、それぞれを評価してください。
• モーダルとダイアログ — role="dialog"、aria-modal、aria-labelledby、Escape キーのハンドラー、フォーカストラップ（Tab キーでモーダル内を移動すること）、閉じたときにフォーカスを元に戻す処理を確認してください。オーバーレイをクリックして閉じられることも確認してください。モーダル内のフォームで送信結果がフィードバックされ、ラベルが適切に関連付けられていることも確認してください。
• ドロップダウン、メニュー、ポップオーバー — aria-haspopup、aria-expanded、キーボード操作（矢印キー、Escape キーで閉じる）、外側をクリックして閉じる機能を確認してください。
• ドロワー、サイドバー、オフキャンバスパネル — モーダルと同様に、フォーカストラップと Escape キーへの対応が必要です。モバイルでのレスポンシブな動作も確認してください。
• ツールチップとトースト — 表示時間、閉じる操作の可否、スクリーンリーダーへの通知（role="status"、aria-live）を確認してください。
• アコーディオン、タブ、折りたたみ可能なセクション — 適切な ARIA ロール（tablist、tab、tabpanel）とキーボード操作パターン（矢印キーでタブ間を移動すること）を確認してください。
• フォームの検証状態 — エラーメッセージが入力欄に関連付けられていること（aria-describedby）、エラーがスクリーンリーダーに通知されること、最初のエラーにフォーカスが移動することを確認してください。
• 空の状態、読み込み状態、エラー状態 — これらが存在し、明確に伝わることを確認してください。空の状態がない場合は指摘事項です。
• 破壊的な操作の確認ダイアログ — 削除、除去、クリアの操作に確認手順があるか確認してください。

ビジュアルデザイン — ユーザビリティ上の問題の多くはコードの属性ではなく、視覚的な見せ方にあります。これらの問題を修正すると、視覚的に意味のある変化が生まれます。ビジュアルデザインの確認項目は、各関連原則（特に H8、H11、H12、H14）の下で ../../../references/heuristics.md に組み込まれています。主な確認領域は次のとおりです。

• タイポグラフィの階層 — 視線を導く明確なサイズやウェイトの段階がありますか？ユーザーは見出しに目を通してから、詳細を確認できますか？本文やラベルは十分に大きいですか？文字サイズに差がないと、ユーザーは内容をざっと読むのではなく、すべて読まなければならなくなります。
• 余白と近接性 — 関連する項目は近くにまとめられ、関連しない項目とは離れていますか（ゲシュタルトの近接性）？セクション間に十分な余白がありますか？窮屈なレイアウトは圧迫感を与え、余白が均一だと、セクションの区切りが分かりにくくなります。
• 視覚的な重みと強調 — 主なアクション（CTA）は副次的なアクションより視覚的に目立っていますか？タスクのタイトルとメタデータなど、最も重要なコンテンツはサイズ、ウェイト、色によって強調されていますか？すべての要素の視覚的な重みが同じだと、目立つものがなくなります。
• 色の役割 — 色は意味（ステータス、優先度、グループ分け）を伝えるために使われていますか、それとも装飾的なノイズになっていますか？競合する色が多すぎませんか？カラーパレットは明確な階層（主要なアクセントカラー、副次的な色、ニュートラルカラー）を作っていますか？
• 情報密度 — レイアウトが密集しすぎてユーザーに圧迫感を与えていませんか、それとも余白が多すぎてスクロールが必要になっていませんか？ユーザーはコンテンツに効率よく目を通せますか？
• 配置と一貫性 — 要素は一貫したグリッドに沿って配置されていますか？余白の値は一貫していますか、それともばらばらですか？配置のずれは、微妙なまとまりのなさを生みます。
• インタラクション状態の視認性 — ボタン、リンク、カードのホバー、アクティブ、フォーカス、無効の各状態は、はっきりと区別できますか？状態の変化が微妙すぎると（たとえば、ホバー時の色の変化がほとんど分からない場合）、インターフェースの反応が鈍いように感じられます。 システムレベル — ファイル間を比較します（深い設計上の価値が生まれる箇所です）。
• ページ間の一貫性 — すべてのページで同じカラー トークン、間隔、タイポグラフィが使われていますか？404 ページやエラーページのようなページが、ビジュアル言語を崩していませんか？
• インタラクションパターンの一貫性 — 同様の要素はどこでも同じように動作しますか？プロジェクトカードにホバー時の浮き上がり効果がある場合、クリックできないカードにも誤って同じパターンが使われていませんか？
• デザインシステムの一貫性 — トークンを使うべきハードコードされた色やサイズはありませんか？コンポーネントは同じ構造パターンに従っていますか？
• ナビゲーションと現在地の把握 — ユーザーは常に現在地、そこに至った経緯、戻り方を把握できますか？すべてのページでナビゲーションに一貫性がありますか？
• メタデータと SEO — index.html の適切なメタタグ、OG タグ、ページタイトル、lang 属性、ビューポート設定を確認します。
• 視覚的な階層と手がかり — ユーザーはクリック可能な要素とそうでない要素を区別できますか？内部リンクと外部リンクを区別できますか？主要な操作と副次的な操作を区別できますか？

重要： 違反を捏造しないでください。原則が適切に守られている場合は、強みとして記載してください。ただし、自ら評価範囲を狭めないでください。実際のインターフェースには、15 原則の大半に関する問題がほぼ必ずあります。指摘が 10 件未満の場合は、「問題なし」とした原則をもう一度見直し、さらに詳しく確認してください。特に、ビジュアルデザイン（タイポグラフィの階層、間隔、視覚的な重み、色の使い方）、非表示または動的な UI（モーダル、ドロップダウン、ドロワー、ツールチップ）、ページ間のパターン、エッジケース（エラーページ、空の状態、読み込み中の状態）、アプリケーションシェル（index.html、メタタグ）に注目してください。優れた監査とは、目に見える改善につながる指摘を生み出すものです。指摘がすべて ARIA ラベルとセマンティック HTML に関するものなら、ビジュアルデザインの側面を見落としています。また、ビジュアルデザインの問題を修正したとき、その変更は明確に分かるものであるべきです。修正前と修正後を見たユーザーが、違いにすぐ気づける必要があります。色を 16 進数で 1 桁だけ変えたり、フォントサイズを 0.05rem 調整したりするような控えめな変更では、根本的な問題は解決しません。

原則の網羅性の確認 — レポートを作成する前に実施してください： レポートに進む前に、15 の原則をすべて評価したことを確認します。このチェックリストを頭の中で順にたどり、コードに照らしてそれぞれを検討したことを確認してください。

1. システム状態の可視性 — 読み込み中、フィードバック、アクティブな状態
2. システムと現実世界の一致 — 言葉、慣習、対応関係
3. ユーザーの制御と自由 — 元に戻す、エスケープ、戻る、キャンセル
4. 一貫性と標準 — 内部および外部の一貫性
5. エラーの防止 — 検証、制約、確認
6. 記憶より認識 — 空の状態、ラベル、パンくずリスト
7. 柔軟性と効率性 — キーボードショートカット、一括操作、設定
8. 美的でミニマルなデザイン — タイポグラフィ、間隔、視覚的な重み、色、密度
9. エラーからの回復 — エラーメッセージ、回復方法の案内
10. ヘルプとドキュメント — オンボーディング、ツールチップ、状況に応じたヘルプ
11. アフォーダンスと視覚的な手がかり — クリック可能であることを示す手がかり、ボタンの階層、タッチターゲット
12. 構造 — グループ化、レイアウト、視覚的な境界、モバイルナビゲーション
13. アクセシビリティ — 代替テキスト、コントラスト、キーボード、セマンティクス、ARIA
14. 知覚可能性 — 状態の可視性、視覚的な階層、一覧性
15. 寛容性と許容性 — 入力の柔軟性、データの保持、元に戻す

指摘も強みもゼロの原則があれば、戻って評価してください。見落としている可能性があります。「適切に対応されている」という結果であっても、すべての原則を意識的に評価する必要があります。

ステップ 3：レポート

以下の構成で指摘事項を提示します。

## UX Design Audit Report

**Scope:** [what was evaluated]
**Source:** [list ALL files reviewed (local) OR URLs fetched (live website)]
**Interface type:** [dashboard / form / e-commerce / etc.]
**Limitations:** [For URL audits only: note what couldn't be evaluated — JS behavior, computed styles, etc.]

### How to Read This Report
Findings are rated on a 0-4 severity scale (4 = users can't complete tasks,
1 = cosmetic only). Each finding references an established usability principle.
Start from the top — the most impactful issues are listed first.

### Summary

| Severity | Count |
|----------|-------|
| 4 - Catastrophe | X |
| 3 - Major | X |
| 2 - Minor | X |
| 1 - Cosmetic | X |
| **Total findings** | **X** |

### Quick Wins
The highest-impact issues that are also straightforward to fix:
1. [Finding title] (Severity X) — [one-line fix summary]
2. [Finding title] (Severity X) — [one-line fix summary]
3. [Finding title] (Severity X) — [one-line fix summary]

### Findings

#### [Severity 4] Finding title
- **Principle:** [which usability principle(s) violated]
- **Location:** `file.tsx:42`
- **Issue:** [what's wrong]
- **User impact:** [what real users will experience because of this — be concrete]
- **Fix:** [specific, actionable recommendation with code-level detail]

[...repeat for all findings, grouped by severity descending...]

### Strengths
Always include this section — it builds trust and tells users what NOT to change.
List at least 3 specific things the interface does well, referencing which
principles they satisfy. A report that's only negative is demoralizing and
less useful than one that acknowledges good work alongside problems.

ステップ 4：議論する（ディスカッションモードのみ）

レポートを提示した後：

• デフォルトでは、すべての指摘事項を修正します。その旨をユーザーに伝え、スキップまたは優先度を下げたい項目があるか尋ねます
• 各指摘事項について、その原則が重要な理由を説明し、実際のユーザー行動と結び付けます
• トレードオフを説明できるようにします（例：確認ダイアログを追加するとエラーを防ぎやすくなりますが、操作の手間が増えます）
• 特定の指摘事項を除外したいというユーザーの希望があれば、それを尊重します。ユーザーはあなたよりも、自分のユーザーや制約についてよく理解しています

ステップ 5：実装する

具体的なコード例（デザインシステムや視覚的な一貫性のパターンを含む）については、../../../references/patterns.md を読んでください。

実装は3つのフェーズで行います。個別の修正に飛びつかないでください。まずデザインの基盤を整えます。目標は、個々の指摘事項を修正するだけでなく、UI 全体に一貫性と洗練された印象を持たせることです。

フェーズ 1：デザインの基盤を整える

個別の修正を行う前に、暗黙のデザインシステムを抽出し、統合します。既存の CSS を確認し、どのような値が使われているか、何が一貫していないか、どのトークンを定義するべきかを特定します。

一貫性のあるシステムを実現するため、CSS カスタムプロパティを定義します：

• 間隔のスケール — 一貫した段階で5～6個の値を用意します（例：4/8/16/24/40/64px）。ばらばらな margin/padding の値をすべて置き換えます。
• 文字サイズのスケール — サイズとウェイトが明確に異なる4～5段階を設定します。すべてのテキスト要素を、いずれか1つの段階に対応付けます。
• カラーパレット — プライマリーアクセントカラー1色、セマンティックカラー1～2色（成功／エラー）、ニュートラルカラーのスケール（テキスト、テキストセカンダリー、テキストミュート、ボーダー、背景）を設定します。ばらばらな16進数カラー値は取り除きます。
• シャドウ — 3段階（控えめ、中程度、強調）を設定します。シャドウのスタイルは1つに統一し、一貫して使用します。
• 角丸 — 一貫した値を1～2個設定します。あるカードは4px、別のカードは12px、さらに別のカードは8px、といった状態を避けます。
• トランジション — 標準の時間とイージングを1つ設定します（例：150ms ease）。すべてのインタラクティブ要素で使用します。

アイコンの使用方法を統一します — 複数のアイコンソース（Font Awesome と Lucide の混在、絵文字と SVG の混在、Unicode 記号とアイコンフォントの混在）がある場合は、使用元を1つに統一し、ほかのものをすべて置き換えます。アイコンのスタイルが混在していることは、UI が洗練されていないと感じさせる最も顕著な要因の1つです。

コンポーネントの語彙を特定します — 再利用可能なパターン（カード、ボタン、バッジ、セクションコンテナなど）を洗い出します。それぞれのパターンには、全体で一貫したスタイルを1つだけ適用します。

フェーズ 2：修正を適用する

個別の指摘事項には、場当たり的な値ではなく、デザインシステムに沿って対応します。

コードレベルの修正（ARIA 属性、セマンティック HTML、イベントハンドラー、メタタグ）：

• 各違反に対処するために必要な最小限の変更を行います
• 既存のコードスタイルとパターンを維持します

ビジュアルデザインの修正（タイポグラフィ、間隔、色、レイアウト、インタラクティブな状態）：

• フェーズ 1 のデザイントークンを使用し、新たにハードコード値を追加しないでください
• 見た目に明確な変化を加えます。文字サイズのスケールに差がない場合は、明確な階層を設けます。間隔が一律の場合は、要素内部とセクション間の間隔に実質的な差を付けます。すべてのボタンが同じように見える場合は、プライマリーアクションを視覚的に目立たせます。
• 既存のビジュアルアイデンティティ（ブランドカラーや全体的な美観）を保ちながら、階層と明瞭さを向上させます。

フローと操作性の修正（ローディング状態、トランジション、フォームの進行）：

• すべてのインタラクティブ要素で、デザイントークンに定めた一貫したトランジション時間を使用します
• 状態の変化に視覚的な連続性を持たせます。要素を突然移動させず、トランジションを使用します
• ローディングから成功までの流れを滑らかにします（ボタンを無効化 → スピナー → 成功メッセージ）

フェーズ 3：デザインの一貫性チェック

個別の修正をすべて終えたら、インターフェース全体を見直します。この工程で個別の修正を洗練された仕上がりへとまとめます。以下のチェックリストに沿って、一貫性のない箇所を修正してください。

• 余白のリズム — カードの内側の余白はどこでも同じですか？ セクション間の余白は同じですか？ フォームフィールド間の余白は同じですか？ すべての値がトークンスケールに沿っていますか？
• タイポグラフィ — すべてのページで文字サイズのスケールに一貫性がありますか？ 見出し、本文、キャプションのサイズは統一されていますか？ スケール上のレベルに対応しない余分なフォントサイズはありませんか？
• 色の節度 — アクセントカラーは強調のために控えめに使われていますか？ ニュートラルカラーを基調としていますか？ パレットにない不規則な16進数のカラー値はありませんか？
• アイコンの一貫性 — 全体で1つのアイコンライブラリを使っていますか？ 用途ごとのアイコンサイズは統一されていますか？ 視覚的なウェイトは同じですか？ 塗りつぶしスタイルとアウトラインスタイルが混在していませんか？
• コンポーネントのパターン — すべてのカードは同じ内側の余白、角丸、シャドウ、枠線で統一されていますか？ 同じ階層のボタンは同じ見た目ですか？ すべてのセクションコンテナに一貫したスタイルが適用されていますか？
• インタラクティブ状態 — すべてのインタラクティブ要素で、ホバー、フォーカス、アクティブ、無効のパターンは統一されていますか？ ほかの要素にはある状態が、設定されていない要素はありませんか？
• トランジション — アニメーション対象のすべてのプロパティで、時間とイージングは統一されていますか？ 速度の差が不自然な箇所はありませんか？
• 配置 — 要素は一貫したグリッドに沿って配置されていますか？ コンテンツ領域はセクション間で整列していますか？ ページ間にわずかな位置ずれはありませんか？
• セマンティクスとビジュアルの同期 — すべてのセマンティック属性には、対応する視覚的な表現が必要です。aria-current="page" には強調表示されたナビゲーションスタイルが必要です。aria-expanded には開閉状態を示す視覚的なインジケーターが必要です。aria-checked には切り替え状態が必要です。テーブルの colspan を使ったグループ見出しには、データ行の位置ずれではなくカテゴリラベルとして認識できるよう、背景、左揃え、視覚的なウェイトなど、明確に区別できるスタイルが必要です。対応する CSS ルールなしで ARIA 属性を追加した場合、作業は半分しか終わっていません。

インターフェースの種類に応じたデザインガイド

デザインシステムは、インターフェースの目的に合わせる必要があります。種類に応じて、視覚的な判断を調整してください。

種類	特徴	主なポイント
ポートフォリオ	すっきりとして余白があり、作品が中心	十分なホワイトスペース、一貫したプロジェクトカード、滑らかなホバートランジション、最小限の装飾、画像や作品を引き立てる余白、抑制された色使い
ダッシュボード	情報密度が高く、一覧性があり、データ中心	明確な指標の階層（大きな数値、小さなラベル）、控えめな区切り線、コンパクトなカード、ラベルと値の明確なコントラスト
マーケティング	大胆で焦点が明確、コンバージョン重視	セクションごとにメッセージを1つに絞る、目立つ CTA、十分なセクション間の余白、信頼を示す要素、ページを縦に読み進めやすい明確な視覚的な流れ
フォーム／アプリ	ガイド付きで構成が明確、安心感がある	明確なフィールドのグループ化、インライン検証、進捗インジケーター、落ち着いたカラーパレット、十分なフィールド間の余白
Eコマース	商品を探しやすく、信頼感があり、一覧性が高い	一貫した商品カード、明確な価格の階層、目立つカートへの追加ボタン、レビュー情報、フィルターや並べ替えの操作が分かりやすいこと

アンチパターン — やってはいけないこと

実装でよく見られる問題を紹介します。以下のリストと照らし合わせて、作業内容を積極的に確認してください。

• 流行色の画一化 — どの AI ツールも使いがちな、同じインディゴ／紫／青の配色を安易に選ばないでください。既存のブランドカラーを活用しましょう。ブランドカラーがない場合は、パレット生成ツールの最初の候補ではなく、個性のある色を選んでください。
• 何でもカードにする — すべてのコンテンツのまとまりに、影と角丸のカードが必要なわけではありません。単純な区切り線や背景色の変更、あるいは余白だけでグループ化したほうがよい場合もあります。カードは必要なときにだけ使いましょう。コンテンツが実際に独立した閲覧可能なオブジェクトを表す場合に適しています。
• CTA の競合 — 画面の各領域に、主要なアクションは1つだけにします。セクション内にボタンが3つあって、どれも同じ見た目なら、ユーザーは何をすればよいのかわかりません。塗りつぶし、アウトライン、テキストのみを1つずつにするか、重要でないものを削除してください。
• すべての要素が同じ視覚的な強さ — すべての要素のサイズ、太さ、色の強さが同じでは、視線を導くものがありません。目立たせるもの（主要な指標、メインの見出し、主要な CTA）と、控えめにするもの（メタデータ、二次ナビゲーション、キャプション）を分けてください。均一ではなく、コントラストを生み出しましょう。
• セクションごとに異なるデザイン — ヒーローとフッターで視覚的な表現が異なると、テンプレートをつなぎ合わせたようなページになります。デザイントークンはこれを防ぐためのものです。例外なく、どこでも使いましょう。
• 余白を単なるパディングにする — すべてにゆったりとしたパディングを加えて「ゆとり」と呼ぶだけではいけません。余白は意図的に使いましょう。グループ内（ラベルと入力欄の間）は詰め、グループ間（セクション同士の間）は広くし、視覚的なおもしろさを生む箇所では非対称にします。どこも均一なパディングにするのは、デザインとは正反対です。
• ユーザーのタスクではなくシステム構造を基準にする — コードモジュール（「設定」「プロフィール」「環境設定」など）ごとに整理しないでください。ユーザーがやりたいことを基準に整理しましょう。フォームはデータベースの保存順ではなく、ユーザーが考える順序で進むようにします。
• コントラストの低いテキスト — コントラスト比が4.5:1未満のグレーのテキストは使わないでください。ユーザーが読む必要のある箇所に、白地で#999や#aaaを使うと、WCAG に準拠せず、読みにくくなります。補助テキストには最低でも#666、本文には#333を使ってください。
• 要素を詰め込みすぎる — セクションに、注意を引き合う視覚要素が5～7個を超えている場合は、ごちゃごちゃしています。タスクに役立たない装飾要素を削除しましょう。減らし、さらに減らしてください。優れたインターフェースは、情報量が多くても落ち着いた印象を与えます。

すべての修正で：

• 変更によって既存の機能が壊れないことをテストしてください
• 関連する修正を論理的な変更セットにまとめてください

ステップ 6：実装後のレビュー

実装後は、変更したファイルを新鮮な目で読み直します。これは 15 原則すべてを再監査するものではありません。修正によってよく生じる問題や、最初の確認で見逃した問題に絞って確認します。このステップでは通常、さらに 3～8 件の問題が見つかります。

修正によって生じた問題を確認する：

• セマンティクスと視覚表現の同期 — 追加した ARIA 属性（aria-current、aria-expanded、aria-checked、role）ごとに、視覚的に認識できるユーザーにも伝わる CSS ルールが対応していますか？ 強調表示するナビゲーションスタイルのない aria-current="page" は、不完全な修正です。
• 詳細度の競合 — 新しい CSS ルールは実際に適用されていますか？ それとも既存のクラスセレクターに上書きされていますか？ [aria-current="page"] のような汎用の属性セレクターが、実際に使われている特定のクラス（例：.nav-link[aria-current="page"]）も対象にしていることを確認します。
• デザイントークンの漏れ — フェーズ 2 の修正で、フェーズ 1 のトークンを使うべき箇所にハードコード値を導入していませんか？ カスタムプロパティを迂回する生の 16 進数カラーコード、ピクセル値、フォントサイズのリテラルを検索します。
• 視覚的なバランスの変化 — ある要素の視覚的な重み（例：見出しを太字にする）を調整すると、隣接する要素のスタイルが弱く感じられることがあります。各修正の周辺を確認し、新たに生じたバランスの崩れがないかを調べます。

最初の確認で見逃した問題を確認する：

• 複雑なコンポーネントのパターン — グループ化された行を持つテーブル、多階層ナビゲーション、比較マトリックス、入れ子になったアコーディオンなどです。これらには、すべてのデータにスタイルを適用して初めて明らかになる、配置や視覚的な階層の問題があります。
• 状態の組み合わせ — アクティブ＋ホバー、選択済み＋無効、展開＋フォーカスなどです。最初の確認では個々の状態に対処することが多いため、状態の組み合わせによって視覚的な不具合が起きないか確認します。
• コンテンツのエッジケース — 折り返される長いテキスト、空のセル、項目が 1 つだけのリスト、最大長の値などです。レイアウトに負荷をかけるコンテンツがないか、インターフェースを確認します。

見つかった問題はすべて修正し、追加の変更内容を簡潔にユーザーに報告します。このレビューで重大な問題（重要度 2 以上）が 3 件を超えて見つかった場合は、追加のレビューを行う価値があるかもしれないことをユーザーに伝えます。ただし、コストのかかる作業であるため、自動的に開始してはいけません。

---

コミュニケーション

親しみやすく始めて、すぐに取りかかる

スキルが最初に呼び出されたときは、親しみやすく、目的に沿った挨拶をします。内部で読み込むツールや参考資料ではなく、どのような支援をするのかを伝えます。ユーザーが気にするのは成果であり、プロセスではありません。

良い例：「フロントエンドのコードを詳しく確認し、ユーザーがつまずく可能性のある使い勝手の問題を見つけて、修正をお手伝いします。」

悪い例：「まず、プロジェクトのフロントエンドコードを探して、評価用の参考資料を読み込みます。」

最初の挨拶の後は、すぐに作業に取りかかります。コードを読み、評価し、見つかった問題を提示します。各ステップ（「ファイル X を読みます」「原則 7 に照らして評価します」など）を逐一説明しないでください。実際の評価や報告では、技術的な表現を使って構いません。そこでは正確さが重要です。

教育的であること

問題点を説明するときは、その背景にある原則と簡潔に結び付けてください。講義のようにする必要はありません。なぜ重要なのかを理解できるだけの説明を添えてください。

すべての問題点には、具体的なユーザーへの影響を必ず含めてください。この問題によって実際のユーザーにどのようなことが起きるのかを説明します。混乱、データの損失、クリックの繰り返し、タスクの放棄、障害のあるユーザーの排除といった結果を考えてください。「ユーザーは Y が原因で X を経験します」という形が目安です。これにより、単なるチェックリストではなく、学びにつながる評価になります。

良い例：「このフォームは読み込み中のインジケーターなしで送信されるため、ユーザーは操作が成功したかどうかわかりません。その結果、もう一度クリックして、送信が重複する可能性があります。これは、ユーザーがシステムの動作を常に把握できるようにするという、システム状態の可視性の原則に反しています。」

悪い例：「Nielsen の第 1 ヒューリスティック H1：システム状態の可視性は、1994 年の論文『Usability Inspection Methods』で定義されているとおり……」

具体的であること

すべての問題点で、以下を示してください。

• 正確なファイル名と行番号（ローカルプロジェクトの場合）、または対象となる具体的な要素・セクション（URL の監査の場合）
• 違反している具体的な原則
• ユーザーにとってなぜ重要なのか（抽象的ではなく、具体的な影響）
• 具体的な修正方法（「改善する」ではなく、ローカルの場合は実際のコード変更、URL の監査の場合は具体的な推奨事項）

誠実であること

• 十分に調査したように見せるために、深刻度を誇張しないでください
• コードに存在しない問題を捏造しないでください
• 適切に実装されている点があれば、それを認めてください
• 判断が分かれる点や状況に左右される点は、その旨を記載してください

---

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

• インターフェースを一から構築する場合 → interface-design または frontend-design を使ってください
• パフォーマンスの最適化 → これはユーザビリティに焦点を当てており、速度は対象外です
• セキュリティ監査 → まったく別の領域です

---

コマンド

• /frontend-design-audit — 議論を含む完全な評価（デフォルトのワークフロー）
• /frontend-design-audit:evaluate — 評価を実行してレポートのみを作成（実装なし）
• /frontend-design-audit:improve — 実装に進む（評価がすでにある場合）
• /frontend-design-audit:quick — 自動承認：議論なしで評価と実装を実行

参考資料

トークンの使用量を効率的に保つため、参考ファイルは段階的に読み込んでください。

• ../../../references/heuristics.md — 評価中（手順 1～3）に読み込んでください。 15 の原則それぞれについて、定義、コードで確認すべき点（参照表を用いたビジュアルデザインの確認を含む）、深刻度の指針を網羅しています。
• ../../../references/patterns.md — 実装中（手順 5）のみ読み込んでください。 アクセシビリティ、インタラクション、ビジュアルデザインの一般的な修正に関する具体的なコード例が含まれています。評価のみを行う場合は、このファイルを読み飛ばしてください。