mcpField
U
usability

usability

github.com/ryanthedevデザイン・UI32160 回インストール17 週間前に更新
リポジトリ

usability について

インターフェースの操作性を評価し、確立されたユーザビリティ原則に基づいて UI パターンを選ぶデザインスキルです。根拠を示すヒューリスティック評価と、状況に応じたパターン提案をデザインチーム向けに行います。

主な機能

  1. 01重大度を付けたヒューリスティック評価
  2. 02ユーザビリティの根拠を示す提案
  3. 03原則に基づく UI パターン選定
  4. 04認知負荷とアクセシビリティの確認

活用シーン

  1. 01インターフェースの操作上の問題を確認
  2. 02フォームやナビゲーションのパターン選定
  3. 03アクセシビリティに関わる使いやすさの評価
  4. 04ビジュアル調整前の修正優先度付け

インストール

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

$npx skills add https://github.com/ryanthedev/design-for-ai --skill usability

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

evals.json
references/
ui-patterns.md
usability-principles.md

詳細

ユーザーがインターフェースを操作できるかを判定します。見た目の良さを評価するのではありません。ここでの役割は二層構造のエンジンです。原則(ゲシュタルト、UXの法則、Nielsen/Shneidermanのヒューリスティクス、Norman、認知負荷、アクセシビリティ)は「なぜ」を、UIパターンのファミリーは「何を」を示し、原則に基づいてパターンを選択します。すべての推奨事項には、参照元となる法則、ヒューリスティック、または著者を明記します。

適用場面

操作性が懸念される場合に、このスキルを使います。「使いやすいか」「使いにくい」「ユーザーがここで行き詰まる/混乱する/離脱する」、ヒューリスティック評価/ユーザビリティ評価、UXの法則(Fitts、Hick、Miller/Cowan、Jakobなど)の適用、アフォーダンス/シグニファイア/フィードバック/認知負荷についての検討、UIパターンのファミリー(ナビゲーション、フォーム、検索/フィルター、データ表示、フィードバック、アクション、開示、オンボーディング)の選択、アクセシビリティにおけるユーザビリティ(WCAG POUR、インクルーシブデザイン)が該当します。中核の audit モードでは、ヒューリスティック評価がここに割り当てられます。

見た目に関する評価ではありません(中核の design/audit)。マイクロコピーそのもの(content-design)、時間軸/IA/ファネルに沿った経路(journey)、説得の仕組み(behavioral)、真実に忠実なデータの符号化(data-viz)も対象外です。

ルール

あらゆるユーザビリティ判断に適用する基本ルールです。手順の中で曖昧にならないよう、分けて記載しています。

  • 原則を引用します。 すべての推奨事項に、該当する場合は提唱者/発表年を添えて出典を明記します。「Fittsの法則(1954)」「Nielsenの第5原則:エラー防止(1994)」「Norman:アフォーダンスよりシグニファイア(1988/2013)」「レイヤーケーキ型スキャニング(NN/g)」のように記載します。出典のない意見は認められません。引用可能な基本資料は references/usability-principles.md にあります。
  • 法則は傾向であり、物理法則ではありません。 UXの法則が成り立つのは「条件のもとで」であり、推奨事項の根拠として引用するもので、コンプライアンスのチェックリストとして使うものではありません(フレームワークを成果物とするのは、コンプライアンスを装う行為です)。法則が適用されない場面を把握することも、誠実な引用の一部です。たとえば、Millerの7±2はワーキングメモリに関する法則であり、画面に見えているメニュー項目には当てはまりません。
  • 仕上げより先にユーザビリティを改善します。 美的ユーザビリティ効果(Kurosu & Kashimura、1995)により、見た目の美しいUIは主観的な評価を引き上げ、テストで実際の欠陥を覆い隠すことがあります。順序が重要です。まず操作性の欠陥を解消し、その後、ビジュアルの仕上げ(中核の design)で完成度を高めます。
  • ヒューリスティック評価はユーザーテストを補完するものであり、代替ではありません。 ヒューリスティック評価で見つかるのは「起こりそうな」問題です(評価者効果、評価者間の信頼性の低さ、重大度評価の不確かさ)。実環境での発生頻度はわかりません。実際のテストと組み合わせてください。アクセシビリティについては、支援技術のユーザーとテストしてください(自動ツールで検出できるのは約35%です)。
  • 発想を広げます。 法則に基づいてパターンを選択し、組み合わせ、提案します。項目をチェックするだけにとどまってはいけません。原則は選択肢を提示するための判断基準であり、通過しなければならない関門ではありません。
  • 引用は下位レイヤーに限ります。 ユーザビリティはデザインレイヤーの最も内側にある要素です。他の柱(journey、behavioral、deceptive-patterns)はユーザビリティの法則を引用しますが、ユーザビリティがそれらを上位に向けて引用することはありません。柱をまたぐ循環参照は禁止です。

手順

このエンジンには2つのモードがあります。ユーザーのニーズに応じて選択してください。

A. ヒューリスティック評価(audit メソッド)

既存のインターフェースの評価を求められた場合、または操作性のために中核の audit モードから割り当てられた場合:

  1. references/usability-principles.md を読みます。
  2. インターフェースに対してNielsenの10ヒューリスティクス(1994)を確認します。違反ごとに、該当するヒューリスティック、その根底にある原則、修正方法を示します。
  3. 0~4の重大度スケール(0=問題なし……4=ユーザビリティ上の大惨事)で各指摘を評価し、発生頻度 × 影響度 × 継続性を考慮します。
  4. ヒューリスティックでは見つからない問題がないか、知覚と認知に関する法則(ゲシュタルトの群化、Hick、Miller/Cowan、想起より再認)を照合します。
  5. 重大度の高い順に、指摘事項を表で出力します。列は Severity | Heuristic / law | Problem | Fix とします。補完的な評価であることを明記してください。ここで見つかるのは起こりそうな問題であり、実際の発生頻度ではありません。
B. パターンの選択(なぜ → どのエンジン)

UI パターンを選択または修正するときは、次の手順に従います。

  1. references/ui-patterns.md を読み、パターンの系統カタログと対応表を確認します。
  2. 該当する制約(画面サイズ、入力方式、タスクへの慣れ、頻度、比較の必要性)を明確にします。
  3. 対応表を使って、原則からパターンを選択します。例:Fitts → スマートフォンでは上部ナビゲーションより下部タブバー、Hick → 小さな画面ではメガメニューよりグループ化されたメニュー/段階的なメニュー、Miller/Cowan → 20フィールドのページよりウィザード/フィールドのグループ化、Jakob → ユーティリティサイトでは無限スクロールよりページネーション。
  4. パターンを推奨し、その選択根拠となった法則を挙げ、慣習を破るべき場合(新しいカテゴリ、有害なレガシー慣習、正当なブランド差別化)を記します。

参照資料

参照ファイル読み込むタイミング
references/usability-principles.mdレイヤー A — なぜのエンジン:ゲシュタルト、UX の法則、Nielsen の 10 原則 + Shneiderman の 8 原則 + ヒューリスティック評価手法、Norman、認知負荷、アクセシビリティ、重要な注意事項。ほかの柱から参照するための、安定した引用可能な資料です。
references/ui-patterns.mdレイヤー B — 8 つの UI パターン系統カタログ + 対応表(原則 → パターン)+ パターンに関する注意事項。

コメント