mcpField
N
nielsen-usability-heuristics

nielsen-usability-heuristics

github.com/dembrandtデザイン・UI174997 回インストール1 週間前に更新
リポジトリ

nielsen-usability-heuristics について

Nielsen's 10 Usability Heuristicsは、インターフェースのユーザビリティを評価する設計・レビュー用スキルです。基本となる10原則を実践的な指針とチェックリストにまとめています。

主な機能

  1. 0110項目のユーザビリティ原則
  2. 02インターフェース設計の実践指針
  3. 03各原則に沿ったレビュー質問
  4. 04ユーザビリティ確認リスト

活用シーン

  1. 01既存インターフェースのレビュー
  2. 02設計時のユーザビリティ原則の適用
  3. 03エラー防止と復旧の確認
  4. 04一貫性とユーザー操作性の評価

インストール

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

$npx skills add https://github.com/dembrandt/dembrandt-skills --skill nielsen-usability-heuristics

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

詳細

Nielsen のユーザビリティに関する 10 のヒューリスティック

使いやすいインターフェースを評価・設計するための基本原則です。これらをレビュー用チェックリストとして、また設計の初期段階から制約として適用してください。事後監査のツールとしてだけ使うものではありません。


1. システム状態の可視性

適切なフィードバックを適切な時間内に提供し、ユーザーが状況を常に把握できるように設計する必要があります。

システムの現在の状態がわからなければ、ユーザーは適切な判断を下せません。明確でタイムリーなフィードバックによって、信頼が築かれます。

実践例:

  • 読み込み状態、進行状況インジケーター、完了確認を表示する
  • 複数のステップからなるプロセスのどの段階にいるかを示す
  • 状態の変化をすぐに反映する(楽観的 UI や読み込みスピナーなど)
  • 操作が受け付けられたかどうか、ユーザーに迷わせない

レビュー時の質問: ユーザーの操作後、結果は 1 秒以内に表示されますか?


2. システムと実世界の一致

ユーザーになじみのある言葉、表現、概念を使って設計してください。内部の専門用語やシステム用語ではなく、ユーザーの言葉で語る必要があります。

実世界の慣習と自然な対応関係に従い、インターフェースを直感的に使えるようにしてください。ユーザーが意味を読み替える必要がある設計は避けましょう。

実践例:

  • エンジニアリングチームの用語ではなく、対象ユーザーが使う用語を使う
  • アイコンには、実世界の物や広く定着したウェブの慣習に合ったものを使う
  • 空間的な比喩は、実世界での期待に合うものを使う(例:削除には「ゴミ箱」を使う)
  • 内部システムの概念(ID、エラーコード、プロセス名など)をエンドユーザーに見せない

レビュー時の質問: この製品を知らないユーザーでも、すべてのラベルや用語を理解できますか?


3. ユーザーのコントロールと自由

ユーザーは操作を誤ることがあります。望まない状態から、面倒な手順を踏まずに抜け出せる、明確な緊急出口が必要です。

簡単に取り消したり、抜け出したりできる手段があれば、ユーザーは安心して操作でき、閉じ込められたと感じずに済みます。

実践例:

  • 破壊的または取り消せない操作には、必ず取り消し機能を用意する
  • モーダルやダイアログには、わかりやすい閉じる/キャンセル操作を設ける
  • 複数のステップからなるフローには、前のステップに戻る方法を用意する
  • 削除、公開、送信などの破壊的な操作は、可能であれば取り消せるようにする。取り消せない場合は、明示的な確認を求める

レビュー時の質問: ユーザーは作業内容を失ったり、サポートに問い合わせたりせずに、どのような状態からでも抜け出せますか?


4. 一貫性と標準

異なる言葉、状況、操作が同じ意味なのか、ユーザーに迷わせてはいけません。プラットフォームや業界の慣習に従ってください。

ほかの製品で培われたユーザーの期待に応えることで、一貫性が認知負荷を軽減します。

実践例:

  • 製品全体を通じて、同じ操作には同じラベルを使う
  • プラットフォームの慣習に従う(例:モバイルでは左スワイプで削除、取り消しには Cmd+Z を使う)
  • デザインシステムのコンポーネントは、使われる場所を問わず、同じ見た目と動作にする
  • 標準的なウェブのパターンを別の名前で呼ばない(例:「パンくずリスト」を「パストレイル」と呼ばない)

レビュー時の質問: 同じ操作は、製品全体を通じて常に同じ見た目と動作になっていますか?


5. エラーの防止

適切なエラーメッセージは重要ですが、最善の設計は、そもそもエラーの発生を防ぎます。

エラーの防止では、意図しない操作(スリップ)と、設計意図の誤解による誤りの両方に対処します。

実践例:

  • 誤った入力ができないよう制約を設ける(例:必須項目が入力されるまで送信ボタンを無効にする)
  • 破壊的または取り消せない操作の前に確認を求める
  • 入力マスク、検証、適切なデフォルト値を使って、正しい入力を促す
  • 望ましい操作経路が明確になるようフォームを設計する

レビュー時の質問: 破壊的または取り消せない操作すべてに、確認手順または取り消し手段がありますか?


6. 想起ではなく認識

要素、操作、選択肢を見えるようにして、ユーザーの記憶への負担を最小限に抑えます。ユーザーが、インターフェースのある場所で得た情報を別の場所で思い出す必要がないようにします。

認識は想起よりも認知的な労力が少なくて済みます。操作の手がかりを見えるようにすることで、製品を使う際の負担を軽減できます。

実践例:

  • ユーザーにコマンドを覚えるよう求めるのではなく、関連する選択肢を適切な場面で表示します
  • 関連する場合は、以前に入力されたデータを表示します(例:既知のフィールドにあらかじめ入力しておく)
  • アイコンにはラベルを添えます。アイコンだけでは、多くのユーザーにとって意味が曖昧です
  • ナビゲーションは常に表示し、ジェスチャーやホバーで初めて現れるようにしません

レビューの質問: 再び訪れたユーザーは、前回の続きから始めるために何かを覚えておく必要がありますか?


7. 柔軟性と効率的な使用

初心者には見えないショートカットを使うことで、熟練ユーザーは操作を速められます。デザインはどちらにも対応する必要があります。

アクセラレーター、カスタマイズ、パーソナライズにより、初心者に複雑さを加えることなく、経験豊富なユーザーはより速く作業できます。

実践例:

  • 頻繁に行う操作にキーボードショートカットを用意します
  • 新規ユーザー向けのガイド付きフローと、熟練者向けの直接的な操作経路の両方に対応します
  • ユーザーが繰り返し使うビュー、フィルター、レイアウトをカスタマイズできるようにします
  • 使用パターンに基づいて、頻繁に使われる操作を目立つ位置に表示します

レビューの質問: パワーユーザーは、初めて使うユーザーよりも、最も頻繁に行うタスクを大幅に速く完了できますか?


8. 美しくミニマルなデザイン

インターフェースには、無関係な情報や、めったに必要とされない情報を含めないようにします。情報が増えるたびに、関連する情報との競合が生じ、その相対的な視認性が低下します。

ユーザーの主要な目標を支える要点に、コンテンツとビジュアルデザインを集中させます。少ないほどよいのは、減らす対象が適切な場合に限ります。

実践例:

  • 意味を持たない装飾的な要素を取り除きます
  • 二次的、三次的な操作は、主要な操作よりも目立たないようにします
  • すべての機能を同時に表示するのは避けます。段階的開示により、必要な場合にのみ複雑さを明らかにします
  • 空の状態、エラー状態、読み込み状態にも、コンテンツが表示されている状態と同じだけデザイン上の配慮をします

レビューの質問: 画面上のすべての要素には存在する価値がありますか。それとも「念のため」に置かれているだけのものがありますか?


9. エラーの認識、診断、回復をユーザーに支援する

エラーメッセージは平易な言葉で表現し、問題を正確に示し、解決策を建設的に提案する必要があります。

エラーメッセージは UX の表現の一つです。他の UI 文言と同じだけ配慮する必要があります。

実践例:

  • エンドユーザーに未加工のエラーコードやスタックトレースを表示しません
  • 何が問題だったのかを、平易な言葉で明確に伝えます
  • 何が失敗したかだけでなく、次に何をすべきかをユーザーに伝えます
  • 適切な視覚表現を使います。エラーには赤を使いますが、警告や情報には赤を使いません
  • インラインの入力検証エラーは、問題のあるフィールドの近くに表示します

レビューの質問: すべてのエラーメッセージは、何が起きたのか、なぜ起きたのか、次に何をすべきかをユーザーに伝えていますか?


10. ヘルプとドキュメント

システムに追加の説明が必要ないのが理想です。ただし、ユーザーがタスクを完了するのを支援するために、ドキュメントの提供が必要になる場合があります。

ヘルプは状況に応じたもので、検索可能かつ実際に役立つものにします。フッターの奥に埋もれた最後の手段にしてはいけません。

実践例:

  • ツールチップより自己説明的な UI を優先し、ドキュメントよりツールチップを優先します
  • インラインヘルプ(プレースホルダーテキスト、補助テキスト、ツールチップ)は、必要な場所に表示します
  • ドキュメントは機能中心の説明(「設定パネルについて」)ではなく、タスク中心の内容(「……するにはどうすればよいですか?」)にします
  • 空の状態は、単に何も表示しないのではなく、状況に応じたヘルプを提供する機会です

レビューの質問: 困っているユーザーは、現在の画面を離れずにヘルプを見つけられますか?


ヒューリスティック評価チェックリスト

#ヒューリスティックチェック項目
1システムの状態すべての操作で1秒以内に視覚的なフィードバックが得られる
2現実世界の言葉専門用語を使わず、ユーザーが使う語彙に合わせる
3ユーザーの主導権元に戻す手段があり、終了方法が常に表示されている
4一貫性同じ操作には、どこでも同じラベルと動作を適用する
5エラーの防止元に戻せない操作には、確認または取り消し手段を用意する
6想起より認識選択肢は状況に応じて表示し、隠しコマンドをなくす
7柔軟性熟練ユーザーが頻繁に行う操作をすばやく実行できる手段を用意する
8ミニマリストデザインすべての要素に存在する価値がある
9エラーからの回復エラーメッセージは平易かつ具体的で、対処方法が分かる
10ヘルプとドキュメント必要な場面で、状況に応じたヘルプを利用できる

コメント