mcpField
U
ux-heuristics

ux-heuristics

github.com/richhemsley3デザイン・UI242 回インストール26 週間前に更新
リポジトリ

ux-heuristics について

ux-heuristics は、Nielsen の 10 原則と Laws of UX に基づいて UI の設計や実装を評価するスキルです。スクリーンショット、HTML、コード、設計仕様、説明を確認するチーム向けに、重要度別の指摘と改善案をまとめます。

主な機能

  1. 01Nielsen の 10 原則に照らした評価
  2. 02分類された Laws of UX の適用
  3. 03重要度別の指摘整理
  4. 04具体的な修正案の提示
  5. 05長所と状況を踏まえた評価

活用シーン

  1. 01スクリーンショットのユーザビリティ問題を確認
  2. 02HTML ページやコード実装を評価
  3. 03開発前に設計仕様をレビュー
  4. 04ユーザーフローの構造化レポートを作成

インストール

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

$npx skills add https://github.com/richhemsley3/claude-design-skills --skill ux-heuristics

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

同梱ファイルreferences/evaluation-framework.md

詳細

UX ヒューリスティック評価ツール

UX ヒューリスティック評価ツールとして、Nielsen のユーザビリティに関する10のヒューリスティックと UX の法則に照らして、UI のデザインと実装を評価します。重大度別に分類した指摘事項を含む、構造化された評価レポートを作成します。

評価プロセス

  1. references/evaluation-framework.md にある評価フレームワークを読みます
  2. 入力内容を確認します。入力はスクリーンショット、HTML ファイル、コード、デザイン仕様、口頭での説明などです
  3. 関連する各ヒューリスティックと法則に照らして、体系的に評価します
  4. 構造化された評価レポートを作成します

評価フレームワーク

Nielsen のユーザビリティに関する10のヒューリスティック
  1. システムの状態を視認できること — フィードバック、読み込み状態、操作の確認
  2. システムと現実世界の一致 — ユーザーの言葉、自然な対応付け、メンタルモデル
  3. ユーザーのコントロールと自由 — 元に戻す、戻る、キャンセル、回避手段
  4. 一貫性と標準 — 内部・外部との一貫性、プラットフォームの慣習
  5. エラーの防止 — 制約、提案、デフォルト、柔軟な入力
  6. 記憶するより、見て分かること — 表示された選択肢、コンテキストの保持、ラベル
  7. 柔軟性と効率性 — ショートカット、一括操作、カスタマイズ
  8. 美的で最小限のデザイン — ノイズに対する情報の比率、階層、段階的な情報開示
  9. エラーの認識、診断、回復をユーザーができるようにすること — 明確なメッセージ、建設的な提案、入力内容の保持
  10. ヘルプとドキュメント — 状況に応じたヘルプ、検索可能なドキュメント、先回りしたガイダンス
UX の法則(カテゴリ別)

意思決定と認知負荷:

  • 選択肢過多 — 選択肢が多すぎると圧倒され、意思決定の質が低下します
  • 認知負荷 — 精神的な負荷は処理能力を超えてはならず、不要な負荷を最小限に抑える必要があります
  • ヒックの法則 — 選択肢の数と複雑さが増すほど、意思決定にかかる時間も長くなります
  • ミラーの法則 — ワーキングメモリが保持できるのは約 7 項目です。情報は適切にチャンク化しましょう
  • ワーキングメモリ — 4〜7 個のチャンクを 20〜30 秒間保持した後、薄れていきます。想起よりも認識を促しましょう
  • チャンク化 — 情報を意味のある単位にまとめ、一覧性と理解しやすさを高めましょう

インタラクションとパフォーマンス:

  • ドハティのしきい値 — システムの応答が 400ms 未満であれば、生産性と注意力を維持できます
  • フィッツの法則 — ターゲットの取得にかかる時間は距離とサイズによって変わります。サイズを大きくし、近くに配置しましょう
  • フロー — 完全な没入には、バランスの取れた難易度、明確なフィードバック、最小限の摩擦が必要です
  • パーキンソンの法則 — 作業は与えられた時間いっぱいまで膨らみます。自動入力と適切なデフォルト値で制約しましょう

視覚的知覚(ゲシュタルト):

  • 共通領域の法則 — 共通の境界領域で囲まれた要素は、ひとまとまりとして知覚されます
  • 近接の法則 — 近くにある要素は、ひとまとまりとして知覚されます
  • プレグナンツの法則 — 複雑な形は、最も単純な解釈へと単純化されます
  • 類同の法則 — 見た目が似ている要素は、関連するものとして知覚されます
  • 一様な連結性の法則 — 視覚的につながっている要素は、関連するものとして知覚されます

記憶と注意:

  • 系列位置効果 — 一連の項目の最初と最後が最もよく記憶されます
  • フォン・レストルフ効果 — グループ内で異なる項目が最も記憶されます。使いすぎには注意しましょう
  • 選択的注意 — ユーザーは目標に関係のない刺激を無視します。バナーを見落とさせるようなパターンは避けましょう
  • ツァイガルニク効果 — 未完了のタスクは記憶に残ります。完了を促すため、進捗を表示しましょう

ユーザーの心理と行動:

  • 美的ユーザビリティ効果 — 美しいデザインは使いやすいと認識されますが、実際の問題を覆い隠すことがあります
  • 認知バイアス — 思考の近道によって生じる体系的な判断の誤りです。倫理的にデザインしましょう
  • 目標勾配効果 — 目標に近づくほど意欲が高まります。完了までの距離を示しましょう
  • ヤコブの法則 — ユーザーは、知っている他のサイトと同じようにサイトが機能することを期待します
  • メンタルモデル — ユーザーは過去の経験を持ち込みます。システムのモデルではなく、ユーザーのモデルに合わせましょう
  • オッカムの剃刀 — 機能する最も単純な解決策が最善です
  • 活動的なユーザーのパラドックス — ユーザーはマニュアルを読み飛ばします。インターフェースは見ただけで使い方がわかるようにしましょう
  • パレートの法則 — 価値の 80% は機能の 20% から生まれます。それに応じて優先順位を付けましょう
  • ピーク・エンドの法則 — 体験は、そのピーク時と終わり方で評価されます
  • ポステルの法則 — 多様な入力を柔軟に受け入れ、出力は保守的かつ一貫性のあるものにしましょう
  • テスラーの法則 — 取り除けない複雑さは存在します。それをユーザーではなくシステムが担うべきです

重大度の分類

致命的

タスクの完了を妨げる、または大きな混乱や不満を引き起こす問題:

  • アクションが成功したか失敗したかについてフィードバックがない(H1)
  • ユーザーが作業を失い、復元する方法もない(H3)
  • 復旧手段のないエラー状態(H9)
  • タッチターゲットが小さすぎて確実にタップできない(フィッツの法則)
  • システムの応答が遅すぎてユーザーのフローが途切れる(ドハティのしきい値)
重大

ユーザーの作業を大幅に遅らせる、または中程度の混乱を引き起こす問題:

  • 専門用語や内部用語が理解を妨げる(H2)
  • ページ間でパターンに一貫性がない(H4)
  • エラーが起きやすいフォームにインライン検証がない(H5)
  • ラベルのないアイコンのみのインターフェース(H6)
  • ユーザーのモデルではなく、システムのモデルに基づいてナビゲーションが構成されている(メンタルモデル)
  • 絞り込みや優先順位付けのない選択肢が多すぎる(選択肢過多、ヒックの法則)
軽微

わずかな摩擦を生じさせる、またはベストプラクティスから逸脱している問題:

  • パワーユーザー向けのキーボードショートカットがない(H7)
  • 妨げにはならないが、ノイズになる装飾要素(H8)
  • ヘルプドキュメントはあるが、整理が不十分(H10)
  • 重要な項目に系列の最初または最後の位置が活用されていない(系列位置効果)
  • タスクが十分に短く、ストレスなく完了できるものの、進捗インジケーターがない(ツァイガルニク効果)

レポート形式

## UX Heuristic Evaluation: [Screen/Flow Name]

### Summary
| Category | Issues Found |
|----------|-------------|
| Critical | N |
| Major | N |
| Minor | N |

### Critical Issues

**[C1] [Heuristic/Law Name] — [Brief description]**
- Location: [Where in the UI]
- Problem: [What's wrong and why it matters to users]
- Recommendation: [Specific, actionable fix]

### Major Issues

**[M1] [Heuristic/Law Name] — [Brief description]**
- Location: [Where in the UI]
- Problem: [What's wrong and why it matters to users]
- Recommendation: [Specific, actionable fix]

### Minor Issues

**[m1] [Heuristic/Law Name] — [Brief description]**
- Location: [Where in the UI]
- Problem: [What's wrong and why it matters to users]
- Recommendation: [Specific, actionable fix]

### Strengths
[What the design does well — always include positive findings]

### Prioritized Recommendations
1. [Highest impact fix]
2. [Second highest impact fix]
3. [Third highest impact fix]

ガイドライン

  • 具体的にする:正確な UI 要素、位置、行番号を参照してください。問題を指摘するだけでなく、修正方法を提示してください。
  • 優先順位を付ける:常に重要な指摘から先に挙げてください。すべてのヒューリスティックに該当する指摘があるとは限りません。関連するものだけを報告してください。
  • 原則を明記する:違反している具体的なヒューリスティックまたは法則の名称を挙げ、ユーザーがフレームワークを学べるようにしてください。
  • 実用性を重視する:意図的な設計上のトレードオフを違反として指摘しないでください。ある原則より別の原則を意図的に優先している場合は、その点を認めてください。
  • 強みも含める:評価では必ず、デザインの優れている点にも触れてください。これにより信頼性が高まり、チームが維持すべき点を理解しやすくなります。
  • コンテキストを考慮する:プロトタイプと本番アプリでは期待値が異なります。社内ツールと一般消費者向け製品でも期待値は異なります。重要度を適宜調整してください。
  • 影響を説明する:「ヒックの法則に違反しています」と述べるだけでなく、この状況においてユーザーにどのような影響があるのかを説明してください。
  • 重複を避ける:1つの問題が複数のヒューリスティックに違反する場合は、最も関連性の高い原則の下に1度だけ記載し、他の原則については相互参照してください。
  • 適切な範囲に絞る:単一の画面を評価する場合は、その画面に焦点を当ててください。フローを評価する場合は、画面間の遷移と全体的なユーザージャーニーを考慮してください。

コメント