ux-usability-foundations

UX ユーザビリティの基礎

目的

エージェントが、理解しやすく、使いやすく、間違いを許容し、ユーザーの期待に沿ったインターフェースを作れるよう支援します。ユーザビリティは表面的な装飾ではなく、プロダクトの振る舞いとして捉えます。エージェントは、不明瞭または脆弱な UI を、ユーザーが「これは何か」「ここで何ができるか」「今どこにいるか」「何が起きたか」「どうすれば元に戻せるか」「労力をかける価値はあるか」にすばやく答えられるインターフェースに変える必要があります。

このスキルを使う場面

ユーザーから、UI、フロー、フォーム、アプリ画面、ウェブサイト、ダッシュボード、オンボーディング、設定ページ、チェックアウト、ナビゲーションモデル、状態の振る舞い、コンポーネントの操作性について、ユーザビリティの観点から批評、再設計、作成、仕様策定を依頼された場合に、このスキルを使います。アフォーダンスやシグニファイア、フィードバック、制約、エラー、空・読み込み中・成功の各状態、想起より認識を促す設計、タスクの明確さ、フロントエンドの振る舞いにも使います。

このスキルを使わない場面

ユーザーの理解、操作、復旧に直接影響しない限り、詳細なリサーチ業務、ブランドスタイリングシステム、ビジュアルの仕上げ、タイポグラフィの技法、フロントエンドアーキテクチャ、説得や成長施策を主な目的とする場合には、このスキルを主軸として使わないでください。

基本原則

1. 画面ではなく、目標から始める。 コントロールやレイアウトを変更する前に、ユーザーの目標、タスク、状況、想定される知識を特定します。要件では、ウィジェットより先にニーズを記述します。
2. 次の操作を明確にする。 ひと目でわかるインターフェースを優先します。タスクが本質的に目新しい、または複雑な場合は、構造、ラベル、例、フィードバックによって、説明がなくても使い方がわかるようにします。
3. 何ができるかを示す。 インタラクティブな要素は、操作できるように見せます。読み取り専用の要素は、編集可能に見せてはいけません。隠れたジェスチャーには、目に見える代替手段を用意します。
4. ユーザーのメンタルモデルに合わせる。 ユーザーが理解できる概念、名称、順序を使います。ユーザーが必要としない限り、データベースのテーブル、ファイルパス、内部 ID、恣意的なシステム状態を表に出しません。
5. 想起より認識を重視する。 必要な選択肢、コンテキスト、例、状態を表示したままにするか、簡単に確認できるようにします。
6. 作業を減らし、不要な作業をなくす。 ユーザーの目標ではなく、システムの都合に役立つ作業を取り除きます。たとえば、再入力、データの移し替え、コントロール探し、明らかな既定値の設定、推測できる質問への回答です。
7. ユーザーに負担をかけずに選択を導く。 段階的な情報開示、適切な既定値、グループ化、優先順位付けを活用します。
8. 即時かつ有益なフィードバックを返す。 重要な操作にはすべて、システムが操作を受け付けたか、何が変わったか、待つ必要があるか、次に何ができるかを伝える応答を用意します。
9. エラーを説明する前に防ぐ。 制約、安全な既定値、プレビュー、柔軟な入力、インライン検証、取り消しを可能な範囲で活用します。
10. ユーザーではなく、設計に責任を求める。 エラーは、期待との不一致や、想定されていない例外ケースを明らかにします。作業内容を保護し、復旧方法を案内します。
11. プラットフォームと慣習を尊重する。 適合する場合は、使い慣れたパターンを使います。慣習を破るのは、ユーザーの目標に明確な利点があり、新しい振る舞いを見つけて復旧する方法も用意できる場合に限ります。
12. アクセシビリティは、負荷の高い状況でのユーザビリティです。 多様な能力、デバイス、リテラシー、ストレス、環境において、知覚しやすく、操作しやすく、シンプルで、間違いを許容する設計にします。

各原則を再利用可能なカードとしてまとめたものについては、references/principle-cards.md を参照してください。

既定の推奨事項

プロダクトの目標

まず、二次的なビジネス上の要望よりも、主要なユーザータスクの最適化を優先します。法的要件、安全性、不正防止、プライバシー、または事業上重要な要件がある場合にのみ、優先順位を変更します。「どの要件によって主要なタスクを中断または制限する必要があるか。それを隠したり遅らせたりすると、どのような影響があるか」と問いかけます。

対象ユーザー

平均的な分野知識を持ち、記憶が不完全で、意欲はあるものの気が散りやすいユーザーを想定します。安定した環境でプロダクトを頻繁に使う、訓練を受けた熟練オペレーターを対象とする場合は、想定を変更します。「主な対象は、初めて使う、または利用頻度の低いユーザーか、頻繁に使う中級者か、訓練を受けた熟練者か」と問いかけます。

プラットフォームと入力

プラットフォームの慣習に従い、関連する場合はポインター、タッチ、キーボード、支援技術に対応することをデフォルトとします。プラットフォームや入力の制約が不明な場合は、質問してください。

情報密度

認識と意思決定に十分なコンテキストを提供しつつ、使用頻度の低い高度なコントロールは、わかりやすい入口の背後に隠すことをデフォルトとします。比較、モニタリング、エキスパート向けのワークフローでは、この方針を変更してください。次のように尋ねてください。「ユーザーには、モニタリングや比較のための概要重視の情報密度が必要ですか。それとも、完了に向けたステップごとの集中が必要ですか？」

ナビゲーション

現在の場所、対象のオブジェクトや状態、主要な領域へのアクセス、戻るまたは次に進むためのわかりやすい経路を提供することをデフォルトとします。意図的なガイド付きフローの場合に限り、この方針を変更してください。次のように尋ねてください。「ユーザーが自由に移動できるようにしますか。それとも、このフローでは意図的にナビゲーションを制限しますか？」

ラベルと言葉遣い

ユーザーが使う語彙に基づいた、平易でタスク指向のラベルをデフォルトとします。社内用語、ひねりのある表現、法律用語、専門用語を使う場合は、事前に確認してください。

フォーム

常に表示されるラベル、適切な入力タイプ、事前に提示される制約、役立つ場面でのインライン検証、データの保持、明確な主操作をデフォルトとします。専門家向けの情報密度や速度を、初回利用時のわかりやすさより優先する可能性がある場合に限り、質問してください。

エラー処理

まずエラーの発生を防ぎ、エラーが発生した場合は、何が起きたのか、なぜ重要なのか、作業内容を失わずにどう修正するかを説明することをデフォルトとします。エラーの詳細が機密、規制対象、またはセキュリティに関わる場合は、質問してください。

破壊的な操作

最終確認の段階までは、破壊的な操作を視覚的に目立たないものにすることをデフォルトとします。元に戻せる操作には取り消しを優先し、取り消せない操作、コストがかかる操作、法律や安全に関わる操作には確認を使用してください。取り消し可能かどうか、また想定される被害について質問してください。

フィードバックとステータス

操作を受け付けたことを即座に伝え、遅延時には進捗を示し、完了を可視化し、長時間かかる操作や重大な操作では状態を保持することをデフォルトとします。どの状態変化でユーザーに通知すべきか質問してください。

アクセシビリティ

WCAG を意識した基本事項をデフォルトとします。意味的に適切なコントロール、キーボード操作、フォーカスの可視化、プログラムによるラベル付け、十分なコントラスト、色だけに依存しない意味の伝達、読みやすい文言、スクリーンリーダーに適した状態更新を含みます。基本事項を変更してはいけません。

必須の質問

ベストプラクティスに関する定型的な質問はしないでください。回答によって推奨内容が変わる場合に限り、焦点を絞った質問を1つしてください。

• 主なユーザーやタスクが不明な場合。
• 操作が安全、金銭、法律、プライバシー、医療、または取り消し不能な結果に関わる場合。
• 初心者と専門家で異なる動作が必要な場合。
• プラットフォームや入力の制約が不明な場合。
• 必須の用語やコンプライアンス文言が適用される可能性がある場合。
• ユーザーが標準的でない、隠された、または人を誘導するパターンを求めている場合。
• 情報密度とわかりやすさ、またはガイド付きフローと自由なナビゲーションの間に実質的なトレードオフがある場合。

次の形式を使用してください。

question({
  question: "What is the primary task this interface must help users complete?",
  recommended_default: "Optimize for the most common successful task first, then make secondary actions available but visually quieter.",
  options: [
    "Complete one focused task",
    "Compare or monitor multiple items",
    "Explore and choose among options",
    "Other / custom"
  ]
})

質問ツールで使用できるプロンプトの全一覧については、references/decision-prompts.md を使用してください。

既存 UI を批評する際のワークフロー

次の順序で確認してください。

1. ユーザーの目標とタスクへの適合性。
2. 一目で理解できるか。
3. 位置の把握：現在の場所、対象のオブジェクトや状態、次に進む経路や戻る経路。
4. 操作の見つけやすさ。
5. 選択肢の質と優先順位。
6. ラベルと言葉遣い。
7. フィードバックとステータス。
8. エラーの防止と復旧。
9. 記憶への負担と、認識による負担の比較。
10. アクセシビリティと入力方法の対応範囲。
11. フロントエンドでの実現可能性とエッジケース。
12. タスクへの影響、頻度、深刻度、修正工数に基づく優先順位付け。

批評は、影響の大きいユーザビリティ上の問題、すぐに実施できる改善、動作や仕様の詳細、アクセシビリティに関する注意点、リスクやトレードオフとして報告してください。

インターフェースを作成または改善するワークフロー

1. ユーザー、目標、成功条件、リスクを明確にします。
2. 役に立つ最もシンプルなフローを選びます。
3. ユーザーの概念と用語を整理します。
4. 画面上の構造とアクションの優先順位を作ります。
5. タスク上の理由から独自の動作が必要な場合を除き、標準的なパターンを選びます。
6. デフォルト、ホバー、フォーカス、アクティブ、読み込み中、成功、空、入力検証、エラー、オフライン、無効、権限の各状態を設計します。
7. 制約、入力検証、復旧手段を追加します。
8. 初回利用と繰り返し利用の両方をサポートします。
9. アクセシビリティを検証します。
10. タスクの進行、認知負荷、期待、リスクの観点から判断を説明します。

判断の枠組み

次の点を自問してください。

1. 問題は理解、選択、操作、フィードバック、ナビゲーション、復旧のどれに関するものですか？
2. 説明するのではなく、設計によって問題を防げますか？
3. 想起ではなく、認識を使えるインターフェースにできますか？
4. 新たな学習を必要とせず、標準的なパターンで解決できますか？
5. どの要素が最優先、二次、三次、または危険なものですか？
6. ユーザーに必要なのは、より多くの情報、より少ない選択肢、より適切な順序のどれですか？
7. 状態の変化にユーザーは気づきますか？
8. ユーザーが注意散漫なとき、急いでいるとき、タッチ操作やキーボードを使うとき、支援技術を使うとき、またはエラーから復旧するとき、何が起こりますか？
9. 取り消し可能な操作、コストの高い操作、取り消し不能な操作は何ですか？
10. これはユーザーのタスクに役立っていますか、それともシステムの都合に役立っていますか？

実践的なルール

明確さと一覧性

• 各画面の目的が、見出し、構造、主なアクションから分かるようにします。
• 「送信」のようなボタンではなく、「請求書を送信」「変更を保存」「予約する」のような具体的なボタンにします。
• ホバーに頼らず、クリック／タップできる領域がコントロールに見えるようにします。
• 見出し、グループ化、余白、リストを使い、ユーザーが内容をざっと確認できるようにします。
• タスクの妨げになる文言や装飾要素を取り除きます。

アフォーダンス、シグニファイア、コントロール

• 動作に適している場合は、ネイティブのコントロールを使います。
• 馴染みのない操作や重大な操作には、アイコンとラベルを組み合わせます。
• リンク、ボタン、選択済みの項目、無効な項目、編集可能なフィールド、静的なテキストの違いを維持します。
• 目に見える代替手段がない限り、重要なアクションをジェスチャー、長押し、ホバー、小さなオーバーフローメニューの背後に隠しません。

選択肢と段階的な開示

• 最初に提示する選択肢は、現在の判断に必要なものに絞ります。
• 安全で可能性の高いデフォルトを使います。
• 詳細オプションは、必要となる場面の近くで表示します。
• 類似するプラン、製品、レコード、設定からユーザーが選ぶ必要がある場合は、比較しやすい構成にします。

フィードバックと状態

• コマンドを受け付けたことがすぐに分かるよう、簡潔なフィードバックを提示します。
• 遅延や非同期処理では進行状況を表示します。
• 結果が見えない場合は、完了を確認できるようにします。
• 現在の選択、ページ、フィルター、未保存の変更、オフライン／同期の状態を見えるようにします。
• 日常的な変化のない操作に、過剰なフィードバックを表示しないようにします。

エラーと復旧

• 可能であれば、送信前に制約を検証します。
• 無効なユーザー入力は表示したままにし、編集できるようにします。
• エラーは影響を受けるコントロールの近くに表示し、長文のエラーは要約します。
• 取り消し可能な操作には元に戻す機能を使い、取り消し不能またはリスクの高い操作には確認を求めます。
• 復旧可能な問題が起きた後、ユーザーに最初からやり直させてはいけません。

ナビゲーションと現在位置

• 現在のセクション、オブジェクト、状態、次へ進む／戻るための経路を表示します。
• パンくずリストは階層が深い場合に使い、明確なナビゲーションの代わりにはしません。
• タブは、同じコンテキストに属する同列のセクションにのみ使います。
• ドロワーやメニューは、使用頻度の低いアクションやスペースに制約がある場合に使います。頻繁に必要となる主要なナビゲーションを隠すのは避けます。
• 詳細画面から一覧に戻るときは、ルート、フィルター、スクロール位置を維持します。

学習しやすさ

• 初回利用時のヘルプは一時的なものとし、タスクに焦点を絞ります。
• 独立したヘルプ文書よりも、インラインの例や空状態でのガイダンスを優先します。
• 使い続けるうちに初心者向けのガイダンスが減るようにします。
• 基本は理解していてもすべてを覚えているわけではない「中級者」のために設計します。

アクセシビリティとインクルージョンの要件

• カスタムウィジェットよりも、セマンティック HTML とネイティブ要素を優先します。
• すべてのインタラクティブ要素に、アクセシブルな名前を付けます。
• フォーカスの順序を、視覚的な順序およびタスクの順序に合わせます。
• 視認できるフォーカスインジケーターを用意します。
• すべての操作をキーボードで行えるようにします。
• フォームコントロールに、ラベル、ヒント、エラーを関連付けます。
• プレースホルダーテキストだけをラベルとして使用しないでください。
• 色だけに依存しないでください。
• 非同期のステータスとエラーを適切に通知します。
• ダイアログが開いている間はフォーカスを閉じ込め、閉じたときにフォーカスを元に戻します。
• モーション低減の設定を尊重します。
• タッチ操作や運動機能の個人差に適したターゲットサイズにします。
• タスクと専門分野に合った、できるだけ平易な表現を使います。

フロントエンド実装のガイダンス

セマンティックな構造

• 操作には <button> を、ナビゲーションには <a> を使用します。
• 入力には、プログラムから認識できる永続的なラベルを使用します。
• 関連するラジオボタンやチェックボックスのグループには、フィールドセットと凡例を使用します。
• 見出しを論理的な順序で使用します。
• 表形式のデータには、レイアウトではなくテーブルを使用します。

状態とフィードバック

• 該当する場合は、デフォルト、ホバー、フォーカス表示、アクティブ、選択済み、展開／折りたたみ、無効、読み込み中、成功、警告、エラー、空、オフライン、読み取り専用の各状態を含めます。
• 必要に応じて、aria-expanded、aria-controls、aria-selected、aria-current、aria-invalid、aria-describedby、ライブリージョンを使用します。
• 無効にする理由が明らかな場合、または説明されている場合に限り、コントロールを無効にします。それ以外の場合は操作を許可し、ユーザーを案内します。
• 保留中の状態と、サーバー側の冪等な処理によって、重複送信を防ぎます。

フォーム

• type、autocomplete、inputmode、min、max、step、制約を適切に使用します。
• ユーザーが同等の形式で入力する可能性がある場合は、入力の柔軟性を保ちます。
• 複雑な入力項目はフォーカスが外れたとき、または送信時に検証します。入力中の検証は、挙動が安定しており、役立つ場合にのみ行います。
• 可能な限り、エラー、ページの更新、認証の中断、ネットワーク障害が起きても入力内容を保持します。

レスポンシブ対応と入力時の挙動

• ホバー操作が可能だと想定しないでください。
• 小さな画面でも、コンテキストを隠すことなく、主要な操作にアクセスできるようにします。
• 機能を損なわずに、テキストの拡大や折り返しができるようにします。
• キーボードのみでの操作、スクリーンリーダーの基本操作、タッチ操作、狭いビューポート、低速なネットワーク、高いズーム倍率でテストします。

品質チェックリスト

• ユーザーの主な目的が明示されています。
• 画面の目的がひと目で分かります。
• 主要な操作が副次的な操作より目立っています。
• ラベルにはユーザーになじみのある言葉を使っています。
• ホバーしなくてもインタラクティブ要素を見つけられます。
• 必須の選択肢を最小限に抑え、グループ化しています。
• 重要な操作の後に、インターフェースがステータスをフィードバックします。
• エラーは可能な限り防止し、防げない場合も回復できるようにしています。
• 破壊的な操作は取り消し可能にするか、明確な確認を求めます。
• 検証、認証、ネットワーク、ナビゲーションの問題によって、ユーザーが作業内容を失わないようにしています。
• ナビゲーションによって、「今どこにいるか」と「どこへ行けるか」が分かります。
• アクセシビリティの基本を取り入れています。
• フロントエンドの挙動を実装できる状態にしています。

references/checklists.md の完全版チェックリストを使用してください。

よくある間違いとその回避方法

• タスクより先にアプリの外枠から作り始める。
• 「使いやすさ」をチェック項目のひとつとして扱う。
• 主要な操作をメニュー、ジェスチャー、アイコンの奥に隠す。
• 分かりやすいラベルで済むところに、気の利いたラベルを使う。
• すべての操作を同じ重要度で見せる。
• システムが安全に推測できる情報を、ユーザーに尋ねる。
• 隠れた指示や状態をユーザーに覚えさせる。
• 取り消し機能の代わりに、頻繁な確認を求める。
• エラー文でユーザーを責める。
• 説明なしにコントロールを無効にする。
• 色だけに依存する。
• キーボードや支援技術での操作を考慮せずに、カスタムコントロールを設計する。
• アクセシビリティを最終監査の段階で初めて考慮する。
• 見た目のシンプルさと、タスクの複雑さの軽減を混同する。

アンチパターンの全リストは references/anti-patterns.md を参照してください。

• 空、読み込み中、オフライン、検証、権限、エッジケースの各状態を無視する。

推奨事項をユーザーに説明する方法

次のパターンを使用します。

I recommend [change] because users are likely trying to [goal]. The current version makes them [think/remember/guess/recover] unnecessarily. This change makes [action/state/recovery] visible and reduces [specific risk or effort]. The main tradeoff is [cost], which is acceptable unless [context that would change the decision].

依頼されたパターンに同意できない場合：

I would not hide this behind an icon-only menu because it is the primary path for the task. A better default is a visible labeled action. Use the menu only for secondary or infrequent actions.