experience-design-validate

Experience Design Validate

レンダリングされたソフトウェアのビジュアル表現を評価します。目に見えるものと、そうした視覚的な判断が生み出す感覚的な質を対象とします。CSS、トークン、実装手法ではなく、関係性、階層、抑制、一貫性、細やかな配慮を評価します。

これはビジュアル表現に限定した監査です。WCAG 準拠、キーボードやスクリーンリーダーへの対応、操作性、実装品質、本番リリースの準備状況を評価するものではありません。アクセシビリティ準拠の評価には experience-accessibility-validate を、SLDS 準拠の評価には design-systems-slds-validate を使用してください。

用途と対象範囲

次の目的には、このスキルを使用してください。

• デザインのチェックポイントでビジュアル表現を批評する。
• レンダリングされたデザインが、配慮されている、窮屈、落ち着いている、まとまりがない、または魅力的に感じられる理由を説明する。
• 同じ要件を満たす 2 つ以上のデザインの表現力を比較する。
• 目に見える体験を、優れたものから卓越したものへ引き上げるデザイン上の工夫を特定する。

次の目的には、このスキルを使用しないでください。

• 実装やコードレビュー。LWC の生成やセキュリティレビューには、必要に応じて experience-lwc-generate または experience-lwc-security-validate を使用してください。
• WCAG、スクリーンリーダー、キーボード、フォーカス順序の検証を含む、アクセシビリティ準拠の評価。experience-accessibility-validate を使用してください。
• SLDS デザイントークンへの準拠の評価。design-systems-slds-validate を使用してください。
• 実際のユーザー行動に関する主張。影響の判断が目に見える根拠ではなく行動に左右される場合は、ユーザビリティ調査を推奨してください。

視覚的証拠に関する要件

レンダリングされたピクセルが必須です。確認した証拠をそのまま保持できるため、スクリーンショットを優先してください。

1. スクリーンショット： 提供されたページ全体または領域のキャプチャをそのまま使用します。
2. ライブ URL： ブラウザー機能を利用できる場合は、URL を開いて関連する経路だけを操作し、スクリーンショットを撮影して、URL とビューポートを証拠として記録します。利用できない場合は、スクリーンショットを依頼してください。
3. Figma： Figma 機能を利用できる場合は、指定されたレンダリング済みフレームを取得またはエクスポートします。プロトタイプの動作を実際に確認していない限り、フレームは静的なものとして扱います。利用できない場合は、フレームのエクスポートまたはスクリーンショットを依頼してください。
4. 画面録画またはインタラクティブなプロトタイプ： ツールで対応できる場合は、観察可能な遷移を確認し、代表的なフレームを撮影します。
5. ソースコード、デザインの説明、またはアクセスできないリンク： レンダリング結果を推測しないでください。利用可能な機能でレンダリングし、それができない場合はスクリーンショットを依頼してください。

レンダリングされたピクセルが提供されていない場合：

• インタラクティブ実行： スクリーンショットまたは他のレンダリング済みアーティファクトをユーザーに依頼し、監査を中断します。
• 非インタラクティブ実行： ステータス INSUFFICIENT_VISUAL_EVIDENCE と、不足しているアーティファクトを簡潔に示す文を返します。スコアや判定を示したり、指摘事項を作成したり、準備が整っていると示唆したりしないでください。

証拠モード

分析の前に、次のモードを 1 つ宣言してください。

モード	評価に使用できる根拠	評価に使用できない根拠
STATIC_VISUAL	視覚的な階層、余白、タイポグラフィ、色、情報密度、構図、一貫性、およびキャプチャされた瞬間の視覚的な表現	インタラクションの動作、状態間の遷移、キャプチャされたビューポート以外でのレスポンシブな適応、遅延、実行時のパフォーマンス、または表示されていない状態
MULTI_VIEW_STATIC	複数の画面、状態、またはビューポートのキャプチャにわたる静的な視覚的証拠。画面間の一貫性も含む	キャプチャ間の動作、タイミング、入力への応答、実行時のパフォーマンス、または表示されていない状態
DYNAMIC_VISUAL	静的な品質に加え、実際に操作または記録された動作：インタラクションへのフィードバック、遷移、状態変化、体感パフォーマンス	操作していない経路、記録されていない状態、アクセシビリティ準拠、または観察した範囲を超える測定済みパフォーマンス

読み込み中、エラー、または空の状態を写した静的なスクリーンショットで批評できるのは、その状態の視覚的な表現のみです。状態の網羅性、遷移の動作、パフォーマンスを裏付ける証拠にはなりません。観察していない状態や動作が提示されていないことを理由に、スコアを下げてはいけません。その網羅状況は INSUFFICIENT_EVIDENCE と記してください。

5つの次元

次元	感覚的な問い
有用性	表示されているコンテンツは、占めているスペースと注意に見合う価値がありますか？
使いやすさ	表示されている階層とアフォーダンスによって、意図された操作経路が明確になっていますか？
信頼性	観察された状態とフィードバックによって、体験が予測しやすいと感じられますか？
一貫性	表示されている体験から、同じチームが同じ感性で作ったことが伝わりますか？
丁寧な仕上がり	表示されているデザインは、緻密で、よく考えられていて、心地よく感じられますか？

利用可能な証拠で次元を十分に評価できる場合に限り、1〜10のスコアを使用してください。該当する次元を裏付ける証拠がない場合は、INSUFFICIENT_EVIDENCE を使用してください。N/A は、その次元またはトピックが本当に該当しない場合に限って使用し、証拠が不足しているだけの場合には使用しないでください。

スコアの基準、判定ルール、重大度の定義、およびレポートの完全な要件については、references/scoring-rubric.md を読んでください。

クラフトの観点

描画された体験が次のように感じられるかを確認してください。

• ゆとりがある： 空間が構成を整え、視線に余裕を与えている。
• 親しみやすい： 説明がなくても、意図された操作経路が視覚的に明確である。
• 探索を促す： 表示されている状態が探索を促し、行き止まりを感じさせない。
• 熟慮されている： 繰り返される判断が、寄せ集めではなくシステムを形作っている。
• 落ち着いている： 階層が穏やかで、主役を競い合う要素が少ない。
• 心地よい： 細部や個性に意図があり、装飾的なノイズになっていない。
• 自信に満ちている： デザインに明確な主張があり、不必要に曖昧な表現を避けている。

監査ワークフロー

次の順序で進めてください。

1. 証拠のモードを特定し、提供または取得された成果物をすべて一覧にします。
2. 描画されたピクセルがない場合は、視覚的証拠が不十分な場合の手順に従って終了します。
3. ルールを確認する前に見てください。各デザインについて、率直な第一印象を3つまで記録します。
4. カバレッジと関連性の台帳を作成します。各次元と参照トピックについて、SCORED、N/A、INSUFFICIENT_EVIDENCE のいずれか、証拠のモード、および簡潔な理由を記録します。
5. references/craft.md、references/scoring-rubric.md、references/visual-system.md を読み込みます。条件付きの参照資料は、そのトピックが証拠のモードにおいて関連し、かつ観察可能な場合に限って読み込みます。
6. 裏付けのある次元のみを採点します。該当し、観察可能な基準を証拠で完全に裏付けられるアンカーのうち、最も高いものを選びます。証拠がそのアンカーを明確に上回る一方で、次のアンカーを完全には裏付けない場合に限り、奇数のスコアを使用します。
7. 指摘事項を記述します。各次元の指摘は最大5件とし、次元をまたぐ根本原因の重複を避けます。
8. 台帳と証拠の限界を含めて、クラフトレポートを作成します。

段階的な開示

常に読み込むもの：

• references/scoring-rubric.md：スコアリング、網羅性、重大度、判定、レポートのスキーマ。
• references/craft.md：考え抜かれた仕事から感じられる品質。
• references/visual-system.md：目に見えるレイアウト、タイポグラフィ、色、表面。

関連し、観察可能な場合に限り読み込むもの：

リファレンス	必要な証拠
references/components.md	ボタン、入力欄、モーダル、リスト、テーブル、フィードバックコンポーネントが見える
references/navigation.md	ナビゲーション、タブ、パンくずリスト、検索、または経路案内が見える
references/responsive.md	複数のビューポートからのキャプチャ、またはサイズ変更を直接試した証拠
references/forms-flows.md	複数の手順が見える、またはフォームの動作を直接試した証拠
references/data.md	グラフ、ダッシュボード、指標、フィルター、結果、またはテーブルが見える
references/records.md	レコード、詳細ページ、ステータス、メタデータ、または共同作業機能が見える
references/ai.md	AI、エージェント、チャット、引用、またはモデルの出力が見える
references/trust.md	認証、プライバシー、同意、権限、または破壊的な設定が見える
references/usability.md	タスク構造が見える。操作性を推測しないこと
references/interaction.md	インタラクションまたはモーションを示す DYNAMIC_VISUAL の証拠
references/state.md	状態遷移を示す DYNAMIC_VISUAL の証拠。静的な状態のキャプチャが示すのは外観のみ
references/performance.md	タイミング、レイテンシ、またはレイアウトの安定性を示す DYNAMIC_VISUAL の証拠

指摘の書き方

感じられるレベルで述べ、主張を目に見える証拠に結び付けてください。

良い例：「ツールバーは詰め込みすぎに感じられます。多くのコントロールが注意を奪い合うため、目が主要なアクションを見つけられません。」

範囲外の例：「3種類のボタンクラスで、余白のトークンに一貫性がありません。」これは実装または SLDS のレビューに該当します。

各指摘には、severity、primary_dimension、任意の related_dimensions、location、problem、why_it_weakens_craft、what_better_looks_like、fix を含めてください。同じ問題が3か所以上に現れる場合は、件数と代表的な場所を含めた指摘を1件作成してください。

比較監査

同じ証拠要件と評価基準を用いて、各デザインを個別に監査してください。レポートには次の内容を含めます。

• デザインごとの証拠モード、網羅性の記録、第一印象、各ディメンションのスコア、証拠、次に裏付け可能なレベルまでの差。
• N/A と INSUFFICIENT_EVIDENCE を数値比較に置き換えず、そのまま維持する横並びの比較表。
• A_HIGHER_CRAFT、B_HIGHER_CRAFT、TIE、MIXED のいずれかの結果。ディメンションによって優劣が異なる場合、または証拠の網羅性によって全体の順位を決められない場合は MIXED を使用してください。
• 差が表れるディメンション、各デザインがより優れた形で実現している具体的な工夫、模倣せずに互いに取り入れられる改善点。

証拠が引き分けまたは混合の結果を示している場合、勝者を決めないでください。

出力

ユーザーが出力先を明示した場合は、必ずそのパスに書き込んでください。そのパスは命名規則より優先されます。それ以外の場合は、YYYY-MM-DD-<target-slug>-craft-audit-<VERDICT>.md を使用し、PASS、WARN、FAIL、LIMITED は大文字で記載してください。

レポートでは対象範囲を明確にしてください。判定とリリース準備状況への影響は、ビジュアルの仕上がりのみを対象とし、アクセシビリティ、機能の正確性、測定されたパフォーマンス、本番リリースの承認は対象外です。

推奨事項と分野横断的なパターンは、それぞれ0〜5項目としてください。証拠に裏付けられた有用な項目だけを含め、数合わせのための項目は追加しないでください。実行可能な推奨事項が1つ以上ある場合に限り、references/scoring-rubric.md で定義された修正プロンプトで締めくくってください。

基本原則

1. まずピクセルを確認します。 描画された画面の証拠がなければ、ビジュアル表現の監査は行えません。
2. まず目で確認し、次にルールを適用します。 評価基準を分析する前に、第一印象を記録します。
3. 主張は証拠の範囲内にとどめます。 観察できていない動作は、欠陥ではなく不明です。
4. 実装レベルではなく、体感レベルで評価します。 コードではなく、視覚的な体験を説明します。
5. 監査しながら学べるようにします。 それぞれの指摘が重要な理由と、より良い状態がどのように感じられるかを説明します。
6. 数より重大度を重視します。 水増しされたチェックリストより、鋭い指摘をいくつか挙げるほうが効果的です。