visual-reference-calibration

ビジュアルリファレンスの調整

提供されたリファレンスから特定のビジュアル品質を取り入れる場合に使用します。タスクとレビューの流れは ADS が担当し、このヘルパーは何を取り入れるべきかを明確にします。不具合を示すだけのスクリーンショットは、通常のレビューフローで扱います。

質問する前に情報を確認する

ユーザーの依頼、これまでの調整時の回答、現在の製品上の決定事項、実際のリファレンスを確認します。すでに決まっている選択は再利用します。リファレンスを重視する大規模な作業では、簡潔なリファレンス契約を内部で記録します。

• 元となるリファレンスと、維持する特性
• 取り入れない要素（付随するデモコンテンツなど）
• 忠実度の目標（忠実な再現、雰囲気の踏襲、緩やかなヒント）
• 維持すべき既存の画面、階層、トークン、コンテンツ
• 意図した効果を確認するための、観察可能な比較方法

不確かな任意の詳細があるからといって作業を止める必要はありません。判断の不足が結果を大きく左右し、かつ情報を再確認したり妥当に推測したりできない場合に限り、質問してください。たとえば、求める特性はカードごとの表面ではなく、全体で共有されるホバー領域でしょうか。調整項目を最初からすべて質問し直さないでください。

効果をもたらすレイヤーを切り分ける

構成、素材・色、境界線・影・グロー、タイポグラフィ・密度、動き、コンテンツの比喩、システムの挙動を区別します。意図されたレイヤーだけを維持してください。技術的に似た仕組みでも、リファレンスの目に見える品質が失われるなら不十分です。

微妙な方向性が未解決の場合は、必要最小限のビジュアルターゲットまたはインタラクティブなプロトタイプを作り、本格的な実装に入る前にリファレンスと比較します。具体的なリファレンスがあり、タスクが明確であれば、承認済みのローカル実装へそのまま進められます。リファレンスに基づく小さな修正に、追加のモックアップや承認手順は必要ありません。

製品の文脈で確認する

• 関連する同じ状態とスケールを、横に並べて比較します。
• コードの仕組みを説明しなくても、効果が保たれるか確認します。
• 製品に属さない偽のメニュー、イニシャル、アイコン、デモ用の装飾は取り除きます。
• 変更がユーザーの依頼範囲に含まれない限り、既存のコンテンツと階層を維持します。
• インタラクションのリファレンスでは、実際の動作、キーボード操作・フォーカスに相当する動作、モーション低減、対象となるモバイルブラウザーでの挙動を検証します。静止画だけではモーションの忠実度を確認できません。
• 効果がシステム全体に及ぶ場合は、無関係なローカルのホバー効果で代用せず、共有される挙動を検証します。

既存のタスクレビューと納品フローを使用します。ローカルで実装する権限があっても、デプロイや公開の権限があるとは限りません。

改善がうまくいかない場合

直近の成果物と以前の契約に照らして、具体的な修正指示を確認します。うまくいった部分を維持し、誤っていた前提を特定します。タスクの既存の予算内で、通常は実装を1回、修正を1回行う形で、サポート対象の修正を続けます。プロジェクトを自動的にリセットしたり、作業を破棄したり、却下が2回続いた後に同じ質問を繰り返したりしないでください。重要な判断やリソースが収束を妨げている場合は、具体的な成果物と、その阻害要因を1つだけ提示します。手法を切り替えても、予算は更新されません。

Jhey のカードから得られる教訓

記録された https://codepen.io/jh3y/pen/WbwZaNa の教訓は、カード間に影響する共有の近接フィールド、厚みのあるカラフルな境界線、彩度の高いぼかし素材、グローに関するものです。偽のアプリ装飾やオーバーフローメニューを追加するためのテンプレートではありません。付随するデモコンテンツではなくビジュアルシステムを維持してください。この過去の教訓は、別のタスクで同じ美的表現を採用するよう求めるものではありません。