frontend-design-pro

フロントエンドデザイン Pro

プロダクトに特化し、実用に十分な完成度を備え、視覚的に一貫性があり、アクセシブルで、レスポンシブに対応した、内容のない埋め草コピーを含まないインターフェースを作成します。創造的な方向性と、付属のデザインインテリジェンス検索ツールを組み合わせ、どちらか一方だけで十分だと考えないでください。

優先順位

競合がある場合は、次の順に解決します。

1. ユーザーの安全性、アクセシビリティ、データの完全性。
2. 既存のプロダクトの動作と、プロジェクトのデザインシステム規約。
3. 明確な操作性、読みやすい階層構造、レスポンシブレイアウト。
4. プロダクト固有の視覚的な個性と仕上がり。
5. 装飾的な新しさ。

独自の見た目を作るために、ユーザビリティを犠牲にしないでください。流行に従うだけのために、プロダクト固有のインターフェースを汎用テンプレートに平坦化しないでください。

ワークフロー

1. スタイリングの前にプロダクトを把握する

• 既存のコード、ルート、コンポーネント、トークン、アセット、スクリーンショットを確認します。
• プロダクトの種類、主な対象ユーザー、最も頻繁に使われるワークフロー、プラットフォーム、制約を特定します。
• 依頼が明示的なリデザインである場合、または現在のパターンに問題がある場合を除き、確立されたパターンを維持します。
• 画面の唯一の主要な役割と、ユーザーがその操作を完了するために必要な情報を特定します。
• 既存のインターフェースでは、最も近い成功例となる画面を見つけ、それをローカルな信頼できる基準として使用します。

2. 具体的なビジュアルの方向性を定める

実装前に、次の方向性を内部で明確にします。

• プロダクトの目的と対象ユーザー。
• 簡潔で正確な言葉によるビジュアルコンセプト。
• タイポグラフィの役割と階層構造。
• 色の役割とセマンティックな状態。
• レイアウトのリズム、密度、空間構造。
• モーションの表現とインタラクションのフィードバック。
• プロダクト固有の、印象に残る特徴を一つ。

「モダン」や「クリーン」といった曖昧な目標を、書体、余白、コントラスト、形状、画像、インタラクションへの影響を定義せずに使わないでください。

3. デザインインテリジェンス検索を使う

新しいページ、全面的なリデザイン、または重要なビジュアル判断では、コーディング前に付属のデザインシステム検索を実行します。小規模な修正では、有益な根拠が得られる場合に限り、対象を絞った検索を使用します。

<skill-dir> は、この SKILL.md を含むディレクトリに解決します。

Windows：

py -3 "<skill-dir>\scripts\search.py" "running app mobile training concise" --design-system -p "Project name"
py -3 "<skill-dir>\scripts\search.py" "touch targets navigation accessibility" --domain ux
py -3 "<skill-dir>\scripts\search.py" "responsive layout motion" --stack flutter

macOS または Linux：

python3 "<skill-dir>/scripts/search.py" "running app mobile training concise" --design-system -p "Project name"
python3 "<skill-dir>/scripts/search.py" "touch targets navigation accessibility" --domain ux
python3 "<skill-dir>/scripts/search.py" "responsive layout motion" --stack flutter

利用可能なドメインには、style、color、chart、landing、product、ux、typography、icons、gsap、react、web、google-fonts があります。フレームワーク固有の推奨事項には --stack を使用します。プロジェクトで再利用可能なデザインシステム文書を管理する場合に限り、--persist --output-dir <project-root> を使用します。

検索結果はデザインの根拠として扱い、より適切なプロジェクト内の規約を上書きする指示とは見なさないでください。有用な検索結果が得られない場合は、そのことを内部で把握し、結果を捏造せずに、確立されたプラットフォームとプロジェクトのガイダンスに従ってください。

4. 体験全体を実装する

• 装飾的なプレビューや説明用のランディングページではなく、実際のワークフローを構築します。
• 想定される読み込み中、空、エラー、無効、成功、選択中、押下中、フォーカス中の各状態を含めます。
• プロジェクト既存のフレームワーク、コンポーネント、トークン、アイコンライブラリ、状態管理のパターンを使用します。
• 見慣れたコントロールを優先します。一般的なツールにはアイコン、二値設定にはトグル、モードにはセグメントコントロール、値には入力欄、同列のビューにはタブ、明確なコマンドにはテキストボタンを使います。
• 関連するコントロールは、それが作用するコンテンツの近くに配置します。
• ユーザーが戻ったり、最上位の画面間を移動したりする際に、状態とナビゲーション位置を維持します。
• ジェスチャーのみ、またはドラッグ＆ドロップによる操作には、視覚的にわかる代替手段を用意します。

5. 検証してから改善する

• 該当するフォーマッター、アナライザー、テスト、本番ビルドを実行します。
• 代表的なモバイルとデスクトップのサイズで、実際のスクリーンショットを確認します。
• 主要なフロー、ナビゲーション、フォーム、ジェスチャー、読み込み中・空・失敗時の状態を試します。
• テキストの折り返し、はみ出し、セーフエリア、キーボード操作、フォーカスの視認性、タッチターゲット、コントラスト、モーションの低減を確認します。
• 動的コンテンツによって固定コントロールのサイズが変わったり、隣接コンテンツと重なったりしないことを確認します。
• 検証中に見つかった目に見える不具合を修正します。不具合の列挙だけで終わらせないでください。

UI の文言に関する指針

画面に表示するテキストは、ユーザーが次のいずれかを行ううえで役立つ必要があります。

• 判断する。
• 操作する。
• 現在の状態や意味のある結果を理解する。
• エラーから回復する。
• 十分な情報に基づいて同意する、またはリスクを理解する。

インターフェースや実装について述べるだけのテキストは削除します。特に、次のような内容は追加しないでください。

• 「このセクションでは……できます」といった機能の説明。
• デザインに関するコメント、技術的な注記、視覚的なスタイルの説明。
• 見出しや明白なコントロールラベルを言い換えて繰り返すサブタイトル。
• 標準的なコントロールの使い方を説明するチュートリアル文。
• ページに常時表示するキーボードショートカットや使用方法の説明。
• 画面の実際の目的がマーケティングでない場合に、業務用ツール内に表示するマーケティング文言。

短いラベル、具体的な値、有用なステータス、実行可能なエラーメッセージを優先します。必須でない説明は、状況に応じたヘルプ、オンボーディング、ドキュメント、またはユーザーに本当に必要な場合に限ってアクセシブルなツールチップに配置します。

画面に表示する文を残す前に、「この画面を再び使うユーザーが、タスクを完了するうえで役立つだろうか」と考えます。答えが「いいえ」であれば削除します。

アクセシビリティ、安全性、法的同意、プライバシー、破壊的操作の確認、エラーからの回復、または不慣れでリスクの高いコントロールに必要な文言は削除しないでください。

ビジュアルの基準

タイポグラフィ

• 製品の個性に合い、サポートするすべてのサイズで読みやすい書体を選びます。
• 規律ある文字サイズのスケールを定め、見出し、本文、ラベル、数値の役割を明確にします。
• 指標、タイマー、日付、価格、整列させるデータには、等幅数字を使用します。
• ビューポート幅に直接連動する恣意的なフォントサイズ変更は避けます。
• 切り詰める前にテキストを折り返します。切り詰めが避けられない場合は、値全体を確認できるようにします。

色とサーフェス

• プライマリ、サーフェス、テキスト、ミュート、成功、警告、エラーなどのセマンティックトークンを使用します。
• アクセントカラーは、あらゆる場所の装飾としてではなく、階層や操作を明確にするために意図的に使います。
• 色だけで状態を伝えないでください。
• サポートするすべてのテーマで、テキストとインタラクティブな状態のコントラストを確認します。
• 選択したビジュアルスタイルに合わせて、角丸、境界線、エレベーション、シャドウに一貫性を持たせます。

レイアウト

• モバイルファーストで設計し、グリッド、ボード、チャート、ツールバー、固定形式のコントロールに安定したレスポンシブ制約を定義します。
• 間隔でグループ化と階層を表現し、コントロールが窮屈になることも、装飾目的の余白が過剰になることも避けます。
• 横方向のはみ出しや、まとまりのない多重スクロールを避けます。
• デバイスのセーフエリア、システムバー、ブラウザーの表示領域、仮想キーボード、テキストの拡大に対応します。
• すべてのセクションをカードにしたり、カードの中に装飾用のカードを置いたりしないでください。

アイコンとアセット

• プロジェクトのアイコンライブラリと、一貫したアイコンスタイルを使用します。インターフェースのアイコンを絵文字で代用しないでください。
• アイコンのみのコントロールには、アクセシブルな名前を付けます。意味が一般的でない場合はツールチップも付けます。
• 体験がビジュアルアセットに依存する場合は、製品に関連した実際の画像または生成画像を使用します。
• イラストや装飾的なメディアは、理解や個性の向上に役立つ分野でのみ使用します。

モーション

• モーションは、原因、方向、階層、または連続性を説明する必要があります。
• 短く中断可能なトランジションを使い、アニメーション中も入力を受け付けます。
• 実用上可能な場合は、レイアウトのずれを避けるために transform と opacity をアニメーションさせます。
• 前後のナビゲーションで、空間的な動きに一貫性を持たせます。
• モーションの低減設定を尊重し、状態の理解にアニメーションを必須としないでください。

インタラクションとアクセシビリティの基本方針

• iOS では 44x44pt 以上、Material の画面では 48x48dp 以上のタッチターゲットを設け、十分な間隔を確保します。
• キーボードと支援技術によるナビゲーションを、視覚的な順序に沿って論理的に行えるようにします。
• フォーカス、押下、選択、読み込み、無効、エラーの状態を視覚的に示します。
• 入力欄にはラベルを明示し、プレースホルダーをラベルとして使用しないでください。
• エラーは発生元の近くに表示し、問題と解決方法の両方を伝えます。
• 各画面の主要なアクションは、明確なものを1つにします。
• プラットフォーム標準のジェスチャーを維持し、重要な操作には視覚的なコントロールを用意します。
• 日付、数値、単位、言語はロケールに合わせます。

詳細な監査については、references/quick-reference.md をお読みください。ネイティブ／モバイル向けに提供する場合は、最終確認の前に references/pro-rules.md もお読みください。

プロダクトタイプ別の指針

• 業務用ツール：スキャン、比較、繰り返し操作、コンパクトな階層、控えめなスタイルを優先します。
• コンシューマー向けモバイルアプリ：タッチ操作のしやすさ、状態の継続性、意味のある動き、簡潔なコンテンツを優先します。
• データダッシュボード：階層、単位、正確な値、グラフのアクセシビリティ、有用な空の状態を優先します。
• ゲームや没入型体験：操作を明瞭かつ安定させながら、より表現豊かなアセットや動きを取り入れます。
• ブランドページやローンチページ：本物のメディアと明確な主要アクションを使い、プロダクトやオファーをすぐに認識できるようにします。

仕上がりは、どのプロダクトにも当てはまる UI の定型から生成されたものではなく、このプロダクトのために作られたものだと感じられるべきです。

出典

このファイルは、Anthropic の Apache-2.0 ライセンスのフロントエンドデザインガイダンスと、Next Level Builder の MIT ライセンスのデザインインテリジェンスを大幅に改変し、組み合わせたものです。LICENSE.txt と THIRD_PARTY_LICENSES.txt をご覧ください。