design-better

Design Better

あらゆるコーディングエージェントが UI を生成またはレビューする際の、クラフト層です。スタイルは docs/design.md が担い、このスキルは Nielsen Norman Group、Laws of UX、Shneiderman、Refactoring UI、WCAG 2.2、Don Norman、Apple HIG、Material 3、そして 2025〜2026 年の AI プロダクトのパターンに基づく、時代を超えて通用する UX/UI のクラフトに関するヒューリスティックを担います。これらが「リリースした」と「設計した」の違いを生みます。

境界。 ヒューリスティックが視覚的なプロパティを示唆する場合は、docs/design.md のトークンを名前で参照します（{colors.primary}、{rounded.md}）。docs/design.md にそのトークンがない場合は、Design System スキルで追加する新しいパターンとして指摘します。16 進数、フォント名、任意の px 値を直接記述してはいけません。docs/design.md 自体が存在しない場合は、そのプロパティについてコードベースに既存の規約（テーマ設定、CSS カスタムプロパティ、コンポーネントライブラリ）があればそれに従い、その旨を記します。

入力

• docs/design.md — スタイル層です（推奨ですが、必須ではありません）。存在する場合は、すべての視覚的な判断でトークンを名前で参照します。存在しない場合も、このスキルは適用されます。その場合は、コードベースにある既存のデザイン規約（テーマ設定、CSS カスタムプロパティ、既存コンポーネント）をスタイルの基準として使用し、単一の信頼できるトークンソースを確立するために Design System スキルの実行を推奨します（BuilderOS の一部：https://github.com/BuildGreatProducts/builder-os）。
• 構築またはリファクタリングするもの — 概要、ファイル、または未コミットの差分です。
• docs/product-vision.md — 任意です。その戦略とブランドはマイクロコピーのトーンに反映され、どのヒューリスティックのカテゴリを重視するかを判断する助けになります。

ワークフロー

1. スタイルの基準を確立します。 docs/design.md が存在する場合は、そのトークンカタログ（色、タイポグラフィ、角丸、間隔、コンポーネント）と Markdown のルール（エレベーション、形状、Do's and Don'ts）を読み取ります。存在しない場合は、コードベースにある既存のデザイン規約（テーマ設定（例：Tailwind／tokens）、CSS カスタムプロパティ、使用中のコンポーネントライブラリ）を特定し、それらをスタイルの基準とします。そのうえで、今後の作業で文書化された信頼できる情報源を参照できるよう、Design System スキルを推奨します。

2. 対象範囲と重視する項目を確認します。 対象画面（登録／ダッシュボード／チャット／設定／詳細／マーケティング）と、重視するヒューリスティックのカテゴリを明確にします。登録画面ではフォーム、状態、アクセシビリティ、マイクロコピーを重視し、データダッシュボードでは階層、IA、認知負荷を重視し、AI チャットでは AI プロダクト向けの項目を重視します。

3. 両方の層を使って生成またはレビューします。 視覚的な判断すべてにスタイルの基準（docs/design.md のトークン、またはコードベースの規約）を使用し、クラフトに関する判断すべてにヒューリスティックカタログと Laws of UX を使用します。レビューでは、ヒューリスティックを番号で、法則を名前で示します（「H22 — 送信後にエラーにするのではなく、無効状態にする」、「Hick's Law — 1 つのステップに選択肢が多すぎる」）。

4. 納品前のチェックリスト：

   • すべてのインタラクティブ要素に、デフォルト、ホバー／フォーカス可視、アクティブ、無効、読み込み（非同期の場合）の各状態がある。
   • すべての非同期画面について、空、読み込み、エラー、成功の 4 つの状態すべてを設計し、実装している。
   • すべてのフォーム入力に、プログラムから関連付けられた <label>、適切な inputmode／type、autocomplete 属性、onBlur 検証がある。
   • すべてのモーションが 150〜400 ms で、方向に応じたイージング（進入時は out／退出時は in／移動時は in-out）を使用し、transform／opacity のみをアニメーションし、prefers-reduced-motion に対応している。
   • 本文テキストのコントラスト比が 4.5:1 以上、UI コンポーネントが 3:1 以上、フォーカスリングが 2 px 以上の太さで 3:1 以上である。
   • ポインターのターゲットが 24×24 CSS px 以上（タッチでは 44×44 以上）である。
   • 横スクロールなしで、幅 320 CSS px のレイアウトが機能する。
   • 主要なアクションが、その画面で唯一、視覚的に最も目立つ要素である。
   • すべての視覚的な判断が docs/design.md のトークンを参照している（デザインシステムがない場合は、コードベースの規約を参照）。不足しているトークンは新しいパターンとして指摘し、その場で作り出さない。

5. 納品します。 どのヒューリスティックカテゴリと Laws of UX を重視したかを記載し、ヒューリスティックまたは法則を意図的に適用しなかった場合は、そのトレードオフを明示します。

ヒューリスティック・カタログ（50 項目）

各項目：番号（レビューで引用）＋短い名前＋1 行のルール＋コードでの対応。全体を通してスタイルに依存しません。すべての視覚的プロパティは docs/design.md（存在しない場合はコードベースのデザイン規約）に従ってください。

視覚的階層と強調

H1. 1 つのビューにつき主要アクションは 1 つ（フォン・レストルフ効果）。 主要な CTA を、視覚的に際立つ唯一の要素にします。最も目立つデザイントークンの色と、最も大きなボタンサイズを使います。副次的なアクションには、より控えめなトークンを使います。

H2. サイズだけでなく、サイズ＋ウェイト＋色で階層を作る（Refactoring UI）。 副次的なテキストを目立たなくするには、フォントサイズを小さくする前に、ウェイトを下げるか、セカンダリテキストカラーのトークンに切り替えます。

H3. 近接でグループ化し、余白で区切る（ゲシュタルト）。 関連するフィールドは小さな gap でまとめ、関連のないグループはより大きなスペーシングトークンで区切ります。

H4. 共通領域でグループの境界を示す（ゲシュタルト）。 近接だけでは不十分な場合は、デザインシステムのエレベーション／サーフェストークンを使い、カード、区切り線、または色付きのサーフェスで囲みます。

H5. 余白はツールです。まずは多めに（Refactoring UI）。 ゆとりのあるパディングは、自信のある印象を与えます。余白を詰めるのは意図的に行い、デフォルトにはしません。

H6. スペーシングスケールに合わせ、1 ピクセルのずれもなくす（仕上げ）。 すべてのマージン／パディング／ギャップにデザイントークンを使います。グリッドへの整列が、「デザインされたもの」と「下書き」の違いを生みます。

レイアウトと整列

H7. div や ARIA より先にセマンティック HTML を使う（WCAG 1.3.1）。 <main>、<nav>、<header>、<section>、<article>、<button>、<label> を使います。適切なネイティブ要素がない場合に限り、role= を使います。

H8. 読みやすい行の長さは 50～75ch。 max-width: 65ch（または同等の指定）で、文章コンテナーの幅を制限します。

H9. 320 CSS px でリフローする（WCAG 1.4.10）。 すべてのビューは幅 320 px で、横スクロールなしに表示できるようにします。

H10. テキスト間隔の変更に耐える（WCAG 1.4.12）。 行の高さ（1.5 倍以上）、文字間隔（0.12em 以上）、単語間隔（0.16em 以上）をユーザーが上書きしても、レイアウトが崩れないようにします。

タイポグラフィの工夫

H11. ドキュメント化された文字スタイルのレベルのみを使う。 すべての font-size／font-weight で、タイポグラフィトークンを参照します。

H12. データには等幅数字を使う（font-variant-numeric: tabular-nums）。 テーブル、ダッシュボード、台帳の数字を縦に揃えます。

H13. モダンなテキスト折り返しを使う（見出しには balance、文章には pretty）。 見出しには text-wrap: balance を指定すると、より整った印象になります。本文の段落には text-wrap: pretty を指定し、行末に孤立した語が残るのを防ぎます。

色とコントラスト（スタイルに依存しない）

H14. 本文テキストのコントラスト比は 4.5:1 以上（WCAG 1.4.3 AA）。 本文と背景のトークンのすべての組み合わせを検証します。大きなテキスト（太字で 18.66 px 以上、または 24 px 以上）には 3:1 以上が必要です。

H15. UI コンポーネントのコントラスト比は 3:1 以上（WCAG 1.4.11）。 フォームの境界線、アイコンのみのボタン、フォーカスリング、グラフの線はすべて、隣接する色とのコントラスト比を 3:1 以上にします。

H16. 色だけを唯一の手がかりにしない。 色で表す状態には、必ずアイコン、ラベル、またはパターンを組み合わせます。

インタラクションとフィードバック

H17. 100 ms 以内にフィードバックを返す（ドハーティ／ノーマン）。 ロジックを実行するすべてのアクションに対し、100 ms 以内に視覚的な反応（押下状態、リップル、楽観的更新、スケルトン）を返します。

H18. インタラクティブ要素には最低 3 つの状態を設ける。 デフォルト、ホバーまたは可視フォーカス、アクティブ、無効の状態を用意します。非同期処理の場合は、さらに読み込み状態を加えます。

H19. 操作できることが見た目で伝わるようにする。 ボタンは押せるように見せ、リンクは本文テキストと明確に区別します。視覚的な表現にはデザイントークンを使います。

H20. 隠れた操作よりも見つけやすさを優先する（ノーマン）。 重要なアクションはデフォルトで見えるようにし、ホバー、長押し、または明示されていないジェスチャーの背後に隠しません。

H21. 簡単に元に戻せるようにする（シュナイダーマン）。 破壊的なアクションには取り消し、すべてのモーダルにはキャンセル、データを失わずに戻れる手段、削除したデータには復元機能を用意します。

H22. 制約によってエラーを防ぐ（ノーマン）。 無効な選択肢は無効化し、入力には min、max、step、pattern、type を指定します。入力が有効な場合にのみ送信できるようにします。

フォーム

H23. 単一カラムのレイアウトで、ラベルは上揃えにします。 縦に並べ、入力欄の上にラベルを配置します。プレースホルダーをラベルの代わりにしてはいけません。

H24. モバイルキーボードには inputmode と type を指定します。 type="email"、inputmode="numeric"／"decimal"、type="tel"、type="url" を使用します。

H25. autocomplete 属性を設定します。 email、name、new-password、one-time-code、postal-code などを指定します。ユーザーの入力時間を30秒短縮し、パスワードマネージャーも利用できます。

H26. フォーカスが外れたときにインライン検証し、変更時にエラーを消します。 onBlur で検証し、入力が有効になったら onChange でエラーを消します。キー入力のたびに検証すると、タイプミスをしたユーザーに負担をかけます。

H27. スマートなデフォルト値で複雑さを吸収します（テスラーの法則）。 タイムゾーン、ロケール、通貨を検出し、安全な選択肢をあらかじめ選択します。「明日の午後3時」のような自然言語を解析し、以前の入力内容を使って事前入力します。

状態：空、読み込み中、エラー、成功

H28. あらゆるデータビューに4つの状態を用意します。 空、読み込み中、エラー、成功の各状態を、デザイントークンを使って設計・実装します。

H29. コンテンツにはスピナーよりスケルトンを使います（NN/g）。 最終的なレイアウトと同じ寸法で、形状を合わせたプレースホルダーを使用します（CLS を防止します）。

H30. リスクの低い操作には楽観的 UI を使います。 「いいね」、切り替え、フォローは即座に更新し、バックグラウンドで整合性を取り、失敗した場合はトーストを表示して元に戻します。

H31. 空の状態は第一印象を左右します。 空のリストにはそれぞれ、表示される内容の説明を1行で示し、主要な CTA を用意します。

H32. エラーでは、何が起きたか、なぜ起きたか、どう解決するかを伝えます。 「問題が発生しました」だけで済ませてはいけません。必ず再試行または復旧の手段を提示します。

モーション

H33. UI のモーションは150～400 ms の範囲にします（NN/g、Material 3）。 マイクロモーションは100～150 ms（ホバー、切り替え）、標準は200～300 ms（メニュー、モーダル）、大きなモーションは300～400 ms（ページ遷移）です。繰り返し表示される UI のアニメーションは500 ms を超えてはいけません。

H34. イージングを動きの方向に合わせます。 入場にはイーズアウト（cubic-bezier(0, 0, 0.2, 1)）、退場にはイーズイン、画面上の2つの状態間の移動にはイーズイン・アウトを使います。

H35. アニメーションは transform と opacity のみに適用します。 GPU で高速化されます。width／height／top／left をアニメーションさせてはいけません。

H36. prefers-reduced-motion を尊重します。 必須ではないモーションは @media (prefers-reduced-motion: reduce) で囲みます。transform は即時変更または短い opacity フェードに置き換えます。フィードバックのシグナルを完全に取り除いてはいけません。

アクセシビリティ（WCAG 2.2 AA）

H37. すべての要素をキーボードで操作できるようにします（WCAG 2.1.1）。 すべてのインタラクティブ要素に Tab／Shift+Tab／Enter／Space／Arrow キーでアクセスできるようにします。モーダル内のフォーカストラップも機能させます。

H38. フォーカスリングを見えるようにします（WCAG 2.4.7）。 :focus-visible による同等の表示を用意せずに outline: none を指定してはいけません。フォーカスリングは2 px 以上、コントラスト比は3:1 以上にします。定義済みの場合は、デザインシステムのフォーカストークンを使用します。

H39. ポインターターゲットのサイズは24×24以上にします（WCAG 2.5.8）。 クリック可能なすべての要素を CSS px で24×24以上にします。タッチ操作では、44×44（Apple HIG）または48×48（Material 3）を目安にします。

H40. ラベルをプログラムで関連付けます（WCAG 3.3.2）。 すべての入力欄に <label htmlFor=id> を関連付けるか、入力欄をラベルで囲みます。aria-label は、入力欄に視覚的なラベルが本当に存在しない場合に限って使用します。

H41. フォーカスが隠れないようにします（WCAG 2.4.11）。 固定ヘッダーやフッターで、フォーカス中の要素を覆ってはいけません。固定要素の高さに合わせて scroll-padding-top／-bottom を設定します。

H42. アクセシブルな認証を提供します（WCAG 3.3.8）。 ログインに認知能力を試すパズルを使ってはいけません。パスワード欄への貼り付けを許可します。OTP には autocomplete="one-time-code" を設定します。

モバイルとタッチ

H43. 主要な CTA は親指が届く範囲に配置します。 モバイルでは、主要な操作を画面の下半分に配置します。頻繁に使う操作を画面上部の隅に置くのは避けます。

H44. セーフエリアのインセットを尊重します。 固定またはスティッキーな下部バーと、画面幅いっぱいのヘッダーには env(safe-area-inset-*) を使用します。

H45. 重要な情報をホバー時だけ表示してはいけません。 :hover のみで表示されるツールチップは、タッチ操作では見えません。重要なコンテンツはデフォルトで表示します。

H46. ドラッグ操作にはタップでの代替手段を用意します（WCAG 2.5.7）。 並べ替え、削除、サイズ変更をドラッグで行う場合は、同等のボタンまたはメニューも用意します。

認知負荷とナビゲーション

H47. ナビゲーションは5〜9項目以内に（ミラーの法則）。 最上位のナビゲーションはマジックナンバーの範囲内に収め、残りはメニュー、コマンドパレット、または設定に移します。

H48. 想起より認識を（NN/g #6）。 選択中のフィルター、現在のページ（アクティブなナビゲーション状態）、パンくずリスト、最近使った項目を表示します。前の画面で見た値をユーザーに覚えておかせてはいけません。

AI プロダクト固有の指針（2025〜2026年）

H49. ストリーミングと停止は主要な操作です。 AI の回答は生成と同時にストリーミング表示します。ストリーミング中は、主要な操作として目立つ［停止］ボタンを表示し、UI だけでなく基盤となるリクエストを中断できるようにします。ツール呼び出し、思考、検索は、ラベル付きのステップとして表示します。

H50. AI の出力は編集可能な下書きです。 モデルの回答は、ユーザーが編集、一部採用、再生成、または却下できる下書きとして扱います。出典は文中に引用し、ワンクリックで開けるようにします。エラーの種類（ネットワーク、レート制限、コンテンツフィルター、モデルエラー）を区別し、それぞれに適した復旧方法を用意します。

UX の法則

上記の50のヒューリスティックは実践的なチェックリストであり、以下の UX の法則はその背後にある心理学的原則です。lawsofux.com をもとにしています。関連する場面で適用し、特に直接対応するヒューリスティックがない法則を重視します。レビューでは法則名を挙げてください（「ヒックの法則 — 1つのステップに選択肢が多すぎます」）。ヒューリスティックがすでに法則を具体化している場合は、↔ H# の相互参照が示されています。法則とヒューリスティックは、同じルールを異なる角度から捉えたものとして扱います。法則は「なぜ」、ヒューリスティックは「確認項目」です。

知覚とグルーピング — ユーザーがレイアウトを視覚的に把握する方法

近接の法則。 近くに配置されたオブジェクトは、ひとまとまりとして認識されます。関連するフィールドやコントロールは小さな gap でまとめ、関連のないグループはより大きなスペーシングトークンで分けます。↔ H3

共通領域の法則。 共通の明確な境界内にある要素は、ひとまとまりとして認識されます。近接だけでは不十分な場合は、カード、区切り線、またはエレベーション／サーフェストークンを使った色付きの面で関連する項目を囲みます。↔ H4

類似性の法則。 視覚的な特徴が共通する要素は、関連があると認識されます。同じ機能を持つ要素には同じデザインを適用し（すべての主要アクションに同じボタントークンを使う、すべてのリンクを同じスタイルにするなど）、本当に異なるものは見た目も異なるようにします。↔ H16、H19

一様な結合性の法則。 視覚的につながった要素は、単に近くにある要素よりも関連が深いと認識されます。近接だけに頼るのではなく、共通のコンテナー、背景、または接続線（セグメントコントロールやラベル付きフィールドグループなど）を使って、関連するコントロールをつなげます。

プレグナンツの法則。 人は曖昧または複雑な形を、可能な限り単純に解釈します。シンプルで規則的な形とすっきりしたレイアウトを優先し、ひと目で構造がわかるように視覚的な複雑さを抑えます。

美的ユーザビリティ効果。 ユーザーは美しいデザインほど使いやすいと感じ、軽微な問題を許容します。ヒューリスティックに沿って、スペーシング、文字組み、仕上げなどのビジュアル品質に投資します。ただし、表面的な仕上がりで、テストによって明らかになった実際のユーザビリティ上の問題を覆い隠してはいけません。

選択肢と認知負荷 — 判断して行動する労力を減らす

ヒックの法則。 選択肢の数と複雑さが増えるほど、意思決定にかかる時間も長くなります。各ステップの選択肢を減らし、段階的開示を使い、安全なデフォルトをあらかじめ選択し、長いフローはステップに分割します。↔ H47

選択肢の過多。 選択肢が多すぎると、ユーザーは圧倒され、行動が止まります。選択肢を厳選して順位付けし、おすすめのデフォルトを提示し、一度にすべて表示するのではなく、重要度の低い選択肢を絞り込むか折りたたみます。

ミラーの法則。 ワーキングメモリーが保持できる項目は約7±2個です。コンテンツやナビゲーションを小さなグループに分け、トップレベルのナビゲーションはマジックナンバーの範囲内に収め、残りはメニューやコマンドパレットに移します。↔ H47

チャンク化。 情報は意味のある単位にまとめると、処理しやすくなります。長い文字列（電話番号、カード番号、ID）を読みやすく整形し、フォーム項目、ナビゲーション、コンテンツを把握しやすいまとまりにグループ化します。↔ H3

認知負荷。 要素、ラベル、ステップが一つ増えるごとに、精神的なリソースが消費されます。余計な負荷を減らし、記憶の負担はインターフェースに移します（ユーザーに思い出させるのではなく、表示します）。装飾的なノイズを取り除き、各画面の主な役割を一つに絞ります。

ワーキングメモリー。 ユーザーは前の画面の値を確実に覚えておけるとは限りません。選択したフィルター、前回の入力内容、現在のステップを表示するなど、コンテキストを引き継ぎ、画面をまたいで再入力や記憶を求めないようにします。↔ H48

選択的注意。 ユーザーは目標に関係する画面の一部に集中し、それ以外を無視します（バナー盲目）。重要な情報やアクションは目標達成の経路上に配置し、広告のような領域や簡単に閉じられるクロームの中に隠さないようにします。

オッカムの剃刀。 同等の解決策があるなら、要素が最も少ないものが選ばれます。存在する価値のない要素、選択肢、ステップは取り除きます。最善のインターフェースとは、目的を果たせる範囲で最もシンプルなものです。

テスラーの法則（複雑性保存の法則）。 どのシステムにも、削減できない複雑さがあります。問題は、それを誰が負担するかだけです。追加の入力項目や選択肢を増やすのではなく、スマートなデフォルト、推測、適切な自動化によって、ユーザーではなくシステム側で負担します。↔ H27

認知バイアス。 ユーザーの判断は、体系的なバイアス（アンカリング、フレーミング、デフォルト）の影響を受けます。ユーザーが適切に判断できるよう、誠実に配慮して設計します。操作を目的としてはなりません。ダークパターン、強制的な継続、誤解を招くフレーミングは避けます。

パレートの法則。 利用のおよそ80％は、機能の20％から生まれます。高頻度の利用経路を特定し、素早く分かりやすく使えるようにします。利用頻度の低い機能で、一般的な機能を埋もれさせないようにします。

記憶と注意 — ユーザーが覚えていること、引きつけられるもの

フォン・レストルフ効果（孤立効果）。 似た項目の中では、異なる項目が記憶に残ります。主要なアクションを一つだけ視覚的に目立たせ、強調は控えめに使い、その意味が保たれるようにします。↔ H1

系列位置効果。 人は一連の項目の最初と最後を最もよく覚えています。最も重要なナビゲーション項目やアクションは、リスト、メニュー、バーの先頭と末尾に配置し、重要度の低いものは中ほどに置きます。

ツァイガルニク効果。 未完了のタスクは記憶に残りやすく、完了させようとする意欲を生みます。進捗インジケーター、チェックリスト、「Y個中X個完了」といった表示を使い、オンボーディング、セットアップ、複数ステップのフローの完了を促します。

目標勾配効果。 目標に近づくほど、モチベーションは高まります。進捗を表示し、残りのステップが少なく感じられるようにします。進捗バー、ステップカウンター、最初のステップを事前入力して、ゼロより先の状態から勢いをつけます。

ピーク・エンドの法則。 人は体験の中で最も強烈な瞬間と終わりによって、その体験を評価します。ピーク（マジックモーメント）と終わり（成功、初回の成功、サインオフの状態）に力を入れます。成功の瞬間には、簡素なトーストだけで済ませず、きちんとデザインを施します。

期待と振る舞い — ユーザーの実際の行動に合わせる

ヤコブの法則。 ユーザーはほとんどの時間をほかの製品で過ごしており、あなたの製品も同じように動作することを期待しています。一般的な UI（ナビゲーション、フォーム、アイコン、ジェスチャー）には、確立された慣習やプラットフォームのパターンに従い、本当に効果がある場合にのみ新しさを取り入れます。↔ H20

メンタルモデル。 ユーザーは、システムがどのようなもので、どう動くのかという自分の認識に基づいて行動します。なじみのあるラベル、メタファー、フローを用いて、期待されるモデルに合わせます。新しいモデルを覚えさせるのではなく、ユーザーのモデルとシステムのモデルの隔たりを埋めます。↔ H48

アクティブユーザーのパラドックス。 ユーザーはマニュアルを読み飛ばし、読んだほうが早い場合でもすぐに使い始めます。最もスムーズな操作経路をひと目で分かるようにし、ガイダンスはドキュメントではなく、画面内の適切な場所に表示します。また、説明がなくても成功できるように設計します。

ポステルの法則。 入力の受け入れには寛容に、出力の生成には慎重にします。雑多で多様な入力（空白のトリミング、日付や電話番号の形式の解析、大文字と小文字を区別しない処理）を受け入れ、明確で一貫性のある、適切な形式の出力を返します。↔ H26, H27

パーキンソンの法則。 作業は、与えられた時間いっぱいまで膨らみます。自動入力、スマートなデフォルト、適切な制約を用いて完了までの時間を短縮し、ユーザーがそうでなければ必要だった時間より早く作業を終えられるようにします。↔ H27

フロー。 ユーザーは作業に深く没頭しているとき、最も力を発揮します。集中を妨げないようにします。中断を最小限に抑え、作業の途中で不必要なモーダルや確認を表示せず、状態を維持し、完了までの流れを途切れさせません。

パフォーマンスと応答性 — ユーザーの時間を尊重する

ドハーティのしきい値。 システムとユーザーが 400 ms 未満で応答し合うと、生産性は大きく向上します。オプティミスティック UI、スケルトン、即時の押下フィードバックなどを使って操作にすばやく反応し、ユーザーがインターフェース上で待たされないようにします。↔ H17

フィッツの法則。 ターゲットを操作するまでの時間は、ターゲットまでの距離とサイズによって決まります。頻繁に使う主要なターゲットは大きくし、ユーザーが現在いる場所の近くに配置します。タップ領域には十分な余裕を持たせ、モバイルの主要な操作は親指が届く範囲に配置します。↔ H39, H43

新しいパターンへの対応

ヒューリスティックの適用にあたり、docs/design.md にまだ定義されていない視覚的なプロパティ（新しいカラーの役割、不足している余白の段階、ドキュメント化されていないコンポーネントのバリエーションなど）が必要になった場合、値をその場で決して作り出さないでください。 代わりに、次のように対応します。

• docs/design.md が存在する場合 — デリバリーノートで不足箇所を新しいパターンとして指摘します（対象のプロパティ、ヒューリスティックが示す値、必要な箇所）。トークンカタログの編集を担当し、docs/design.html との同期を維持する Design System スキルを使って、docs/design.md に追加することを提案します。それまでは最も近い既存のトークンを使います。
• docs/design.md が存在しない場合 — そのプロパティについて、コードベースの既存の規約（テーマ設定、CSS カスタムプロパティ、コンポーネントライブラリ）に従い、その旨を記載します。プロジェクトにドキュメント化された信頼できる情報源を用意するため、Design System スキルの実行を提案します。

完了の基準

生成またはレビューした UI がワークフローのステップ 4 にある事前チェックリストをすべて満たしており、すべての視覚的な判断が docs/design.md のトークン（デザインシステムがない場合はコードベースの規約）を参照していること、主要なアクションが視覚的に最も目立つ唯一の要素（H1）であること、マイクロコピーが平易な言葉で書かれていること、エラーに内容・原因・解決方法が記載されていること（H32）、成功した瞬間を大切にしていること（ピーク・エンドの法則）、デザインシステムにまだないトークンはその場で作り出さず、Design System スキルで追加する新しいパターンとして指摘されていること。

推奨する併用方法：このスキルを Build Loop と併用してください。Build Loop のレビューステップ（/review、機密性の高い画面では /security-review）で、見逃されやすいトークンの不整合やアクセシビリティの低下を検出できます。また、指摘された新しいパターンは、コミット前に Design System スキルを使って docs/design.md に反映します。