mcpField
L
laws-of-ux

laws-of-ux

github.com/rolemodelデザイン・UI781 回インストール2 日前に更新
リポジトリ

laws-of-ux について

laws-of-uxは、21のUX法則を用いてUIをレビュー・構築するスキルです。既存UIコードの確認と新機能の設計支援に対応し、認知、視覚、インタラクションの観点を扱います。

主な機能

  1. 0121のUX法則に基づくUIレビュー
  2. 02新機能のUX設計ガイダンス
  3. 03認知・視覚・操作の観点で法則を分類
  4. 04チェックリストで関連法則を特定
  5. 05コードからUIパターンと使いやすさを確認

活用シーン

  1. 01既存UIコードの使いやすさをレビュー
  2. 02新機能の画面と操作を設計
  3. 03ナビゲーション、フォーム、ボタン配置を確認
  4. 04UX原則に基づくUI監査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/rolemodel/rolemodel-skills --skill laws-of-ux

インストール後、Claude Code で/laws-of-uxを入力して読み込まれたか確認します。

詳細

概要

このスキルは、21 Laws of UX を用いてユーザーインターフェイスをレビューし、構築するための指針を AI に提供します。目的は次の 2 つです。

  1. レビュー モード：既存の UI コードを分析して UX 原則への違反を特定し、改善案を提案します。
  2. ガイダンス モード：新機能の構築時に UX の法則を適用し、最初から使いやすく直感的なインターフェイスを実現します。

法則は、ユーザー体験のどの側面を扱うかに応じて、次の 3 つのカテゴリに分けられています。

  • 認知と意思決定 — ユーザーの思考と情報処理の方法
  • 視覚と知覚 — ユーザーが視覚的なレイアウトを見て解釈する方法
  • 行動とインタラクション — ユーザーがインターフェイス上で行動し、反応する方法

コードをレビューする際は、まずレビュー用チェックリストを確認して、どの法則が最も関連するかを特定し、その後、詳細な解説と例を参照してください。

キーワード：UX レビュー、UI レビュー、ユーザビリティ、Laws of UX、UX のベストプラクティス、ユーザー体験、UX 監査、UI パターン

レビュー用チェックリスト

この表を使うと、すばやく確認できます。各チェック項目は 1 つ以上の法則に対応しており、コードで確認すべき内容を示します。

チェック項目法則確認する内容
ナビゲーションの最上位項目が 7 個以下であるミラーの法則nav、メニュー、サイドバー — 直接の子要素を数える
各ステップの選択肢が最小限に抑えられているヒックの法則<select> の選択肢数、ラジオボタングループ、ボタン配列
クリック対象のサイズが少なくとも 44x44px であるフィッツの法則ボタン／リンクの min-height、min-width、padding
重要なアクションが大きく、アクセスしやすいフィッツの法則CTA のサイズとレイアウト内の配置
400ms 以内に読み込みのフィードバックが表示されるドハティの閾値スピナー、スケルトンスクリーン、disabled の状態
フォームが柔軟な入力形式を受け付けるポステルの法則入力値の検証、マスキング、書式要件
主要な CTA が 1 つだけ視覚的に目立つフォン・レストルフ効果ボタンのバリアントクラス、色の強調
関連する項目が視覚的にグループ化されている近接、共通領域余白、境界線、背景によるグループ化
複数ステップのフローに進行状況インジケーターがあるツァイガルニク効果、目標勾配ステップインジケーター、進捗バー
リストの先頭と末尾に重要なアクションがある系列位置効果ナビゲーションの順序、リスト構造
インターフェイスがプラットフォームの慣習に従っているヤコブの法則標準的なパターンとカスタムウィジェットの比較
UI が洗練され、一貫性のある見た目である美的ユーザビリティ効果デザイントークンの使用、一貫したスタイル
ユーザーではなくシステムが複雑さに対処しているテスラーの法則スマートなデフォルト、自動検出、事前入力された値
最もよく使われる機能が優先されているパレートの法則レイアウトの階層、機能の目立ちやすさ
フォームとフローの範囲が適切であるパーキンソンの法則ステップ数、フィールド数、時間制限
最後のインタラクションが良い印象を残すピーク・エンドの法則成功時の状態、確認ページ、エラーからの回復
視覚的な階層が明快でシンプルであるプレグナンツの法則レイアウトの明瞭さ、視覚的なノイズの少なさ
一貫した視覚スタイルが関連性を示している類似性の法則関連要素に一貫したクラスを使用
つながった要素が共通の視覚的な目印を持つ一様な連結性線、境界線、共通の背景
最もシンプルな説明が選ばれるオッカムの剃刀UI の複雑さとタスク要件の比較
複数ステップのタスクで進行状況と勢いを示す目標勾配効果進捗バー、ステップ完了のフィードバック

認知と意思決定の法則

これらの法則は、ユーザーが情報を処理し、判断を下し、認知的な負荷を管理する方法を扱います。

ミラーの法則

定義：人が一度にワーキングメモリに保持できる項目数は、平均して約7（±2）です。

重要なポイント：コンテンツを5～9項目のグループに分割します。さらに項目が必要な場合は、階層化やグループ化を活用して認知負荷を軽減します。

コードで確認すること：

  • ナビゲーションメニュー、タブバー、サイドバーの直下にある項目数を数える
  • 一度に表示されるフォームフィールドの数（スクロールなし）を数える
  • ドロップダウンの選択肢やラジオボタングループの選択肢の数を数える
  • 長いリストが論理的なグループに分割されているか確認する

例：

✅ GOOD

<nav class="main-nav">
  <a href="/dashboard">Dashboard</a>
  <a href="/projects">Projects</a>
  <a href="/team">Team</a>
  <a href="/reports">Reports</a>
  <a href="/settings">Settings</a>
</nav>

🚫 BAD

<nav class="main-nav">
  <a href="/dashboard">Dashboard</a>
  <a href="/projects">Projects</a>
  <a href="/team">Team</a>
  <a href="/reports">Reports</a>
  <a href="/analytics">Analytics</a>
  <a href="/settings">Settings</a>
  <a href="/billing">Billing</a>
  <a href="/integrations">Integrations</a>
  <a href="/support">Support</a>
  <a href="/docs">Documentation</a>
  <a href="/profile">Profile</a>
  <a href="/admin">Admin</a>
</nav>

フラットなナビゲーション項目が12個あると、ワーキングメモリに過度な負荷がかかります。ドロップダウンの下にグループ化するか、項目を統合してください。

レビュー時の確認事項：

  • トップレベル項目が7個を超えるナビゲーションにフラグを立てる
  • グループ化せずに一度に7個を超えるフィールドが表示されるフォームにフラグを立てる
  • グループ化されていない選択肢が10個を超える<select>要素にフラグを立てる（<optgroup>を提案する）
ヒックの法則

定義：選択肢の数と複雑さが増えるほど、意思決定にかかる時間も長くなります。

重要なポイント：一度に提示する選択肢の数を減らします。複雑な判断は、より小さな段階に分けて順番に提示します。

コードで確認すること：

  • 同時に表示されるアクションボタンの数を数える
  • 複雑なフォームで、1ページにまとめるのではなく、複数ステップのウィザードを使用しているか確認する
  • 必要なときだけ選択肢を追加表示する段階的開示のパターンを探す
  • デフォルトまたは推奨の選択肢が強調表示されているか確認する

例：

✅ GOOD

<div class="pricing-options">
  <div class="pricing-card">
    <h3>Basic</h3>
    <button class="btn btn--outline">Select</button>
  </div>
  <div class="pricing-card pricing-card--recommended">
    <span class="badge">Recommended</span>
    <h3>Pro</h3>
    <button class="btn btn--primary">Select</button>
  </div>
  <div class="pricing-card">
    <h3>Enterprise</h3>
    <button class="btn btn--outline">Contact Us</button>
  </div>
</div>

🚫 BAD

<div class="pricing-options">
  <div class="pricing-card"><h3>Free</h3><button class="btn">Select</button></div>
  <div class="pricing-card"><h3>Starter</h3><button class="btn">Select</button></div>
  <div class="pricing-card"><h3>Basic</h3><button class="btn">Select</button></div>
  <div class="pricing-card"><h3>Pro</h3><button class="btn">Select</button></div>
  <div class="pricing-card"><h3>Business</h3><button class="btn">Select</button></div>
  <div class="pricing-card"><h3>Enterprise</h3><button class="btn">Select</button></div>
  <div class="pricing-card"><h3>Custom</h3><button class="btn">Select</button></div>
</div>

視覚的に同じ見た目で、推奨の選択肢も示されていない選択肢が7つあります。選択肢を減らし、最適なデフォルトを強調してください。

レビュー時の確認事項：

  • 1つの画面に、同等の重み付けのアクションボタンが4～5個を超えてある場合にフラグを立てる
  • 複数ステップのプロセスで、段階的に提示せず、すべてのステップを一度に表示する場合にフラグを立てる
  • デフォルトまたは推奨の選択肢が強調表示されていない選択肢セットにフラグを立てる
テスラーの法則（複雑性保存の法則）

定義：どのアプリケーションにも、取り除いたり隠したりできない固有の複雑さがあります。それはシステムかユーザーのどちらかが対処しなければなりません。

重要なポイント：ユーザーが複雑さに対処しなくて済むように、システム側で複雑さを引き受けます。スマートなデフォルト、自動検出、事前入力済みの値を活用します。

コードで確認すること：

  • フォームフィールドにスマートなデフォルトが設定されているか確認する
  • 自動検出（タイムゾーン、ロケール、住所の自動補完など）があるか確認する
  • システムがすでに把握している値を事前入力しているか確認する
  • ユーザーの操作手順を簡略化する条件分岐を探す

例：

✅ GOOD

<form>
  <label for="phone">Phone Number</label>
  <input type="tel" id="phone" placeholder="(555) 123-4567"
         data-controller="phone-format"
         data-action="input->phone-format#format">
  
</form>

🚫 BAD

<form>
  <label for="phone">Phone Number (format: +1-XXX-XXX-XXXX)</label>
  <input type="text" id="phone" pattern="\+1-\d{3}-\d{3}-\d{4}">
  <span class="help-text">Must include country code and dashes</span>
</form>

書式設定の負担がシステムではなくユーザーにかかっています。

レビュー時の確認事項：

  • システム側で自動書式設定できるのに、ユーザーに特定の形式を求めるフォームにフラグを立てる
  • システムがすでに把握している情報を尋ねるフィールドにフラグを立てる（例：ログイン中にメールアドレスを再入力させる）
  • 妥当な値があるのに、スマートなデフォルトが設定されていない場合にフラグを立てる
オッカムの剃刀

定義：同じ観察結果を説明する仮説が複数ある場合、前提が最も少ないものを選ぶべきです。

重要なポイント：タスクを達成できる、最もシンプルなUIを優先します。不要な要素、手順、視覚的な複雑さを取り除きます。

コードで確認すること：

  • 使われていない、または冗長なUI要素（目的のない装飾要素）がないか確認する
  • よりシンプルな構造で対応できるのに、コンポーネント階層が過度に複雑になっていないか確認する
  • 異なるスタイルや視覚的な表現の種類が、必要な範囲に収まっているか確認する

例：

✅ GOOD

<div class="empty-state">
  <p>No projects yet.</p>
  <a href="/projects/new" class="btn btn--primary">Create your first project</a>
</div>

🚫 BAD

<div class="empty-state">
  <img src="/images/empty-illustration.svg" alt="">
  <h2>Welcome to Your Dashboard!</h2>
  <p>It looks like you haven't created any projects yet. Projects help you organize your work and collaborate with your team members efficiently.</p>
  <p>Getting started is easy — just click the button below to create your first project and begin your journey!</p>
  <a href="/projects/new" class="btn btn--primary btn--large">Create Project</a>
  <a href="/help/getting-started" class="btn btn--outline">Learn More</a>
  <p class="text-muted">You can also import projects from other tools.</p>
</div>

シンプルな空の状態に対してコンテンツが過剰です。ユーザーの目的は明確なので、すぐに行動できるよう支援してください。

レビュー時の確認事項：

  • 1つで十分なのに、複数の競合する行動喚起があるUIにフラグを立てる
  • 行動を促す場面で、コピーが過度に冗長な場合にフラグを立てる
  • 簡略化できる、深くネストされたコンポーネントツリーにフラグを立てる
パーキンソンの法則

定義：あらゆるタスクは、利用可能な時間をすべて使い切るまで膨張します。

重要なポイント：適切な境界を設定して、タスクの範囲を制限します。フォームの入力項目は必要なものだけに絞り、大きなタスクは焦点を絞ったステップに分割します。

コードで確認すること：

  • フォームの入力項目数を確認します。現在のステップで本当にすべて必要でしょうか？
  • 後のステップに回せる任意の入力項目がないか確認します
  • 各ステップの範囲が適切に設定された複数ステップのフローを確認します

レビュー時のチェック項目：

  • 目標の達成に必要な項目がもっと少ないのに、入力項目が5～7個を超えるフォームを指摘します
  • 重要な処理経路のフォームにある「任意」の入力項目を指摘します（2つ目のステップに移動します）
  • ステップ形式にすると使いやすくなる可能性のある単一ページのフォームを指摘します
パレートの法則（80/20の法則）

定義：結果のおよそ80％は、原因の20％から生じます。

重要なポイント：ユーザーが最もよく利用する機能や操作の20％を特定し、目立つ位置に配置して、簡単にアクセスできるようにします。

コードで確認すること：

  • 最もよく使われる操作にすぐアクセスできることを確認します（メニューの奥に隠れていないこと）
  • レイアウトの階層を確認します。主要な機能は視覚的に目立つようにします
  • あまり使われない操作にもアクセスできる一方で、注意を引きすぎていないことを確認します

レビュー時のチェック項目：

  • 主要な操作がドロップダウンメニューや2次ナビゲーションの奥に隠れている場合は指摘します
  • すべての要素が同じ視覚的な強さを持つダッシュボードを指摘します
  • 頻繁に使うコントロールとほとんど使わないコントロールが同じ階層に混在する設定やオプションを指摘します

視覚・知覚の法則

これらの法則は、ユーザーが画面上の視覚情報をどのように認識し、解釈するかを扱います。

近接の法則

定義：近くにあるオブジェクトは、ひとまとまりとして認識される傾向があります。

重要なポイント：間隔を使って関係性を伝えます。関連する項目は近づけ、関連しない項目の間にはより広い間隔を設けます。

コードで確認すること：

  • gap、margin、padding の値を確認します。関連する項目間の間隔は、グループ間より狭くします
  • <fieldset> や、間隔を設けたラッパー div を使ってフォーム項目がグループ化されているか確認します
  • 間隔のトークンが視覚的な階層を作っているか確認します（例：グループ内には --op-space-small、グループ間には --op-space-large）

例：

✅ GOOD

.form__group {
  display: flex;
  flex-direction: column;
  gap: var(--op-space-x-small);  /* Tight spacing within group */
}

.form__section + .form__section {
  margin-top: var(--op-space-x-large);  /* Larger spacing between sections */
}

🚫 BAD

.form label,
.form input,
.form select,
.form textarea {
  margin-bottom: 16px;  /* Uniform spacing everywhere — no grouping */
}

均一な間隔では、どの入力項目が関連しているか伝わりません。

レビュー時のチェック項目：

  • 論理的なグループがあるレイアウトで、すべての項目の間隔が均一な場合は指摘します
  • 視覚的なグループ分け（<fieldset>、セクション区切り、間隔の変化）がないフォーム項目を指摘します
  • デザイントークンではなく、ハードコードされた間隔の値を指摘します（optics-context スキルを参照）
類似性の法則

定義：視覚的な特徴（色、形、大きさ）が共通する要素は、関連し、ひとまとまりであると認識されます。

重要なポイント：同じ機能を果たす要素には、一貫したスタイルを適用します。異なる用途を示すために、意図を持ってスタイルに変化をつけます。

コードで確認すること：

  • 同じ機能を持つ要素に同じ CSS クラスが使われているか確認します
  • ナビゲーション項目、カードコンポーネント、リスト項目のスタイルに一貫性があるか確認します
  • 意図的なスタイルの違いが、機能の実質的な違いを反映しているか確認します

例：

✅ GOOD

<div class="action-bar">
  <button class="btn btn--primary">Save</button>
  <button class="btn btn--outline">Cancel</button>
  <button class="btn btn--danger">Delete</button>
</div>

3種類の異なるボタンスタイルで、3種類の異なる意図を示しています。

🚫 BAD

<div class="action-bar">
  <button class="btn btn--primary">Save</button>
  <button class="btn btn--primary">Cancel</button>
  <button class="btn btn--primary">Delete</button>
</div>

用途が大きく異なるにもかかわらず、すべてのボタンが同じ見た目になっています。

レビュー時のチェック項目：

  • 同じ機能を持つのにスタイルが異なる要素（一貫性がない）を指摘します
  • 異なる機能を持つのにスタイルが同じ要素（曖昧）を指摘します
  • 他の同種の要素と一致させるべき要素に、独自の単発スタイルが使われている場合は指摘します
共通領域の法則

定義：共通の境界（枠線、背景、コンテナー）内にある要素は、ひとまとまりとして認識されます。

重要なポイント：背景、枠線、カードなどの視覚的なコンテナーを使って、関連するコンテンツをグループ化します。これにより、近接しているだけの場合よりもグループ化が強化されます。

コードで確認するポイント：

  • <fieldset>、カード、パネル、または視認できる境界のあるセクションがあるか確認します
  • コンテナー領域の作成に background-color、border、border-radius が使われているか確認します
  • グループ化された項目が共通のコンテナー要素を共有しているか確認します

例：

✅ 良い例

<fieldset class="form__section">
  <legend>Shipping Address</legend>
  <input type="text" placeholder="Street">
  <input type="text" placeholder="City">
  <input type="text" placeholder="Zip">
</fieldset>

<fieldset class="form__section">
  <legend>Billing Address</legend>
  <input type="text" placeholder="Street">
  <input type="text" placeholder="City">
  <input type="text" placeholder="Zip">
</fieldset>

🚫 悪い例

<label>Shipping Street</label>
<input type="text">
<label>Shipping City</label>
<input type="text">
<label>Shipping Zip</label>
<input type="text">
<label>Billing Street</label>
<input type="text">
<label>Billing City</label>
<input type="text">
<label>Billing Zip</label>
<input type="text">

グループ化されていないフラットなフィールドのリストです。ユーザーは、配送情報がどこで終わり、請求情報がどこから始まるのかをすぐに把握できません。

レビュー時の指摘事項：

  • 視覚的なグループ化のない、長いフラットなフォームフィールドのリストを指摘します
  • コンテナーの境界がない、独立したコンテンツセクションを指摘します
  • <legend> のない <fieldset> の使用を指摘します（境界はありますが、ラベルがありません）
均一な連結性の法則

定義：線、色、枠、その他の形状によって視覚的につながっている要素は、つながりのない要素よりも関連性が高いと認識されます。

重要なポイント：線、共通の色、囲みなどの視覚的なコネクターを使って、要素間の関係を示します。

コードで確認するポイント：

  • ステップインジケーターに視覚的なコネクター（ステップ間の線）があるか確認します
  • 関連する項目を結び付ける、共通の背景色や枠線があるか確認します
  • タイムライン、パンくずリスト、ウィザードで、視覚的につながる要素が使われているか確認します

例：

✅ 良い例

.stepper__step {
  display: flex;
  align-items: center;
}

.stepper__connector {
  flex: 1;
  height: 2px;
  background-color: var(--op-color-border);
}

.stepper__step--completed .stepper__connector {
  background-color: var(--op-color-primary-base);
}

レビュー時の指摘事項：

  • ステップ間に視覚的なコネクターがない、複数ステップのウィザードを指摘します
  • 共通の視覚的な処理がない、関連する要素を指摘します
  • つなぐ線や矢印がない、パンくずリストやタイムラインのコンポーネントを指摘します
プレグナンツの法則（単純性の法則）

定義：人は、曖昧または複雑な画像を、可能な限り単純な形で解釈する傾向があります。

重要なポイント：レイアウトをすっきりとシンプルに保ちます。明確な視覚的階層と十分な余白を使い、不要な視覚的な複雑さを避けます。

コードで確認するポイント：

  • 過剰な枠線、影、装飾要素がないか確認します
  • 視覚的な重みが競合する要素が多すぎるレイアウトがないか確認します
  • コンテンツにゆとりを持たせるため、余白が効果的に使われているか確認します

例：

✅ 良い例

.card {
  background: var(--op-color-surface-base);
  border-radius: var(--op-radius-medium);
  padding: var(--op-space-large);
}

🚫 悪い例

.card {
  background: linear-gradient(135deg, #f5f5f5, #e0e0e0);
  border: 2px solid #ccc;
  border-radius: 12px;
  box-shadow: 0 4px 8px rgba(0, 0, 0, 0.1), 0 2px 4px rgba(0, 0, 0, 0.06);
  padding: 24px;
  outline: 1px solid rgba(255, 255, 255, 0.5);
}

過剰なスタイリングが注意を奪い合い、視覚的なノイズを増やしています。

レビュー時の指摘事項：

  • 2種類を超える装飾的な処理（影＋枠線＋グラデーション）が施された要素を指摘します
  • 主要なセクション間に余白がないレイアウトを指摘します
  • デザイントークンではなく、ハードコードされた視覚的な値を指摘します（optics-context スキルを参照）
フォン・レストルフ効果（孤立効果）

定義：似たものが複数ある場合、ほかと最も異なるものが最も記憶に残りやすくなります。

重要なポイント：最も重要な要素を視覚的に際立たせます。主要なアクションに注目を集めるため、単一のプライマリ CTA スタイルを使います。

コードで確認するポイント：

  • ビューまたはセクションごとに、主要なアクションボタンが1つだけあるか確認します
  • 最も重要な要素が視覚的に強調されているか（色、サイズ、ウェイト）確認します
  • セカンダリアクションに控えめなスタイルが使われているか確認します

例：

✅ 良い例

<div class="dialog__actions">
  <button class="btn btn--outline">Cancel</button>
  <button class="btn btn--primary">Confirm Purchase</button>
</div>

🚫 悪い例

<div class="dialog__actions">
  <button class="btn btn--primary">Cancel</button>
  <button class="btn btn--primary">Confirm Purchase</button>
</div>

どちらのアクションも視覚的な重みが同じため、ユーザーは主要なアクションをすぐに判断できません。

レビュー時の指摘事項：

  • 注目を奪い合う複数の btn--primary（または同等の要素）があるビューを指摘します
  • 周囲の要素に溶け込み、視覚的な区別がない CTA を指摘します
  • 視覚的に明確な焦点がないページを指摘します
系列位置効果

定義：ユーザーは、系列の最初と最後にある項目を最もよく記憶する傾向があります。

重要なポイント：リスト、ナビゲーション、コンテンツの並びでは、最も重要な項目を先頭と末尾に配置します。

コードで確認する点：

  • ナビゲーションの順序を確認します。重要な項目は先頭と末尾に配置します
  • リストやタブの順序を確認し、優先度に沿って配置されているか確認します
  • フッターやページ下部のコンテンツに、重要なアクションがあるか確認します

例：

✅ 良い例

<nav class="main-nav">
  <a href="/dashboard">Dashboard</a>     
  <a href="/projects">Projects</a>
  <a href="/team">Team</a>
  <a href="/reports">Reports</a>
  <a href="/settings">Settings</a>       
</nav>

レビュー時の指摘事項：

  • 最も重要度の低い項目が先頭にあるナビゲーションを指摘します
  • 重要な項目が戦略的に並べられていない長いリストを指摘します
  • 役立つアクションがなく、定型文しか含まれていないフッターを指摘します

行動とインタラクションに関する法則

これらの法則は、ユーザーがインターフェースをどのように操作するか、また何がユーザーの行動を促すかを扱います。

フィッツの法則

定義：ターゲットを選択するまでの時間は、ターゲットまでの距離とターゲットの大きさによって決まります。

重要なポイント：重要なインタラクティブ要素は、大きく、簡単に操作できるようにします。特にタッチデバイスでは、クリック／タップできるターゲットのサイズを大きくします。

コードで確認する点：

  • ボタンやリンクのサイズを確認します。タッチターゲットは最低でも44x44pxにします
  • インタラクティブ要素に十分なパディングがあるか確認します
  • 重要なアクションの配置を確認します。ユーザーの注意やカーソルがすでにある場所の近くに配置します
  • メディアクエリを使用して、モバイル向けにサイズが調整されているか確認します

例：

✅ 良い例

.btn {
  min-height: 44px;
  min-width: 44px;
  padding: var(--op-space-small) var(--op-space-medium);
}

.icon-btn {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-height: 44px;
  min-width: 44px;
}

🚫 悪い例

.action-link {
  font-size: 12px;
  padding: 2px 4px;
}

.icon-btn {
  width: 20px;
  height: 20px;
}

クリックターゲットが小さいと、タッチデバイスではタップしにくく、デスクトップでも正確にクリックするのが困難です。

レビュー時の指摘事項：

  • インタラクティブ要素が44x44px未満の場合は指摘します（特にタッチインターフェース）
  • パディングのないテキストリンクを指摘します（ターゲット領域をテキストサイズだけに頼っています）
  • ユーザーが注目すると予想される領域から離れた位置にある重要なアクションを指摘します
  • 小さすぎる、または手が届きにくい隅にある閉じる／閉じるボタンを指摘します
ドハティのしきい値

定義：コンピューターとユーザーが互いを待たずに済むペース（400ms未満）でやり取りすると、生産性が大幅に向上します。

重要なポイント：すべてのユーザーアクションに対して、すぐに視覚的なフィードバックを提供します。ローディング状態、楽観的更新、スケルトンスクリーンを使い、体感応答時間を400ms未満に保ちます。

コードで確認する点：

  • 非同期アクションにローディングインジケーター（スピナー、スケルトンスクリーン）があるか確認します
  • フォーム送信中のボタンにdisabled状態があるか確認します
  • 楽観的UIパターン（サーバーの応答前にUIを更新する）があるか確認します
  • 部分的なページ更新にTurbo Frame／Streamが使用されているか確認します

例：

✅ 良い例

<button type="submit" class="btn btn--primary"
        data-disable-with="Saving..."
        data-controller="submit-button">
  Save Changes
</button>


<div class="card card--skeleton">
  <div class="skeleton-line skeleton-line--title"></div>
  <div class="skeleton-line"></div>
  <div class="skeleton-line"></div>
</div>

🚫 悪い例

<button type="submit" class="btn btn--primary">Save Changes</button>

レビュー時の指摘事項：

  • data-disable-withまたは同等のローディング状態がないフォーム送信ボタンを指摘します
  • スケルトンスクリーンやスピナーのない非同期データ読み込みを指摘します
  • Turbo Frameによる部分更新のほうが速いのに、新しいページへ遷移するアクションを指摘します
  • 状態変化にトランジション／アニメーションがない場合は指摘します
目標勾配効果

定義：目標に近づくほど、目標を達成しようとする傾向が強まります。

重要なポイント：複数のステップがあるタスクでは進捗状況を表示します。ユーザーが完了に近づくにつれて、進捗を視覚的に明確にし、最後までやり遂げる意欲を高めます。

コードで確認する点：

  • 複数のステップがあるフォームに進捗インジケーターがあるか確認します
  • 完了率やステップ数（例：「5つ中3つ目のステップ」）があるか確認します
  • オンボーディングのフローに進捗状況のフィードバックがあるか確認します
  • 視覚的な進捗（プログレスバー、完了したステップのチェックマーク）があるか確認します

例：

✅ 良い例

<div class="stepper">
  <div class="stepper__step stepper__step--completed">
    <span class="stepper__icon">&#10003;</span>
    <span>Account</span>
  </div>
  <div class="stepper__connector stepper__connector--completed"></div>
  <div class="stepper__step stepper__step--active">
    <span class="stepper__icon">2</span>
    <span>Profile</span>
  </div>
  <div class="stepper__connector"></div>
  <div class="stepper__step">
    <span class="stepper__icon">3</span>
    <span>Preferences</span>
  </div>
</div>

🚫 悪い例

<h2>Profile Information</h2>
<form>
  
  <input type="text" placeholder="Name">
  <button type="submit">Next</button>
</form>

レビュー時の指摘事項：

  • 進捗インジケーターがない複数ステップのフォームやウィザードを指摘します
  • ステップ数やプログレスバーがないオンボーディングのフローを指摘します
  • ステップが明確に視覚化されていないチェックアウトのプロセスを指摘します
ヤコブの法則

定義：ユーザーは、ほとんどの時間をほかのサイトで過ごしています。すでに知っているほかのサイトと同じように動作するサイトを好みます。

重要なポイント：確立された UI の慣例に従います。ナビゲーション、フォーム、一般的な操作には標準的なパターンを使用します。新しい試みは慎重に行います。

コードで確認すること：

  • ナビゲーションがプラットフォームの慣例に従っているか確認します（トップバーまたはサイドバー、ロゴからホームへのリンク）
  • 標準的なフォームのパターンを確認します（入力欄の上にラベル、右下に送信ボタン）
  • リンクがリンクらしく、ボタンがボタンらしく見えるか確認します
  • 標準的なキーボード操作を確認します（Escape キーでモーダルを閉じる、Tab キーで移動する）

例：

✅ 良い例

<header class="header">
  <a href="/" class="header__logo">
    <img src="/logo.svg" alt="AppName">
  </a>
  <nav class="header__nav"></nav>
  <div class="header__actions">
    <a href="/account" class="header__avatar"></a>
  </div>
</header>

🚫 悪い例

<footer>
  <a href="/">
    <img src="/logo.svg" alt="AppName">
  </a>
  <nav></nav>
</footer>

主要なナビゲーションをフッターに配置すると、ユーザーの期待に反します。

レビュー時の確認事項：

  • キーボードで操作できないのに、ブラウザー標準のコントロールを再現しているカスタムウィジェット（カスタムの選択メニュー、カスタムのチェックボックス）を指摘します
  • ナビゲーション、検索、ユーザーアカウントへのリンクの配置が標準的でない場合は指摘します
  • 通常のテキストのように装飾されたリンクや、リンクのように装飾されたボタン（役割の混同）を指摘します
  • Escape キーで閉じられないモーダルを指摘します
美的ユーザビリティ効果

定義：ユーザーは、見た目の美しいデザインほど使いやすいと感じることがよくあります。

重要なポイント：ビジュアルの仕上げに力を入れます。適切にデザインされたインターフェースはユーザーの信頼を築き、小さな使いにくさへの許容度を高め、利用を促します。

コードで確認すること：

  • デザイントークン（色、余白、タイポグラフィ）が一貫して使用されているか確認します
  • 視覚的な配置と余白の一貫性を確認します
  • インターフェース全体に統一感のあるカラーパレットが使われているか確認します
  • マイクロインタラクション（ホバー状態、フォーカス状態、トランジション）の細部への配慮を確認します

例：

✅ 良い例

.btn {
  background-color: var(--op-color-primary-base);
  color: var(--op-color-primary-base-on);
  border-radius: var(--op-radius-medium);
  padding: var(--op-space-small) var(--op-space-medium);
  transition: background-color 150ms ease;
}

.btn:hover {
  background-color: var(--op-color-primary-plus-one);
}

.btn:focus-visible {
  outline: 2px solid var(--op-color-primary-base);
  outline-offset: 2px;
}

🚫 悪い例

.btn {
  background: blue;
  color: white;
  padding: 8px 12px;
}
/* No hover state, no focus state, no transitions */

操作状態がなく、色がハードコードされていると、仕上がりが粗く感じられ、品質の印象が損なわれます。

レビュー時の確認事項：

  • ホバー状態とフォーカス状態のないインタラクティブ要素を指摘します
  • 余白やタイポグラフィに一貫性がない場合（トークンとハードコードされた値の混在など）は指摘します
  • 状態の変化にトランジションがない場合は指摘します
  • デザイントークンではなく色がハードコードされている場合は指摘します（optics-context スキルを参照）
ピーク・エンドの法則

定義：人は、すべての瞬間の総和ではなく、最も感情が高まった瞬間（ピーク）と最後にどう感じたかをもとに、体験を大きく評価します。

重要なポイント：印象的なピークの瞬間と心地よい締めくくりを設計します。成功状態、確認メッセージ、完了時の演出は、体験全体の評価に大きく影響します。

コードで確認すること：

  • 成功ページや確認ページに、前向きなフィードバックがあるか確認します
  • 完了時の演出（チェックマーク、成功メッセージ、アニメーション）を確認します
  • エラー状態に、行き止まりではなく役立つ復旧手段があるか確認します
  • フローの最後のステップに満足感があるか確認します

例：

✅ 良い例

<div class="success-state">
  <div class="success-state__icon">&#10003;</div>
  <h2>Payment Successful!</h2>
  <p>Your order #1234 has been confirmed. You'll receive a confirmation email shortly.</p>
  <a href="/orders/1234" class="btn btn--primary">View Order</a>
</div>

🚫 悪い例

<div class="alert alert--success">
  <p>Done.</p>
</div>

複雑なフロー（チェックアウトなど）の後に、唐突で簡素な成功メッセージが表示されると、最後の印象が弱くなります。

レビュー時の確認事項：

  • 完了状態のメッセージがありきたり、またはそっけない場合（「完了」「成功」など）は指摘します
  • 次の手順や復旧方法が明確でないエラーページを指摘します
  • 成功ページや確認ページから自動的に移動させる設定を指摘します
  • 前向きな確認の瞬間がないまま終わるチェックアウトやオンボーディングのフローを指摘します
ポステルの法則（ロバストネス原則）

定義：受け入れるものには寛容に、送るものには厳格に対応します。

要点：幅広い形式のユーザー入力を受け入れ、小さなミスは許容します。厳格な検証エラーを出すのではなく、自動フォーマット、自動修正を行い、役立つ提案を提示します。

コードで確認すること：

  • 入力の検証を確認します。厳格なフォーマットのために有効な入力を拒否していませんか？
  • 電話番号、日付、クレジットカード番号などの自動フォーマットを確認します
  • エラーメッセージを確認します。役立つ内容で、具体的ですか？
  • 検索が柔軟に対応できることを確認します（タイプミスや部分一致への対応）

例：

✅ GOOD

<input type="tel" placeholder="Phone number"
       data-controller="phone-input"
       data-action="input->phone-input#format">

🚫 BAD

<input type="text" placeholder="XXX-XXX-XXXX" pattern="\d{3}-\d{3}-\d{4}">
<span class="error">Phone number must be in format XXX-XXX-XXXX</span>

フォーマットの違いを理由に、有効な電話番号を拒否しています。

レビュー時の指摘事項：

  • よくある別の形式を拒否する厳格な入力パターンを指摘します
  • 何を期待されているのか説明していない検証メッセージを指摘します
  • あいまい検索やオートコンプリートのない検索入力を指摘します
  • 日付ピッカーを使わず、特定の形式を要求する日付入力を指摘します
ツァイガルニク効果

定義：人は、完了したタスクよりも未完了または中断したタスクをよく覚えています。

要点：未完了のタスクに視覚的なインジケーターを使い、完了への意欲を高めます。プロフィールの完成度バー、未完了のフォームの下書き、保存された進捗など、開始済みでも完了していない項目を表示します。

コードで確認すること：

  • プロフィールやセットアップの完了を示すインジケーターを確認します
  • リスト表示に「下書き」または「進行中」の状態があるか確認します
  • 一部まで入力したフォームの進捗が保存されることを確認します
  • 「前回の続きから再開する」パターンを確認します

例：

✅ GOOD

<div class="profile-completion">
  <div class="progress-bar">
    <div class="progress-bar__fill" style="width: 60%"></div>
  </div>
  <p>Your profile is 60% complete. <a href="/profile/edit">Complete your profile</a></p>
</div>

🚫 BAD


<div class="profile-header">
  <h2>Welcome, Alex</h2>
</div>

プロフィールの完成を促す機会を逃しています。

レビュー時の指摘事項：

  • 部分的な進捗を保存しない複数ステップのフローを指摘します
  • 完了インジケーターのないオンボーディングフローを指摘します
  • 画面遷移時にデータが失われるフォーム（自動保存や下書き状態がないもの）を指摘します
  • 注意が必要なリスト項目に「未完了」または「下書き」バッジがない場合は指摘します

横断的な考慮事項

複数の法則が相互に補強し合うことがあります。コードをレビューする際は、同じ問題を複数の法則名で指摘するのではなく、関連する指摘をまとめてください。

法則のグループ化：近接性＋共通領域＋類似性＋一様な結合性

これら4つの法則は、どの要素同士がまとまりを成すかについて、ユーザーがどう認識するかに関係します。レイアウトをレビューする際は、次の点を確認します。

  • 空間的なグループ化（近接性）を確認します
  • 視覚的なコンテナ（共通領域）を確認します
  • 関連要素のスタイルが一貫しているか（類似性）を確認します
  • 視覚的なつながりを示す要素（一様な結合性）を確認します

レイアウトが4つすべてに違反している場合は、ひとつのグループ化の問題として報告し、修正に最も関連する法則を示してください。

複雑さに関する法則：ミラーの法則＋ヒックの法則＋テスラーの法則＋オッカムの剃刀＋パーキンソンの法則

これらの法則はすべて、インターフェースの複雑さをどう管理するかを扱います。

  • 項目が多すぎる → ミラーの法則
  • 選択肢が多すぎる → ヒックの法則
  • 複雑さをユーザーに押し付けている → テスラーの法則
  • 不要な複雑さ → オッカムの剃刀
  • フォームのスコープクリープ → パーキンソンの法則

フォームにフィールドが多く、各フィールドの選択肢も多すぎる場合は、それぞれの問題に最も大きく影響する法則を挙げてください。

フィードバックに関する法則：ドハティの閾値＋ピーク・エンドの法則＋目標勾配効果＋ツァイガルニク効果

これらの法則はすべて、フィードバックと進捗の認識に関係します。

  • アクションへの即時応答 → ドハティの閾値
  • 重要な場面の質 → ピーク・エンドの法則
  • 進捗の可視化 → 目標勾配効果
  • 未完了タスクの認識 → ツァイガルニク効果

複数ステップのフローでは4つすべてを確認しますが、指摘事項は法則名ごとではなく、該当するインタラクションの箇所ごとにまとめてください。

関連スキル
  • bem-structure：これらのUX法則を適用したコンポーネントを作成する際に、CSSクラスの命名規則に使用します。
  • optics-context：これらの法則の視覚的な側面を実装する際に、デザイントークン（色、間隔、タイポグラフィ）の使用に役立ちます。

コメント

Markdown 対応