astra-frontend-design

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

プロダクトに役立ち、コードベースに適合し、実際のブラウザーで確認しても問題のない、一貫性のある独自のインターフェースを構築します。ユーザーが計画や批評のみを求めている場合を除き、依頼されたフロントエンド作業は実装とビジュアル検証まで行います。

ユーザーの依頼内容とリポジトリにすでに確立されているプロダクト上の制約を優先します。ここに記載されているガイダンスは、定型的なデザインルールではなく、判断の基準として扱ってください。テーマやワークフローに適しているなら、よくあるパターンを使ってもかまいません。

タスクに応じて参照先を選ぶ

現在のタスクに必要な参照資料のみを読みます。

タスク	参照資料
ランディングページ、ポートフォリオ、エディトリアル、ブランド、または表現性の高いサイト	art-direction.md
ダッシュボード、SaaS プロダクト、管理画面、フォーム、または業務ツール	product-ui.md
既存インターフェースの再設計またはモダナイゼーション	redesign.md
参考資料としてのスクリーンショット、Figma フレーム、画像、またはサイト名	reference-to-code.md
目立つアニメーション、スクロール動作、またはインタラクションの演出	motion-and-interaction.md
レビュー、仕上げ、アクセシビリティ監査、または最終検証	quality-gates.md
実装ではなく再利用可能なプロンプト	prompt-recipes.md
モデルや改訂版ごとのスキル品質の比較	evaluation.md

デザインの前提を明確にする

表示される UI を変更する前に、対象のルート、関連コンポーネント、グローバルスタイル、アセット、依存関係のマニフェストを確認します。新しい方向性が明示的に求められていない限り、プロジェクトのフレームワーク、コンポーネントの基本要素、デザイントークン、アイコンの種類、インタラクションの規約を再利用します。

利用可能なコンテキストから、簡潔なデザインの見立てを導きます。

• テーマ、対象ユーザー、画面の主な役割
• ビジュアルの特徴と印象に残るアイデア
• 情報の密度と動きの度合い
• 維持すべきコンテンツ、動作、ブランド、アクセシビリティ上の制約

妥当な仮定に基づいて進めます。答えによってプロダクト、ブランド、またはインタラクションのモデルが大きく変わる場合に限り、焦点を絞った質問を1つだけします。実装が認められている依頼に対して、実現案の説明だけで終わらせてはいけません。

複数画面のプロダクトや継続的な再設計では、長期的に維持すべきプロダクトの事実と、ビジュアルの方向性を分けて記録します。リポジトリに同等の資料がない場合は、PRODUCT.template.md と DESIGN.template.md を出発点として使用します。実際の方向性のずれを防ぐ効果がない限り、小規模で単発の変更にプロセス文書を作成してはいけません。

スタイリングの前に構成を決める

装飾的な詳細を選ぶ前に、階層、コンテンツの順序、レスポンシブな動作、インタラクションの状態を決めます。各画面のビジュアルには明確な軸を1つ設けます。その軸を支える部分には表現の複雑さを使い、それ以外は節度を保ちます。

生成物らしく見える慣習は、無検討のデフォルトとして使われる場合にのみ注意が必要です。たとえば、同じ大きさのカードを並べる、装飾的なグラデーションを使う、あらゆる要素をピル形状にする、すべての見出しの上にアイブロウを置く、根拠なく等幅フォントのラベルを使う、どこでも使える文言にする、すべての要素に動きを付ける、といったものです。依頼内容に適しているなら使ってもかまいません。そうでなければ、テーマに即した、より具体的な解決策を選びます。

事実に基づいたコンテンツを使用します。顧客名、推薦文、実績の主張、精密な数値、プロダクトの機能を捏造してはいけません。状態を示すために現実的なデータが必要な場合は、サンプルデータであることを明記します。

実際に使える体験を実装する

• まず役立つ画面を作成します。ユーザーがアプリ、ツール、ゲーム、ダッシュボードを求めている場合、マーケティング用の外枠で代用しないでください。
• 想定される操作要素やフローを機能させます。関連する読み込み中、空、エラー、成功、無効、オーバーフローの各状態を含めてください。
• 装飾的なプレースホルダーよりも、実際のプロジェクトのアセットや関連する画像を優先します。結果を実質的に改善でき、利用可能なツールで対応できる場合に限り、アセットを作成または取得してください。
• パッケージをインポートする前に、依存関係のマニフェストを確認します。現在のスタックに必要な機能が備わっていない場合に限り、依存関係を追加してください。
• セマンティック HTML、キーボード操作への対応、視認できるフォーカス、読みやすいコントラスト、テキストのリフロー、動きを減らす設定への対応、レスポンシブレイアウトを、切り離されたチェックリストではなく実装に組み込みます。

視覚的な確認を繰り返して仕上げる

関連する最小限のビルド、Lint、動作確認を実行します。必要に応じてアプリを起動し、代表的なデスクトップ幅とモバイル幅で実際のインターフェースをキャプチャして、ソースコードだけを信頼せず、画像を確認します。階層、フレーミング、コンテンツの収まり、配置、コントラスト、操作へのフィードバック、コンソールエラーを確認します。視覚上または機能上の不具合を修正し、重大な問題がなくなるまで、影響する確認を繰り返します。

利用可能な場合は、プロジェクト既存のブラウザーまたはエンドツーエンドのツールを使用します。スクリーンショットを撮るだけのために、大規模なテストスタックを追加しないでください。変更内容に応じて検証の規模を調整します。トークンの微調整に必要な確認は、レスポンシブページやアニメーションを伴う操作ほど多くありません。

引き継ぎでは、まず今すぐ使えるものを伝えます。選択したビジュアルの方向性と検証結果を簡潔に述べ、ユーザーから求められない限り、設計上の検討を一つひとつ説明しないでください。

エージェントオーケストレーションと組み合わせる場合

このスキルの設計判断と実装判断は、能力のあるフロントエンド実装者に委ねてください。範囲が明確でブラウザーでテスト可能な構築では、小規模なコーディネーターが、元の製品要件と参考資料を1人のAstraワーカーに渡し、実行中の結果をテストして、スクリーンショットと具体的な不具合を同じワーカースレッドに返す方法もあります。コーディネーターは、規範的なレイアウト手順でワーカーの視覚的判断を置き換えてはいけません。品質が最優先の場合、作業の規模が大きい場合、または受け入れテストが難しい場合は、Astraに直接依頼するか、Astra主導の計画を使用してください。ユーザーと環境が許可する場合に限り委任し、必須の確認項目を明示的に割り当ててください。

参考資料

このスキルは、Astraを中心に独自にまとめたものです。出典と適用時の判断については、research-basis.mdを参照してください。