design-variations

デザインのバリエーション

ブラウザーを、一時的な意思決定の場として使います。本番実装の前に方向性を分岐させ、人に選択または組み合わせてもらった後、選ばれた案だけを通常のAgentic Design Systemの構築・レビュー工程に進めます。

適用条件

リクエストで、新しいページ、コンポーネント、機能、またはインタラクションの選択肢、バリエーション、コンセプト、モックアップ、別の方向性、あるいは方向性を決めるための支援が求められている場合に、このスキルを使います。

次の場合は使いません。

• 方向性がすでに決まっている
• タスクがバグ修正、文言の編集、または機械的な仕上げである
• 形を評価する前に、実データとの接続が必要である
• 違いが単一のトークンまたはスタイル値だけである
• 指定された参考資料に忠実に実装するよう求められている

希望するビジュアルの参考資料が重要な場合は、visual-reference-calibrationを使い、参考にする要素を見極めます。過去の回答を再利用し、二度目のヒアリングは追加しません。

ワークフロー

1. 判断事項を明確にします。

   • ユーザー、タスク、制約、既存の画面、各バリエーションで判断しやすくする内容を示します。
   • プロジェクトのベースライン、コンポーネント、トークン、実際のドメイン用語を確認します。
   • 変えないコンテンツを特定し、すべてのバリエーションで共通にする状態を明示します。

2. バリエーションの数を決めます。

   • 実際の選択を解決できる最小限の選択肢を使います。多くの場合、2つで十分です。
   • 数を満たすためではなく、実質的に異なる主張がある場合にのみ、選択肢を増やします。
   • ユーザーが明示した数があれば、それに従います。

3. 異なる主張に名前を付けます。

   • 各方向性には、そのアイデアを表す名前を付けます。「バージョン1」や「オプションB」といった名前は使いません。
   • 構造、階層、密度、インタラクションモデル、メタファー、情報の流れなど、意味のある軸を変えます。
   • コンテンツ、データ、状態、ビューポート、ユーザーの基本的な目的は同一に保ちます。
   • 色の変更、フォントの差し替え、余白の調整だけでは、別の方向性とはみなしません。

4. 使い捨てのブラウザー成果物を1つ作成します。

   • 単独で比較できる場合は、assets/variations.htmlを使います。
   • 実装済みアプリを比較する場合は、別のバリエーション／レビューループではなく、この判断を支える手法としてbrowser-variant-workflowを使います。
   • タスクでプロジェクトのアセットが必要でない限り、自己完結型にします。
   • アクセシブルな切り替え機能を使い、一度に1つの完成した方向性だけを表示します。
   • 各方向性を、文脈の中で評価できる程度に一貫性のあるものにします。
   • 本番用の依存関係、機能フラグ、長期間維持するバリエーション用アーキテクチャは追加しません。

5. ブラウザーでレビューします。

   • 関連するデスクトップとモバイルの幅で成果物を表示します。
   • 状態とビューポートを揃えて各方向性をキャプチャします。
   • はみ出し、キーボード操作、ラベル、フォーカス、基本的なコントラストを確認します。
   • 既存のADSレビューを使い、ユーザーの目的、情報の順序、ビジュアルの方向性、動作を比較します。有用な選択の代わりに、複合的な自己評価スコアを使ってはいけません。
   • コンセプトとインタラクションモデルに基づいて、概念上の違いを評価します。ピクセルの違いだけでは、意味のある分岐の根拠になりません。

6. 判断を提示します。

   • 推奨する方向性を最初に示し、その理由を説明します。
   • すべての方向性について、意味のあるトレードオフを要約します。
   • 人による判断が引き続き必要な場合は、具体的な選択肢を一度だけ提示します。これまでの指示と、自律的に選択して進めるよう求める指示を尊重します。
   • すでに承認されている実装に、余分な承認工程を設けてはいけません。

7. 選ばれた案だけを昇格させます。

   • 選択された方向性を実際の技術スタックで再構築します。
   • 通常のADSコア工程と、レンダリング結果のエビデンス確認ゲートを実行します。
   • 昇格後、一時的な実装用の足場を削除します。比較に役立つエビデンスはタスクとともに保持し、既存のユーザー成果物は削除しません。

検証要件

バリエーションを提示する前に、次の点を確認してください。

• 各方向性に固有の主張名がある
• すべての方向性で、同じ現実的なコンテンツとアプリケーションの状態を使用している
• 各方向性の間で、構造または操作性の軸が少なくとも1つ異なる
• 切り替え機能がキーボードで操作でき、選択状態が示される
• 各方向性が必須のビューポートで表示される
• 各方向性について、スクリーンショットまたは同等のレンダリング済みの証拠がある
• 推奨理由が、見た目の新しさだけでなく、ユーザーとの適合性とトレードオフに基づいている

出力

次の項目を返してください。

• 判断が必要な事項
• 推奨する方向性
• バリエーションの主張とトレードオフ
• バリエーション間で共通する不変の要素
• レンダリング済みの証拠
• リスクまたは未解決の質問
• 成果物のパス