markhougaard/ux-laws

Laws of UX — インデックスとプロトコル

このファイルは、モードの選択、30の法則のうちどれを適用するかの選択、それらの使用方法とレポート方法を定義します。各法則はreferences/配下に、以下の表の名前（fitts-law → references/fitts-law.md）で独立したファイルとして存在します。選択したファイルのみを開いてください。

ユーザーが1つの法則を指定した場合（「このフォームをPostelの法則に照らしてレビューして」）、その参照ファイルのみを開き、ユーザーが依頼したモードで使用します。レビューは、このセクション5の手順に従います。

0. ファイルと環境

このスキルはファイルを読み取れる任意のエージェントで動作します。特定のツールに依存しません。

• パス このスキル内のすべてのファイル（参照ファイルを含む）のパスは、このSKILL.mdを含むディレクトリを基準とします。references/fitts-law.mdは、常に <スキルディレクトリ>/references/fitts-law.md を意味します（たとえ別の参照ファイル内に記述されていても）。
• 参照ファイルを開けない場合（例えば、このテキストがフォルダなしでプロンプトに貼り付けられた場合）、その旨を伝え、必要な法則ファイルを要求してください。記憶だけでチェックを実行しないでください。チェックID、重大度、証拠の種類はそれらのファイルにのみ定義されています。
• 証拠は検査可能なものに依存します。 画像、スクリーンショット、モックを表示できない場合、それらはあなたにとってstaticな証拠にはなりません。持っているテキストやコードをレビューし、その旨をスコープ行に記載してください。アーティファクトを実行できない場合、interactiveおよびruntimeは、ユーザーが録画や測定値を提供しない限りスコープ外です。

1. モードの選択

モード	使用するタイミング	生成するもの
アドバイス (Advise)	ゴール、概要、問題定義、ロードマップアイテム、または初期コンセプトのみが存在する場合。	簡潔な方向付けの概要：ここで最も重要な法則、予測されるリスク、チームが回答すべき質問、そして今下すべき決定。
構築 (Build)	設計または実装の進行中で、参照が必要な場合。	該当する法則のモード2から抽出した、対象のコンポーネントや画面に対するターゲットを絞ったガイダンス。具体的な値があればそれも含む。
レビュー (Review)	完成したデザイン、プロトタイプ、スクリーンショットセット、URL、またはコード差分がコミットされようとしている場合。	重大度、証拠、修正案、および判定を含む、厳格な所見レポート。

リクエストに明記されていない場合は、入力から推測します：ゴール → Advise；作業中 → Build；完成品 → Review。それでも不明な場合は、1つ質問してください。

2. 法則の選択

すべてのタスクで30の法則すべてを開かないでください。状況に基づいて選択し、目にしたものに一致するトリガーがあれば追加してください。

UIレビューのベースライン（常に実行）： fitts-law、jakobs-law、cognitive-load、law-of-proximity、law-of-similarity、selective-attention、cognitive-bias。アーティファクトがインタラクティブな場合は、doherty-thresholdを追加します。

状況別：

状況	開く法則
フォーム、データ入力、サインアップ	postels-law、working-memory、chunking、law-of-proximity、parkinsons-law、goal-gradient-effect
ナビゲーション、メニュー、情報アーキテクチャ	hicks-law、serial-position-effect、mental-model、jakobs-law、chunking、pareto-principle
ダッシュボード、データ密度の高いツール、エキスパートツール	cognitive-load、chunking、law-of-common-region、law-of-pragnanz、flow、pareto-principle
データ可視化、図	law-of-pragnanz、law-of-uniform-connectedness、law-of-similarity、von-restorff-effect
オンボーディング、初回起動、ヘルプ	paradox-of-the-active-user、goal-gradient-effect、zeigarnik-effect、cognitive-load、mental-model
料金、プラン、カタログ、チェックアウト	choice-overload、hicks-law、cognitive-bias、von-restorff-effect、serial-position-effect、peak-end-rule
通知、アラート、ステータス	selective-attention、von-restorff-effect、flow、zeigarnik-effect
モバイル、タッチ	fitts-law、law-of-proximity、serial-position-effect、doherty-threshold
パフォーマンス、ローディング、非同期処理	doherty-threshold、goal-gradient-effect、peak-end-rule、flow
リデザイン、マイグレーション	jakobs-law、mental-model、serial-position-effect、aesthetic-usability-effect
自動化、AI、スマート機能	teslers-law、mental-model、cognitive-bias、doherty-threshold
スコープ、優先順位付け、ロードマップ	pareto-principle、occams-razor、teslers-law、hicks-law
ビジュアルデザイン、デザインシステム	aesthetic-usability-effect、law-of-similarity、law-of-proximity、law-of-common-region、law-of-pragnanz、von-restorff-effect
エラー、障害、終了	peak-end-rule、postels-law、selective-attention、mental-model

各開いた法則の関連法則は、所見や質問が実際にその法則に触れた場合のみ参照してください。

3. アドバイスプロトコル

1. ゴール、ユーザー、コンテキストを2〜3行で要約します。ユーザーやコンテキストが不明な場合はその旨を述べてください — それが最初のリスクです。
2. 表から3〜6の法則を選択します。6つを超えるとアドバイスが希薄になります。
3. 各法則について、このプロジェクトに対して予測される1〜2のリスクと、チームが回答すべき質問を示します。法則のモード1をソースとして使用しますが、具体的にします。
4. 今すぐ下すべき決定（予算、デフォルト、規約、強調ルール、測定）と、それを誰が担当すべきかをリストアップします。
5. 意図的な選択が必要となる法則間の緊張関係をフラグします（セクション6参照）。

おおむね1ページ程度に収めます。目的は方向を示すことであり、事前設計ではありません。

4. 構築プロトコル

1. 作業中のコンポーネント、画面、またはフローを特定します。
2. 該当する法則を開き、そのモード2のリストを参照として使用し、具体的な値（ターゲットサイズ、タイミング、コントラスト比、WCAG基準）を引用します。
3. ガイダンスが矛盾する場合は、その旨を述べ、このケースに推奨する解決策を1つ提案します。
4. 構築中は完全なレビューを実行しないでください。ブロッカーの可能性が高い場合にのみ、Reviewレベルの問題に言及します。

5. レビュープロトコル（厳格）

レビューは、コミット前の問題を防止するために存在します。厳格性のルール：

• 証拠がない限り合格ではありません。 チェックは、アーティファクト内の肯定的な証拠に基づいてのみパスします。見えない状態、サイズ、タイミング、動作を決して想定しないでください。
• 検証不可はUNVERIFIED（未検証）であり、合格ではありません。 必要なもの（エラー状態、測定値、実際のデータ、デバイス、コード）を明示します。
• スコープは明示され、暗示されるものではありません。 判定は、あなたが与えられた証拠のみをカバーします。与えられなかった種類の証拠を必要とするチェックはスコープ外としてリストされるため、スクリーンショットのレビューが完全な合格と読まれることはありません。
• 和らげないでください。 称賛のパディング、「全体的に良さそう」、期限や既に費やした労力のために重大度を下げることはありません。
• 具体的にしてください。 すべての所見は、場所（画面、コンポーネント、要素、またはファイル:行）、観察内容、および具体的な修正案を示します。
• 1つの問題に1つの所見。 複数の法則が同じ問題を指摘する場合は、1回報告し、すべてのチェックIDをリストし、最も高い重大度を使用します。
• 合格した法則は明示的に報告します。 どの法則が適用され、所見がなかったかをリストにし、カバレッジを可視化します。

ステップ：

1. 与えられたもの（画面、状態、ブレークポイント、コード）、不足しているものを棚卸しし、証拠スコープを設定します：以下の証拠の種類のうち、どれを持っているか。
2. ベースラインと状況別の法則を選択します。
3. 選択した各法則のモード3テーブルのすべてのチェックを実行します。各チェックを以下のいずれかに分類します：
   • checked（チェック済み） — 合格したか、所見が生成されました。
   • unverified（未検証） — その証拠の種類はスコープ内ですが、必要な状態、要素、または測定値が不足しています（例：staticスコープだが、エラー状態の画面がない）。
   • out of scope（スコープ外） — その証拠の種類のいずれもスコープ内にありません。
   • not applicable（該当なし） — アーティファクトにはチェックの対象となるものがありません（例：マウスのみのデスクトップツールに対するFIT-1）。理由を数語で述べてください。
4. 重複をマージし、重大度を割り当て、修正案を記述します。
5. 判定をスコープと共に提示します。

証拠の種類

すべてのモード3チェックには、それを判断できる入力の種類を示すEvidence列があります。複数リストされている場合、いずれか1つで十分です。

種類	説明	典型的な入力
static	関連する画面と状態の静止画像で見られるもの。	スクリーンショット、静的モック、測定値を含むデザインファイル、フローボード
interactive	操作したときだけ表示されるもの：キーボード、フォーカス、トランジション、体感されるタイミング、アクション後の結果。	クリッカブルプロトタイプ、動作中のビルド、URL、画面録画
code	ソースまたはマークアップにあるもの：セマンティクス、ARIA、autocomplete、ヒットエリア、トークン、およびソースが明確に固定する動作（エラー時のハンドラの動作、入力が保持されるか、フォーカスがどこに行くか）。	差分、コンポーネントソース、レンダリングされたDOM
runtime	現実的なハードウェア、ネットワーク、データでの測定値。	パフォーマンストレース、RUMまたはラボ数値
context	アーティファクト外の事実：使用データ、調査、決定記録、ビジネスルール。	分析、調査結果、PRDまたはADR、チームからの声明

証拠の種類をスコープ内としてカウントするのは、実際にそれを持っている場合のみです。コードが存在すると言われただけでは、codeはスコープ内になりません。

重大度

重大度	意味
Blocker	コアタスクを妨害または誤誘導するもの；データ損失、金銭的、安全、セキュリティ上の害のリスクがあるもの；WCAG 2.2 AA基準に違反するもの；または欺瞞的なパターン。コミット前に修正する必要があります。
Major	かなりの摩擦、エラーが発生しやすいデザイン、または規則性やデザインシステムとの明確な不一致。コミット前に修正するか、指名された責任者による明示的な承認とフォローアップを記録します。
Minor	磨きと一貫性。次にその領域に触れるときに修正します。

判定

最初に一致するルールを適用します：

1. Blockerが1つでもある → コミットしないでください。
2. スコープ内のBlockerチェックがUNVERIFIEDである → 証拠待ちでブロック。 不足している状態や測定値を明記します。チームはすでに与えた証拠と共にそれを提供できたはずです。
3. Majorが1つでもある → 各Majorが修正されるか、指名された責任者によって承認された場合のみコミットしてください。
4. Minorのみ、またはなし → 合格。

すべての判定にはそのスコープが含まれます（例：Pass (static scope)）。Blockerチェックがスコープ外にある場合は、各チェックが必要とする証拠の種類と共に判定行にリストします（例：out of scope: JAK-1 (interactive), SA-2 (interactive), DOH-1 (interactive)）。判定が修飾されない（単に「Pass」）のは、選択された法則のBlockerチェックがスコープ外または未検証でない場合のみです。スコープ外のチェックは判定を変えることはありません。それらはチームにまだレビューされていないもの、およびリリース前に追加の証拠による2回目のパスが必要かどうかを伝えます。

レポートテンプレート

## UX laws review — <アーティファクト名>

Reviewed: <レビューしたもの：画面、状態、ブレークポイント、ファイル>
Evidence scope: <static | interactive | code | runtime | context — 実際に提供されたもの>
Not provided: <不足している状態または証拠>
Laws applied: <コード>
Verdict: <Do not commit | Blocked pending evidence | Commit with accepted Majors | Pass> (<スコープ> scope)
         out of scope: <BlockerチェックIDと各チェックが必要とする証拠の種類、または "none">

### Blockers
- [BLOCKER] FIT-1, JAK-1 · <場所> — <観察内容> → <修正案>

### Majors
- [MAJOR] CL-2 · <場所> — <観察内容> → <修正案>

### Minors
- [MINOR] SIM-6 · <場所> — <観察内容> → <修正案>

### Unverified (スコープ内、証拠不足)
- POS-2 · <チェックできなかったもの> — <特定の状態または測定値> が必要

### Out of scope
- interactive: JAK-1, SA-2, DOH-1, …
- code: CH-3, PKL-3, …

### Not applicable
- FIT-1 — <理由>

### Applied with no findings
<コード>

6. よくある緊張関係

緊張関係	デフォルトの解決策
Hick / Occam（選択肢を減らす） vs Paretoのロングテールとエキスパートのニーズ	重要だが稀な機能を段階的開示で見つけられるように維持する；使用状況だけで削除しない。
Occam（削除） vs Tesler（削減できない複雑さ）	偶発的な複雑さを削除する；本質的な複雑さは可視性と元に戻せる機能を備えてシステムに移す。
Jakob（慣習） vs 差別化	コアコントロールではなく、問題に革新をもたらす。逸脱には、明示されテストされた利点が必要。
Von Restorff（強調） vs Similarity（一貫性）	ビューごとに1つの強調された要素；それ以外はすべて一貫させる。
Fitts（大きくて便利なターゲット） vs 偶発的なアクティベーション	破壊的なアクションは分離する；結果が重大なアクションには元に戻すか確認を追加する。
Flow（中断なし） vs 安全確認	結果が重大で元に戻せないアクションに対してのみ中断する。
Cognitive Load（少なく表示） vs Working Memory（コンテキストを表示）	現在のステップに必要なコンテキストを表示し、残りは隠す。
Postel（寛大に受け付ける） vs 正確性	形式には寛容に、意味には厳密に；曖昧で結果が重大な値は確認する。
Goal-Gradient、Zeigarnik、Serial Position、Von Restorffをてことして使う vs ユーザーの関心	ユーザーが望む結果に向けてのみ使用する；cognitive-biasを参照。

7. すべての法則

知覚と注意

法則	コード	使用目的
aesthetic-usability-effect	AUE	ビジュアルの磨き、第一印象、ブランド表現、ユーザビリティテストの解釈、製品の見た目と機能のギャップ
law-of-common-region	CR	カード、パネル、セクション、境界線、背景塗り、テーブル行、フォームグループ、アイテムが一緒に属することを示すための任意のコンテナ
law-of-proximity	PRX	スペーシング、レイアウト密度、ラベルとフィールドの関連付け、コントロールとコンテンツのグループ化、スペーシングスケール
law-of-pragnanz	PRG	アイコン、イラスト、データ可視化、レイアウトのシルエット、ロゴ、一目で理解されなければならない視覚要素
selective-attention	SA	通知、アラート、ステータス変更、バナー、オンボーディングヒント、システムメッセージ、ユーザーが見逃してはならない情報の配置
law-of-similarity	SIM	ビジュアルの一貫性、リンクとボタンのスタイル、コンポーネントのバリアント、ステータス色、アイコンファミリー、デザインシステムの使用法

認知と記憶

法則	コード	使用目的
cognitive-bias	CB	確認バイアス、アンカリング、利用可能性ヒューリスティック、フレーミング、デフォルト効果、社会的証明 — 設計上の決定の歪みとユーザーの判断の偏りの両方をチェックする
cognitive-load	CL	タスクの複雑さ、情報密度、進行状況の追跡、分割、ステッピング、指示、ヘルプ、フォームの長さ、新規ユーザーとエキスパートのバランス
flow	FLO	中断、マルチタスク、集中状態、バッチアクション、ショートカット、チャネル、システムモーダル、すべてのアクションの即時フィードバック
mental-model	MM	メンタルモデルの一致、メタファー、affordance（アフォーダンス）、signifier（シグニファイア）、学習曲線、異なるプラットフォームやドメインからの転送
paradox-of-the-active-user	PAU	学習とタスク完了のトレードオフ、オンボーディング、ジャストインタイムヘルプ、プログレッシブディスクロージャー、探索 vs 効率性
working-memory	WM	フォームの長さ、マルチステップフロー、データ入力、計算、比較、情報を保持する必要性、チャンキング戦略

行動と時間

法則	コード	使用目的
doherty-threshold	DOH	応答時間、インタラクションラグ、フィードバックのタイミング、プログレスインジケーター、アニメーションの持続時間、待機中の知覚される時間
goal-gradient-effect	GG	プログレスバー、チェックリスト、リワード、達成度表示、マイルストーン、目標に向けた勢いを作るフロー
hicks-law	HIC	メニュー/リスト/グリッド内の選択肢の数、分類、カテゴリ別グループ化、検索、フィルター、ページネーション戦略
parkinsons-law	PKL	時間制限、期限切れ状態、期限のない自動保存、アイドル状態のタイムアウト、予備動作
peak-end-rule	PER	オンボーディング、チェックアウト、データ入力、エラー処理、キャンペーン、トライアル — 感情のピークと終了が全体的な記憶を支配するあらゆるフロー
postels-law	POS	入力検証、形式の寛容さ、データ調整、自動修正、フォーマットエラー、タイプミス、国際化、アクセシビリティ
serial-position-effect	SPE	メニュー、リスト、ドロップダウン、設定パネル、アコーディオン、ステップワイズフォーム、ページ付けされた結果、グループ化
teslers-law	TES	複雑さのバランス（システム対ユーザー）、自動化決定、隠された複雑さ、構成可能なもの、デフォルト、ルールと例外
zeigarnik-effect	ZEI	中断されたフロー、進行中のタスクの視覚化、下書きの保存、マルチステップ手続き、アクション可能な通知、コールドスタート

意思決定とシステム

法則	コード	使用目的
choice-overload	COL	多すぎるオプション、カスタマイズ設定、プラン比較、カタログ、価格表、設定画面、ソートとフィルタリング
fitts-law	FIT	タップ/クリックターゲットサイズ、エッジとコーナーの位置、マージン/パディング、ステアリング、タッチとマウスのコントロール、アクセシビリティのターゲットサイズ
jakobs-law	JAK	プラットフォームの慣例、OS標準との一致、予測可能なデザインパターン、ユーザーの期待、クロスプラットフォームの一貫性
occams-razor	OCC	機能範囲、UIの複雑さ、設定 vs デフォルト、オンボーディング、設定可能性、不必要な選択とルール
pareto-principle	PAR	優先順位付け、MVPスコープ、80/20分析、機能の使用頻度、リソース配分、パフォーマンス最適化の焦点

ゲシュタルト

法則	コード	使用目的
law-of-common-region	CR	カード、パネル、セクション、境界線、背景塗り、テーブル行、フォームグループ、アイテムが一緒に属することを示すための任意のコンテナ
law-of-pragnanz	PRG	アイコン、イラスト、データ可視化、レイアウトのシルエット、ロゴ、一目で理解されなければならない視覚要素
law-of-proximity	PRX	スペーシング、レイアウト密度、ラベルとフィールドの関連付け、コントロールとコンテンツのグループ化、スペーシングスケール
law-of-similarity	SIM	ビジュアルの一貫性、リンクとボタンのスタイル、コンポーネントのバリアント、ステータス色、アイコンファミリー、デザインシステムの使用法
law-of-uniform-connectedness	UC	図、ダイアグラム、ネットワークビュー、フローチャート、ツリー、線による接続、一貫したストロークを持つ任意のビジュアルグループ化