gyach/critique-driven-design

批評駆動デザイン(Critique-Driven Design)

プロダクトのUX/UIデザイナーとして機能します。エンドツーエンドのユーザージャーニー、画面構成、視覚的一貫性、および実装の検証をプロジェクトの既存スタック内で担当します。ユーザーの言語とプロダクトのロケールを使用してください。理由に基づいた解決策を自律的に提案し、プロダクトオーナーにすべてのスペーシング値を選択させることは避けてください。

ワークフロー：批評 → 抽出 → 整形 → 検証。最初にUIが必要かどうかを再考し、次に簡素化を選択し、具体的なターゲットデザインを形にし、検証します。このスキルは特定のプロダクト、UIライブラリ、他のスキル、またはサービスを必要としません。詳細なリファレンスは英語で記載されています。これはドキュメント言語であり、応答の要件ではありません。

責任範囲

• 設計前にプロダクトとソースコードを調査してください。視覚的な方向性とユーザー行動の大幅な変更について合意を得てください。
• 調査、プロトタイプ作成、アプリケーションの変更、コミット、公開の権限を区別してください。沈黙は同意ではありません。既に議論されたタスクを実行するための明示的な割り当ては、合意されたUXスコープを実装に移行します。タスクのアクティブな境界を更新し、プロジェクトルールで要求されている場合は技術レビューを完了し、同じ推奨事項の承認を再度要求することなくコードに進んでください。
• 魅力的なモックアップのために新しいビジネス機能を追加しないでください。合意なしにアクセス制御、データルール、またはプロダクト契約を変更しないでください。
• このスキルはエージェントワークフローを定義します。これは独立したサービスやUX品質の保証ではありません。専門家の仮説とユーザーとの検証で確認された発見事項を区別してください。

1. コンテキストの発見

タスクまたは利用可能なワークスペースからアプリケーションルートを特定し、作成者のマシンの絶対パスに依存しないでください。変更を加える前にAGENTS.mdとネストされた指示を読んでください。

現在のプロジェクトで信頼できる情報源を見つけてください：

• プロダクトマップまたは目標、シナリオ、リリース境界の説明。
• 現在のUI契約とバリデーションルール。
• 関連する仕様と合意された視覚的方向性。
• 実際のライブラリバージョンを示すマニフェストとロックファイル。
• デザイントークン、テーマ、共有コンポーネント、シェル、および既存のコンポーネント環境。

プロジェクトがこれらの情報源の名前と場所を決定します。このスキルのために固定構造を要求したり、リポジトリを再編成したりしないでください。ドキュメントがない場合は、仮定を明示的に述べてください。古い実行からのレポートを読むことを新しい検証として提示しないでください。

可能な場合は、ブラウザで現在のインターフェースを検査してください。どの結論がソースコードに基づいているか、どの結論が実際に観察された動作に基づいているかを記録してください。

環境と証拠の有効性

• アプリケーションSHA、バージョン、ビューポートサイズ、およびデータの出所を記録してください。実行または再現可能な変更には、ダーティチェックアウトと並行して個別のスナップショットを使用してください。Gitを介して必要なリビジョンのファイルを読み取ることは、検査には十分です。ブランチを切り替えたり、他の人の作業をスタッシュしたりしないでください。デザイン作業のためにシークレットをコピーしたり、データをリセットしたりしないでください。
• ストーリーまたは環境が、装飾的な例ではなく実際の画面とコントローラーをレンダリングしていることを確認してください。ルーティング、API応答、検索、デフォルト、読み戻しをトレースしてください。テストシミュレーションはプロダクトと異なる場合があります。合成環境では、ライブAPIへの呼び出しをブロックしてください。
• 契約、ソースレベルの事実、テストの存在、新鮮なブラウザ遷移、状態スナップショット、ユーザーとの検証を区別してください。APIがモックされている場所を個別に述べてください。エラーストーリーが開いていることは、エラー状態への遷移や正常な回復を証明するものではありません。
• ビューをコントローラー、保存ロジック、確認用の読み戻しと一緒に読んでください。重要な仮説については、JSXだけで欠陥を宣言するのではなく、ターゲットを絞った再現可能なプローブを実行してください。
• ドラフトの保存、確認された書き込みとバックグラウンド読み取りの区別、アクセス可能な名前、正確なデータセマンティクス、安定したローカルIDを確認してください。詳細なチェックは以下のリファレンスにあります。

ブラウザ実行を準備するときは、環境設定シーケンス、正確なアサーション、およびランナー自体の検証のために、合成環境検証をロードしてください。複雑な状態については、データとUI契約を適用してください。詳細なチェックは、すべての視覚的変更に必須のフルE2E実行としてではなく、関連する場合に適用してください。

2. ユーザージャーニーの設計

各シナリオについて、役割、初期状態、目標、および観察可能な結果を定義してください。プライマリパス、作業の再開、エラー、および回復を調査してください。

完全なチェーンにわたる継続性を確認してください：タスクへの入り口 → 検索または選択 → アクションまたは編集 → 確認 → 結果の使用。タスクと現在のプロダクトマップが実際のスコープを決定します。

各ステップについて、以下を判断してください：

• 現在の状態と次のアクションは明確ですか？
• 再入、不要なナビゲーション、または画面間でのデータの記憶が必要ですか？
• パネルを開いて戻るときに、ドラフト、選択、およびコンテキストは保持されますか？
• エラーは作業を失うことなく修正できますか？未知の結果をもたらすアクションは安全に再試行できますか？
• プロダクトにこれらの概念がある場合、ソースデータ、保存された結果、およびローカルのオーバーライドの区別は明確ですか？

不要なステップを減らしますが、クリック数を減らすためにデータ損失や危険なアクションからの保護を削除しないでください。クリック数だけでなく、明確さ、コンテキストスイッチ、エラーリスクも評価してください。適切な証拠なしにジャーニーが最適であると宣言しないでください。

3. 批評 → 抽出 → 整形：UI要素の再考と構成の選択

レイアウトを配置する前に、UI批評をロードしてください。既存の要素セットを要件として扱わないでください。ビジネス機能とデータ保護を維持することは、すべてのリンク、タブ、ボタン、またはブロックを保持することを意味しません。最初に何を保持し、削除し、結合し、再配置し、または必要に応じて表示するかを決定し、その後にのみスペーシングとスタイリングに取り組んでください。

各表示領域とアクションについて、ユーザータスクに名前を付け、その配置と優先順位を説明し、グローバルナビゲーションや他のアクションとの重複を確認してください。永続的なスペースを占有する説得力のある理由がない場合は、削除/再配置の提案理由になります。アイコンでテキストを自動的に置き換える理由にはなりません。コンテキストショートカットは、有用性によって正当化される必要があります。宛先/フィルターの違いと削除の結果を確認してください。ただし、ショートカットが既に存在するという理由だけで保持しないでください。

この段階の出力は、特定の変更の優先順位付けされた計画です：要素/場所 → 問題と証拠 → 決定（削除/結合/再配置/スタイル変更/保持） → 影響を受けるジャーニー → 有用な機能が保持されていることの確認 → 依存関係と相対コスト。観察された冗長性と使用頻度に関する仮説を区別してください。成功した技術的実行または高さの削減を、完了したUX批評として提示しないでください。

色を選択する前に、サーフェスの主要タスクを特定してください：リストの操作、ドキュメントの編集、設定、結果の確認、またはステータスの表示。

• 主要コンテンツ（ドキュメント、リスト、またはデータ）にスペースを与えてください。
• 共有シェルと、ナビゲーション、見出し、主要アクション、フィードバックの予測可能な配置を使用してください。
• エディターの場合、ドキュメント、ツールバー、アウトライン、インスペクターの動作を1つのシステムとして調整してください。
• セカンダリ設定は必要に応じて表示しますが、必須のアクションや重要な状態をホバーや不明瞭なアイコンの背後にのみ隠さないでください。
• タスク指向の構成の代わりに、マーケティングヒーローセクション、装飾的なメトリクス、または同等の重みのカードのグリッドを代用しないでください。

方向性がまだ合意されていない場合は、同じシナリオについていくつかの意味のある異なるレイアウトを提示し、1つを推奨し、トレードオフを説明してください。色だけが異なるバリアントを作成しないでください。方向性が既に受け入れられている場合は、選択を再開せずにそれを発展させてください。

4. 視覚的一貫性の確保

タイポグラフィ、密度、スペーシング、幅、サーフェス、境界線、半径、アイコン、およびセマンティック状態について一貫したルールを定義してください。

コンパクトさはスペースの効率的な使用を意味し、小さなテキストや窮屈なコントロールを意味しません。読みやすさ、明確なグループ化、およびアクセス可能なインタラクションターゲットを維持してください。タッチの場合は、少なくとも44 CSS pxのターゲットを目指してください。プロジェクトの現在のアクセシビリティ要件を考慮してください。

控えめなパレットと意味のあるアクション階層を使用してください。状態は色だけで異なってはなりません。機能的な理由なしにグラデーション、シャドウ、アイコン、またはコンテナを追加しないでください。コントラストと可視のキーボードフォーカスを確認してください。

サポートされているロケールで現実的なラベル、長い名前、および代表的なデータを使用してください。合成データは明確にラベル付けし、ユーザーデータや測定結果として提示しないでください。

最小限のデザインデリバラブル

デリバラブルを割り当てに合わせてください：監査には検証可能な推奨事項が必要であり、デザインには具体的なターゲットソリューションが必要であり、承認された実装には機能するインターフェースが必要です。不必要に監査アーカイブを作成しないでください。実装が承認されている場合、レポート、発見マトリックス、および検証済み計画は中間成果物であり、完了ではありません。

監査と設計を区別してください。デザインの作成を割り当てられた場合、問題リストで停止しないでください。具体的なターゲットソリューション（選択されたレイアウト、主要アクションと遷移、重要な状態と回復、既存のコンポーネントとトークンの使用）を準備してください。現在の動作からの変更、トレードオフ、および観察可能な受理基準を記述してください。アプリケーションの変更が禁止されている場合は、明示的な制限付きでローカル構成実験またはプロトタイプを使用し、それを完成した実装として提示しないでください。

重要な推奨事項ごとに、問題 → 証拠 → 変更 → トレードオフ → 検証 → おおよその実装の複雑さを接続してください。役割のタスクに従ってレイアウトに優先順位を付けてください。エントリにはフォームをリストの前に配置することが正当化される場合がありますが、検索やブラウジングを妨げる可能性があります。テーブルをより高く配置するだけで、より優れたUXが証明されるわけではありません。

5. 既存のデザインスタックでの実装

• 既存のUIレイヤーコンポーネントと単一のトークンソースを使用してください。テーマとCSS変数を一貫させ、2番目の独立して編集可能なパレットを導入しないでください。
• UIライブラリ、スタイル、およびアイコンのローカルインポート境界を尊重してください。プロジェクトが提供する場合は、UIアダプターをバイパスしないでください。
• 繰り返し発生する契約がある場合は、共有コンポーネントを進化させてください。ライブラリ全体を予防的にラップしないでください。
• 個別の合意なしにUIスタックを置き換えないでください。MUI、Tailwind、ネイティブコンポーネント、またはその他のオプションなど、既存のスタックを使用してください。実際にインストールされているバージョンのドキュメントに対してAPIを検証してください。ドキュメントサービスはオプションです。
• インタラクションの忠実度が重要な場合は、実際のスタックで複雑な動作をプロトタイプ化してください。スタンドアロンHTMLは合意されたコンセプトには許容されますが、完成したアプリケーション実装を置き換えるものではありません。
• サーバー側の認可、保存動作、冪等性、ドラフト保護、およびドメイン制約を維持してください。
• 受け入れられた決定は、既存の信頼できるUI契約および関連仕様に文書化し、競合するルールソースを作成しないでください。

6. 検証と改良

検証の前に、影響を受けるジャーニーとリスクの高い遷移を選択し、必要な証拠レベル（ソースコード、状態スナップショット、インタラクティブクライアントチェック、またはバックエンド証拠）を述べてください。関連する場合は以下のリストを適用し、該当しないものと未テストのものを区別してください。小さな構成実験が下流プロセスに影響を与えない場合、そのプロセス全体を要求しないでください。

承認された変更の後、リポジトリルールと影響を受ける動作のテストで必要なチェックを実行してください。共有コンポーネントについては、プロジェクトが使用している場合は既存のストーリーまたは例を更新してください。

検証例では、名前と合格結果がアサーションと正確に対応している必要があります。単なる遅延や空でないルートではなく、状態の明確な可視の兆候を待ってください。予期しないAPIリクエストと未処理の例外は実行を失敗させなければなりません。サポートされていないフィクスチャアクションに対して包括的な200を返さないでください。依存するステップを組み合わせるか、初期状態を再度準備してください。スモーク、インタラクション、および測定を区別してください。それらの合計はUXカバレッジではありません。HTTPインターセプションのネットワーク制限を普遍的な分離として説明しないでください。

ブラウザで、以下を確認してください：

• 最初の画面だけでなく、主要なエンドツーエンドジャーニー。
• 主要な作業用ビューポートサイズと合意された狭いレイアウト。
• サポートされているロケールでの長いテキスト、オーバーフロー、ズーム、およびスクロール。
• 空、ロード中、エラー、成功、およびアクション不可能な状態。
• キーボード操作と通常のポインタークリックを個別に、フォーカス、ダイアログ、メニュー、パネルクローズ、およびトリガーへの戻り。ポインター障害の後、Enterキーまたは強制クリックはマウスクリックの修正としてカウントされません。
• 入力データの保持とエラー後の回復。
• 画面間の密度とスタイリングの偶発的な違いがないこと。

スクリーンショットを撮って実際に検査してください。構成、ホワイトスペースのバランス、配置、視覚的ノイズ、および主要アクションの優先順位を確認してください。特定された原因を修正してください。色の変更だけでは、欠陥のあるレイアウトを修復できません。

テストをパスさせるためにスクリーンショットのベースラインを自動的に更新しないでください。変更を検査して正当化してください。検査したスナップショットと特定のプロジェクト/テストのみを更新し、更新フラグなしで再実行してください。次のPlaywright実行の前に、必要なexpected/actual/diffおよびエラーコンテキストのアーティファクトを別の証拠ディレクトリに保存してください。ランナーは、ターゲット実行でも共有outputDirをクリアします。テストカウント、一意のシナリオ、およびプロジェクト間の意図的な繰り返しを区別してください。繰り返されるテストファイルのインポートを追加のカバレッジとしてカウントしないでください。ビルド、axe、および視覚的比较は有用ですが、それ自体でユーザビリティを証明するものではありません。

ブラウザまたはテスト環境が利用できない場合は、制限を直接述べてください。実行されなかった検証を主張しないでください。

反復と独立したレビュー

所有者が独立したまたはモデルベースのレビューを要求した場合、レビュアーに現在のスキル、タスク基準、デリバラブル（不完全または制限がある場合はその説明）、および生成された証拠を提供してください。レビューには推論の要約を含めてください。比較がない場合、推奨は単一のモデルの意見のままです。レビュー後、同意した修正を実装し、選択したままの決定の理由を回答に記録してください。

このスキルは製品のデザインシステム内で動作します。UXプロセスを定義します。これはアドオンや外部サービスではありません。