frontend-design

フロントエンドデザイン

明確で、そのテーマに即した視点を持つ、実際に動作するフロントエンドを作成します。そして、レンダリングされた UI でその成果を示します。

契約

• 批評、レビュー、デザイン計画の場合は、該当する製品を調査し、ファイルを編集せずに方針を報告します。
• ビルドや再設計の場合は、依頼の対象範囲内で必要な変更を行い、ローカルで非破壊的な検証を実施します。
• 明示されたユーザーの指示、提示された参考資料、リポジトリの指示、既存の製品の動作、ローカルのデザインシステムを最優先します。忠実性に関する要望は、このスキルの既定の方針より優先されます。
• 技術スタックと動作中の機能を維持します。依頼で必要とされない限り、フレームワークやデザインシステムの置き換え、依存関係の追加、新機能の考案は行いません。
• 再設計では、既存の特徴的なアートワークや有用な視覚的手がかりを維持します。置き換える前に、代替案でもそれらがアイデンティティ、理解、インタラクションに果たす役割が保たれることを確認します。
• アートディレクションに適している場合は、コードで作成したオリジナルの SVG またはストック画像を選びます。その他のメディアの生成は、依頼で必要とされる場合に限ります。
• テーマ、対象ユーザー、ページの目的が不足している場合は、正当化できる範囲で最小限の仮定を置きます。着手前にその仮定を伝えます。回答によって範囲やアイデンティティが大きく変わる場合に限り、確認します。

レイアウトとテーマの既定値

各ビルドを、特定の目的に合わせた単独のページとして扱います。ユーザーから指定がない限り、以下を既定値として適用します。

• デスクトップのブラウザーウィンドウ専用に構築します。モバイルレイアウトやレスポンシブレイアウトは追加しません。
• テーマは 1 つだけ作成します。2 つ目のテーマ、テーマ切り替え、prefers-color-scheme のバリエーションは追加しません。
• 色を選ぶ前に、システムの表示モードを確認します。システムがライトモードの場合のみ、ライトテーマを使用します。それ以外の場合はダークテーマを使用します。
• macOS では、defaults read -g AppleInterfaceStyle を実行します。ダークモードでは Dark が出力されます。ライトモードではキーが存在しないため、コマンドは失敗します。

既存の画面を変更する場合は、現在動作しているレスポンシブ表示とテーマの動作を維持します。ユーザーから依頼されない限り、新たな画面には適用しません。

ワークフロー

1. ページを描く前に製品を確認する

対象のルートまたはコンポーネント、周辺 UI、トークン、タイポグラフィ、アセット、依存関係、リポジトリの検証コマンドを調査します。以下を特定します。

• 具体的なテーマと対象ユーザー。
• 画面の主な目的とコンテンツの階層。
• 既存のビジュアル言語とインタラクションの慣習。
• 必要なビューポート、テーマ、状態、アクセシビリティの制約。

可能な限り、実際の製品コンテンツと提示されたアセットを使用します。コピーが不足している場合は、ユーザーがインターフェースを理解し、操作するために必要な内容だけを書きます。

2. アートディレクションを一つ定める

コーディングの前に、簡潔な方向性を定義します。

• 主旨： ビジュアルのアイデアを、題材と画面の役割に結び付ける一文。
• システム： 役割ごとのカラー・トークン、明確な文字の役割とサイズ、間隔と密度、意図的なレイアウトと配置の選択。
• シグネチャー： ドメインのオブジェクト、ワークフロー、データの形状、環境、言語から着想を得た、記憶に残る要素。
• リスク： 明確な理由を添えて、この要件に適した、あえて一般的な解決策から外れる選択を一つ。
• 動きとコピー： 動きが役立つ場面、インターフェースの語り口、抑制が重要な箇所。

既存のブランド上の制約に合わせ、この方向性を調整してください。別個のデザイン言語を作らないでください。ユーザーから方向性の選択を求められていない限り、選択肢やプロセスの説明は内部にとどめてください。

実装や大幅な再設計では、画像の使用をケースごとに検討してください。背景、セクション間の切り替え、注目箇所には、ストック写真、アートワーク、またはオリジナルの SVG を検討します。画像は、サイトの題材、雰囲気、またはコンテンツの階層を強化するときに限り使用してください。画像を使わないデザインも有効です。オリジナルの SVG モチーフを選ぶ、または作成する場合は、SVG design を読んでください。

ストック画像が方向性に合う場合は、$chromium-browser を使って Google または Unsplash を検索してください。画像を使用する前に、元のソースを開いて利用条件と、必要なクレジット表記を確認してください。検索結果だけでは、アセットの再利用許可があるとは判断できません。

画像とカラフルな背景は、ひとつの配色として組み合わせてください。相性のよい色、意図的なトリミング、テキストやコントロールの背後にある余白を選びます。無関係なサイトにも使えてしまうような、ありきたりなストック画像は避けてください。

3. デフォルトを疑う批評を行う

題材の入れ替えテストを適用します。題材を無関係なものに置き換えて頭の中で考えてみてください。そのまま変わらず使える主要な選択は、おそらくテンプレートのデフォルトです。その選択を見直すか、構造上適切である理由を説明してください。

すべてのビジュアル要素に役割を持たせてください。カード、ピル、グラデーション、番号、区切り線、大きな文字、分割型のヒーロー、イラスト、アニメーションは、装飾だけでなく、階層、機能、順序、または題材を伝える必要があります。表現力はシグネチャーに集中させ、周囲のシステムはそれを支えるようにします。

明確な境界は、機能上の要件です。グループ分けや所有関係をひと目で把握しやすくするなら、枠線やコンテナを使ってかまいません。デザインをフラットにしたり、ありきたりな印象を避けたりするためだけに、有用な境界を取り除かないでください。

具体的なパターンは、批評のきっかけとして扱い、絶対的な禁止事項にはしないでください。要件が裏付けていない場合は、クリーム色の背景、見出しの斜体アクセント、01/02/03 のセクションラベル、等幅フォントのラベル、ピル型のボタンを疑ってください。繰り返し使う装飾カード、シャドウ、セクション表示時のエフェクトにも、同じテストを適用します。要件や明確な機能に適している場合は、これらの選択を維持してください。最初のレンダリング後には、ほかにも検討されていないデフォルトがないか特定し、見直してください。

4. 実際の体験を構築する

• 新しいプリミティブを導入する前に、既存のコンポーネント、トークン、スタイリングのアーキテクチャ、依存関係のバージョンに従います。
• 用途に合わせて構成を調整します。業務用ツールでは、情報をひと目で把握でき、繰り返しの操作を効率よく行えることを重視します。編集やマーケティング向けの画面では、より表現豊かなストーリー展開を取り入れてもかまいません。
• 最初に表示される画面で、サービスのアイデンティティと主な目的の両方を伝えます。アプリケーションやツールでは、依頼されていないランディングページで包まず、実際の作業画面を表示します。
• プロジェクト、レコード、独立したパネルは、視認できる境界線、面のコントラスト、余白を使って区別しやすくします。描画後に少なくとも同程度に境界が明確になる置き換えがない限り、役立つグループ境界を維持します。
• 関連するオブジェクトや繰り返し表示されるオブジェクトにはカードを使います。入れ子のコンテナは、実際の階層を伝える場合にのみ使用します。
• ディスプレイ、本文、ユーティリティの各用途に合わせて、意図的にタイポグラフィを選びます。まず利用可能なフォントを使います。目新しさだけを理由にフォントの依存関係を追加しないでください。これらの用途には、1〜2種類のフォントファミリーで対応できます。
• 本文は読みやすく保ち、通常は1行あたり80文字未満にします。書体とコンテンツに合わせて、文字幅と行の高さを調整します。
• インターフェースの文言はユーザーの視点で書きます。具体的な名詞、能動態の動詞、一貫したアクション名、文頭のみ大文字にする表記、有用な空状態とエラー状態を使います。コントロールのラベルには、その結果を明記します。
• おなじみのコントロールとプロジェクトのアイコンライブラリを使います。アイコンのみで、なじみのないコントロールには、適切にアクセシブルな名前と、視認できるツールチップを付けます。
• モーションは任意です。使う場合は、階層を説明したり、有用な操作フィードバックを与えたりする箇所に絞ります。動きを抑える設定を尊重し、アニメーションがなくても体験が明確であることを確認します。
• 対象とするあらゆる幅で、要素の重なり、切り抜き、読みにくい折り返し、レイアウトのずれを防ぎます。既定の対象幅はデスクトップの1種類です。ユーザーがレスポンシブ対応を求めた場合は、デバイス名ではなくコンテンツに基づいてレスポンシブな制約を設け、狭い幅と広い幅の両方を含めます。
• 画像には、焦点を保ちながら不要なダウンロード容量を抑えられる、レスポンシブなトリミングと配信サイズを選びます。意味のある画像には有用な代替テキストを付け、装飾画像の代替テキストは空にします。
• セマンティックな構造、キーボード操作、視認できるフォーカス、十分なコントラストとターゲットサイズを維持します。プロジェクトのアクセシビリティ基準がさらに厳しい場合は、それに従います。
• セレクターの詳細度とコンポーネントの所有関係を予測しやすく保ちます。余白や状態を決めるために、競合するセレクターや壊れやすいカスケード順序に頼らないでください。

5. 描画、確認、修正

リポジトリで必須とされるチェックと、変更した動作を証明するために必要な最小限の追加チェックを実行します。影響を受ける範囲に応じて、フォーマット、lint、型チェック、テスト、ビルドから選択します。編集や未解決の懸念によって無効にならない限り、合格済みの検証結果を再利用します。その後、このセッションで利用できる場合は chromium-browser スキルを使って描画結果を確認します。利用できない場合は、ホストの DevTools／ブラウザツールを使います。DevTools ブラウザツールが利用できる場合は、Computer Use や場当たり的な Playwright スクリプトに切り替えないでください。

変更内容に応じて確認マトリクスの規模を調整します。リポジトリの指示により、複数ビューポートの確認を省略するなど、ビューポートや状態のマトリクスを縮小できる場合があります。その指示に従ってください。そうした指示がない場合、既存 UI への小規模な編集では、代表的なビューポートで変更した状態のみを確認すれば十分です。新規の画面、または大幅に再設計した画面では、単一テーマのデスクトップビューポートと、変更したすべての操作および状態を確認します。レスポンシブ動作や複数のテーマをユーザーが求めている場合は、代表的な狭いビューポートと広いビューポート、および指定された各テーマを追加します。リポジトリに自動テストがある場合、動作の検証にはそれを使います。表示、レイアウト、テーマに関する確認にはブラウザを使います。

描画結果について、コンテンツの階層、グループの境界、対象の具体性、アセットの読み込み、はみ出し、重なり、切り詰め、コントラスト、フォーカス、ホバー、動き、空およびエラー状態、対象範囲内のテーマのバリエーションを確認します。テストした幅と各テーマで、各項目が属するグループと各グループの範囲が明確にわかることを確認します。結果を依頼内容とアートディレクションに照らし合わせます。目に見える不具合を修正し、役割を十分に果たさない要素は削除します。

描画が可能な環境で、ソースコードの確認だけをもって表示を検証したと主張しないでください。環境上 UI を描画できない場合は、その制約を明示し、実際に検証した内容を正確に報告します。

完了

完了には、依頼された成果物またはコード、実装に反映された対象に即した方向性、関連するローカルチェックの合格、そしてツールが利用できる場合は描画結果の確認記録が必要です。方向性を一文で述べ、実行したチェックと確認したビューポートを報告し、残る制約があれば記載します。

ビルドを終える際は、### ✨ Built: <surface>、🎨 Direction — <one sentence>、### 🧪 Verification を含めます。複数の状態を確認した場合は、簡潔なビューポート／状態／結果の表を使います。スクリーンショットや成果物がある場合は、リンクします。未解決事項がある場合に限り、### ⚠️ Remaining を追加します。エージェントの報告に絵文字や ASCII 装飾を使うことが許可されていても、依頼やデザインシステムで指定されていない限り、製品 UI の文言、スナップショット、ソースコードにそれらを追加してはなりません。