frontend-design

フロントエンドデザイン

ユーザー、タスク、コンテンツ、製品カテゴリ、技術的制約に適したインターフェースを作成します。「最善」とは、特定のビジュアルスタイルに従うことではなく、状況に適していることを意味します。

アクセシビリティ、機能の正確性、妥当な実装例、使いやすいレスポンシブ動作は、必ず満たすべき条件です。キーボード操作が行き詰まる、操作要素にアクセスできない、コンテンツが読みにくい、状態が壊れている、レスポンシブ対応に重大な欠陥がある、またはパフォーマンスへのコストに正当な理由がない結果を、見た目が優れているという理由で承認してはいけません。

運用上の判断基準

実現可能なデザイン案を比較する際は、以下の比重を使用します。これは運用上の判断基準であり、普遍的な数学的基準ではありません。また、必ず満たすべき条件の失敗を補うものではありません。

基準	比重
ユーザーとタスクへの適合性	20%
アクセシビリティ	20%
使いやすさと情報アーキテクチャ	15%
ビジュアルの一貫性と適切な独自性	15%
レスポンシブおよび適応動作	10%
パフォーマンスとレジリエンス	10%
インタラクションと状態の網羅性	5%
保守性と検証	5%

基準が競合する場合は、まず主要なタスクと必ず満たすべき条件を優先します。意図的に妥協した点が残る場合は、その内容を記録します。

簡潔なワークフロー

1. 既存の製品、プロジェクトの慣例、デザインシステム、コンポーネント、コンテンツ、制約を確認します。
2. 対象ユーザー、主要なタスク、コンテンツの種類、製品カテゴリ、ブランド上の制約、必要なプラットフォーム、入力方法を特定します。
3. 主要なデザインモードを1つ選びます。適合性が高まる場合に限り、補助的な要素を1つまで追加します。
4. 1文で表すビジュアルの指針、簡潔なコンテンツまたは情報の計画、そして意味のあるインタラクションやモーションが必要な場合に限り、インタラクションの指針を定めます。
5. 新しいものを作る前に、プロジェクトで確立されているデザインシステムとコンポーネントを再利用します。
6. 完全な状態モデルと実際のコンテンツ階層を設計し、実装します。
7. 代表的な画面幅と関連する入力方法を使って、レンダリング結果を検証します。
8. 根拠と未解決の制限事項を正直に報告します。

計画の規模は、作業に見合ったものにします。小さなコンポーネントの変更なら、長い設計文書ではなく、いくつかの明確な判断だけで十分な場合があります。

デザインモードの選択

流行の美的傾向ではなく、製品の目的に基づいてモードを選びます。

製品またはワークスペース

アプリケーション、管理ツール、業務用インターフェースに使用します。

• 実用性を重視した文言と、読みやすい情報密度を優先します。
• ワークスペース、ナビゲーション、コンテキストごとの領域を明確に定義します。
• 色や装飾的な要素は控えめにします。
• グルーピング、囲い込み、インタラクションの意味付けが妥当な場合に限り、カードを使用します。
• デフォルトでランディングページのヒーローを追加してはいけません。

マーケティングまたはブランド

ランディングページ、ローンチページ、ポートフォリオ、プロモーションサイトに使用します。

• 明確なビジュアルの指針を定め、ブランドまたは製品の存在感を強く打ち出します。
• 各セクションに、中心となるビジュアルのアイデアを1つ設けます。
• ストーリーを簡潔に保ち、コンバージョンへの導線を明確にします。
• 画像は意図を持って使用し、モーションはストーリーを支える場合に限って使用します。

データまたはダッシュボード

分析、モニタリング、意思決定支援のインターフェースに使用します。

• 情報の走査、比較、ステータスの可視性を最適化します。
• 意思決定に沿って、フィルター、テーブル、チャート、詳細表示への導線を構成します。
• 情報量の多いレイアウトでも読みやすさを保ちます。
• データの鮮度、単位、対象範囲、空状態またはエラー状態を表示します。
• 装飾目的でダッシュボードのカードを並べることは避けます。

エディトリアルまたはコンテンツ

記事、出版物、ドキュメント、メディアを多く含むコンテンツに使用します。

• 読みやすい行の長さと、明確なタイポグラフィの階層を維持します。
• コンテンツ内のナビゲーションをわかりやすくします。
• メディアを意図的に配置します。
• リズムと余白を活用し、長時間の読書を支えます。

コマースまたはサービス

ショッピング、予約、申請、オンボーディング、取引サービスに使用します。

• 信頼性、明確さ、使い慣れたカテゴリ構成を優先します。
• 商品の探索、価格、手順、コミットメント、主要な操作を明示します。
• エラーを防ぎ、復旧手段を提供します。
• 重要なフローでは、気が散る要素を最小限に抑えます。

没入型または実験的なデザイン

リクエストと製品のコンテキストから、表現豊かな体験が妥当と判断できる場合にのみ使用してください。

• 明確なアートディレクションを確立し、段階的な機能強化を行ってください。
• アニメーションや高度なエフェクトは選択的に適用してください。
• モーションを抑える設定に対応した動作を完全に用意してください。
• モバイル、タッチ、キーボードでも使いやすい代替手段を維持してください。

プリローダー、スムーズスクロールライブラリ、カスタムカーソル、マグネティックボタン、パララックス、固定セクション、横スクロールによる演出、WebGL、GSAP、Lenis、Framer Motion、React Three Fiberは、任意の手法であり、品質要件ではありません。デザイン目標を実質的に支え、アクセシビリティ、パフォーマンス、保守にかかるコストをプロジェクトが負担できる場合にのみ導入してください。

普遍的な品質ルール

目的、階層、コンテンツ

• ページの目的と主要なアクションを明確にしてください。
• 論理的な読み順と、なじみのあるインタラクションパターンを維持してください。
• 実際の製品画面に合ったコンテンツを作成してください。プロンプトの文言やデザインに関する説明をUIに入れないでください。
• 各セクションや領域に明確な役割を持たせてください。
• 複雑さが必要な場合は、段階的開示を使用してください。
• 指標、推薦文、主張、在庫情報、ユーザーデータを捏造しないでください。
• 可能であれば破壊的なアクションを取り消せるようにし、それができない場合は確認と復旧の手段を設けてください。

視覚的な一貫性と独自性

• タイポグラフィ、余白、色、画像、形状、動きから、一貫したシステムを構築してください。
• 汎用テンプレートや、タスクの妨げになる装飾よりも、役立つ独自性を優先してください。
• 視覚的な複雑さは意図的に取り入れ、情報、操作性、階層、雰囲気を加えない要素は取り除いてください。
• カードは、意味のあるグループ化、包含、またはインタラクションにのみ使用してください。
• 60-30-10の配色ルールは、任意のパレットバランスの目安として扱い、普遍的なルールとは見なさないでください。
• 画像を中心とするデザインでは、意味を伝え、読みやすいオーバーレイを支え、ブランドとコンテンツに合う画像を選んでください。
• 動きは適切な範囲に収め、目的を持たせ、インタラクションの設計方針に沿って一貫させてください。

アクセシビリティの基本ライン

WCAG 2.2 レベル AAを基本ラインとして使用してください。規範的な要件と、より強い推奨事項を区別してください。

規範的な基本ライン

• ARIAよりもセマンティックHTMLを優先してください。
• 正確なアクセシブルネームと説明を用意してください。
• すべての機能をキーボードで操作可能にし、論理的で視認できるフォーカスを設け、キーボードトラップを作らないでください。
• ダイアログ、削除フロー、一時的なオーバーレイの後にフォーカスを復元してください。
• ラベル、説明、入力検証エラー、ステータス通知を、それらが示すコントロールや領域に関連付けてください。
• 通常のテキストでは少なくとも4.5:1、大きなテキストでは3:1のテキストコントラストを確保し、WCAGが求める非テキストコントラストも3:1以上にしてください。
• 色だけで意味を伝えないでください。
• コンテンツや機能を失わずに、リフロー、200％のテキストサイズ変更、ズームに対応してください。
• ポインターのターゲットは、少なくとも24 × 24 CSSピクセルにするか、間隔、インライン表示、同等の操作手段、ユーザーエージェント、または不可欠な表示といった、該当するWCAG 2.2 AAの例外を満たしてください。
• 製品で必要な場合は、タッチ、マウス、キーボードに対応してください。
• 状態に応じた遷移を壊す一律のルールは避けながら、モーションを抑える設定を尊重してください。
• 重要な情報やアクションを、ホバー時にしか表示されない状態にしないでください。
• 読み込み中、空、エラー、無効、成功の各状態を認識でき、理解できるようにしてください。

より強い推奨事項

• レイアウトが許す場合は、頻繁に使う操作、リスクの高い操作、タッチが主となる操作に、44 × 44 CSSピクセルのターゲットを優先してください。これはWCAG 2.2 AAの最小要件である24ピクセルよりも強い基準であり、強化されたターゲットサイズの達成基準に沿っています。
• 重要または複雑なワークフローでは、実際のスクリーンリーダーを使ってテストしてください。
• 複雑なウィジェットにはWAI-ARIA Authoring Practices Guideを使用し、サンプルをそのまま本番用コードとして扱わずに、実装を検証してください。

タスクにフォーム、ダイアログ、複雑なウィジェット、破壊的なアクション、密度の高いデータ、またはアクセシビリティレビューが含まれる場合は、アクセシビリティチェックリストをお読みください。

レスポンシブ対応と適応的な動作

デバイス名だけでなく、コンテンツと利用可能なスペースを基準に設計します。

• 狭いモバイル幅、広めのモバイルまたはタブレット幅、デスクトップ幅で確認します。
• ズームや拡大テキスト、粗いポインターと細かいポインター、キーボードのみでの操作を確認します。
• 長いコンテンツ、コンテンツがない場合、ローカライズによるテキストの拡大をテストします。
• 領域が縦に積み重なったり再配置されたりしても、読み上げ順序、優先度、コントロールを維持します。
• 必須のブレークポイントを大量に設けないでください。コンテンツやインタラクション上、実際に必要な箇所にブレークポイントを追加します。
• 狭い画面のスクリーンショットをすっきり見せるためだけに、不可欠な機能を隠さないでください。

パフォーマンスとレジリエンス

アプリケーションの測定が可能な場合は、現在の Core Web Vitals の「良好」目標値を運用上の目標として使用します。

• LCP は 2.5 秒以下。
• INP は 200 ミリ秒以下。
• CLS は 0.1 以下。
• フィールドデータがある場合は、フィールドの結果を 75 パーセンタイルで評価します。

測定せずにこれらの目標を達成したと主張しないでください。ラボでの観察結果とフィールドでの証拠を区別します。

• 画像、フォント、クライアント JavaScript、サードパーティコード、アニメーションの依存関係に予算を割り当てます。
• メディアの寸法をあらかじめ確保し、読み込み時の遷移を安定させます。
• 適切な場合はアニメーションに transform と opacity を優先し、不要なレイアウト処理やスクロールの妨げを避けます。
• プログレッシブエンハンスメントを採用し、オプションのメディア、スクリプト、エフェクトに問題が発生しても、主要なタスクを維持します。
• 必要に応じて、読み込みの遅さ、オフライン、古いデータ、再試行時の動作を検証します。

インタラクションと状態の網羅性

ユーザーが実際に遭遇する状態をモデル化します。機能に応じて、次の状態をカバーします。

• 初期、読み込み中、スケルトン、段階的な表示の各状態。
• 空、結果なし、フィルター適用後に空、初回利用の各状態。
• 成功、一部成功、古い状態、オフライン、再試行の各状態。
• 検証、権限、認証、サーバーエラー。
• ホバー、フォーカス、アクティブ、選択済み、無効、処理中の各コントロール。
• 破壊的な操作に対する確認、キャンセル、取り消し、復旧。

状態遷移を理解しやすくします。意味のある非同期の変更を通知し、重複送信を防ぎ、復元可能なユーザー入力を保持し、処理が成功する前に成功を表示しないでください。

デザインシステムと保守性

• 確立されたコンポーネント、スペーシング、タイポグラフィ、カラー、インタラクションのトークンを再利用します。
• トークンによってばらつきを抑えたり、繰り返し使うテーマやコンポーネントをサポートしたりできる場合は追加します。小規模で独立した領域に、正式な多階層トークンアーキテクチャを必須としないでください。
• 生の値の重複は避けますが、このスキルの要件を満たすためだけにアプリケーション全体をリファクタリングしないでください。
• 明示的に置き換えが対象となっていない限り、既存のブランドとコンポーネントの契約を維持します。
• フレームワークの仕組みは、それを担当する React、Next.js、Vite、JavaScript、Tailwind、Figma、Stitch、またはテストのスキルで扱います。
• 実装例は簡潔で、構文的に有効であり、概念的に正しく、実質的に役立つものにします。

コンポーネントレビューの評価基準

React、Next.js、Vite、その他のフロントエンドスタックでコンポーネントを承認する前に、次の簡潔な評価基準を適用してください。

1. 契約とデータの所有権： プロパティ、イベント、状態、副作用、バリデーション、エラー、所有権の境界が明確です。
2. 状態の網羅性： 関連する読み込み中、空、エラー、成功、無効、権限、古いデータ、レスポンシブの各状態が用意されています。
3. アクセシビリティと入力方法： セマンティクス、名前、キーボード操作、フォーカス、コントラスト、タッチ、ポインター、動きを抑える設定が基本要件を満たしています。
4. 視覚的な階層と作り込み： タイポグラフィ、余白、色、画像、情報密度、動きがコンポーネントの役割を支えています。
5. レスポンシブ動作： コンテンツの再配置によって、切り取り、操作の消失、順序の崩れ、正当な理由のない非表示が発生しません。
6. パフォーマンスへの影響： レンダリング、バンドルサイズ、メディア、ハイドレーション、アニメーションのコストが把握され、妥当な範囲に収まっています。
7. プロジェクトとの一貫性： プロジェクトのシステムを再利用し、避けられる並行パターンを持ち込んでいません。
8. レンダリング結果の検証： 実際のコンポーネントを、代表的な画面幅、状態、入力方法で確認しています。

リソース

• アクセシビリティチェックリスト：WCAG 2.2 AA に関する重点的なチェックと、状態ごとの検証。
• コントラストチェッカー：個別の色またはファイルを対象とした、標準ライブラリによるローカルな色のコントラスト計算。

クライアント間のポータビリティ

このスキルは、GitHub Copilot、Claude Code、Codex で利用できるように作成されています。

• GitHub Copilot：フォルダーを Copilot から見えるスキルパスに配置するか、フォルダーの検出ができない場合はワークフローをプロジェクトの指示にまとめてください。
• Claude Code：フォルダーをローカルのスキルディレクトリまたは互換性のあるプラグインソースに配置してください。
• Codex：フォルダーを $CODEX_HOME/skills/frontend-design にインストールまたは同期し、大きな変更を加えた後は Codex を再起動してください。

MCP の利用可否とフォールバック

優先する MCP サーバー：特に必要ありません

• フォールバック用プロンプト：「MCP を使わずに Frontend Design スキルを使用してください。ローカルの指示、同梱リソース、標準のシェルまたはエディターツール、直接の検証を利用してください。結論を出す前に、根拠として使用した情報を示してください。」
• アクティブなホストで利用できない MCP 操作を使用したと主張しないでください。
• ローカルファイル、テスト、レンダリング結果、ログ、スクリーンショットをフォールバックの根拠として扱ってください。

アンチパターン

• ユーザー、タスク、コンテンツ、制約を理解する前に、流行のスタイルを選ぶ。
• 確立されたデザインシステムを自動的に置き換える。
• ランディングページのヒーロー、カード、グラデーション、ガラス風デザイン、ダークテーマを普遍的なデフォルトとして扱う。
• 「プレミアム」な品質のために、コストの高いエフェクト、アニメーションライブラリ、カスタムカーソル、スムーズスクロール、3D を必須にする。
• 主要なタスクの妨げになる装飾的な UI を使用する。
• 偽のデータ、不完全な状態、アクセシビリティに対応していないコントロール、動作しない例、測定されていないパフォーマンスの主張を承認する。
• 静的なスクリーンショット、ソースコードの確認、自動スコアを、レンダリング動作全体を検証した証拠として扱う。

検証プロトコル

フロントエンド設計のワークフローが成功したと主張する前に、次を確認してください。

1. 合否：主要なモード、ビジュアル上の方針、コンテンツ計画、関連する制約が明確で、依頼に合致しています。
2. 合否：機能の正確性、WCAG 2.2 AA、有効なサンプル、レスポンシブな動作が、すべての必須条件を満たしています。
3. 合否：関連するコンポーネントとページの状態が実装されており、コンテンツに偽りがなく、障害から復旧できます。
4. 合否：実際にレンダリングされた結果を代表的な幅で確認し、キーボードと、関連するポインターまたはタッチ入力で検証しています。
5. 合否：可能な場合はパフォーマンスへの影響を測定し、それ以外の場合は未検証として報告し、憶測で判断していません。
6. 負荷テスト：長いコンテンツ、拡大テキスト、モーションの低減、遅いまたは失敗した依存関係、サポート対象の最も狭い幅で、主要なタスクを再度実行します。
7. 成功指標：すべての承認に、レンダリング、動作、テスト、または測定の証拠が示され、残っている制限が列挙されています。

関連スキル

• web-design-reviewer：実装後のブラウザーを使ったビジュアル QA とレスポンシブ表示の不具合診断に使用します。
• react-development：React 固有のコンポーネントアーキテクチャと実装に使用します。
• nextjs-development：Next.js のルーティング、レンダリング、データ、フレームワークの動作に使用します。
• vite-development：Vite の設定、ビルドの動作、アプリの統合に使用します。
• stitch-design：Stitch 固有の設計および実装ワークフローに使用します。
• figma-implement-design：実装で Figma を信頼できる唯一の情報源とする必要がある場合に使用します。