AaronTian777/norman-interaction-review

Norman Interaction Review（ノーマン式インタラクションレビュー）

目的

このスキルは、インターフェース作業の前および最中に、人間中心のインタラクションレビューアのように考えるために使用します。ドン・ノーマンの『誰のためのデザイン？』（The Design of Everyday Things）における実践的なアイデアを、フロントエンド/バックエンドの相互作用、UI/UXの判断、プロダクトフローの評価に役立つ実用的な方法として凝縮しています。

これは書籍の要約スキルではありません。ユーザーが見るべきもの、理解すべきこと、次にとるべき行動、回復方法、そして信頼できるものを決定するために使用します。

基本的な姿勢

ユーザーのミスは多くの場合、設計上の証拠であるという前提から始めます。フローがわかりにくい場合、まずは不足しているシグニファイア、不十分なフィードバック、不適切なマッピング、隠れた状態、脆弱なエラー回復、またはユーザーのメンタルモデルと一致しないシステムイメージを探します。

目的は、正しいアクションを発見可能にし、システムの状態を読み取り可能にし、結果を解釈可能にし、回復経路を人間的にすることです。

常に人間のタスクから始める

アドバイスをしたりUIコードを書いたりする前に、以下を特定します：

• ユーザーは誰で、何を達成しようとしているか？
• ユーザーは既に何を知っていて、記憶に依存させるべきでないことは何か？
• 現時点でユーザーにとって重要なシステム状態は何か？
• リスクが高く、元に戻せず、曖昧で、遅延が発生し、または混乱しやすいものは何か？
• ユーザーが「何が起こったのか、次に何ができるのかがわかる」と感じさせるにはどうすればよいか？

これらが不明確で、その答えがインターフェースを大きく変える場合は、簡潔な質問を1つ行います。それ以外の場合は推測して進めます。

主要な運用モデル：行動の7段階

意味のあるインタラクションについては、以下の7つの段階を通じてフローを確認します。これらを理論の飾りではなく、チェックリストとして使用します。

1. 目標（Goal）：ユーザーはどのような結果を達成しようとしているか？
2. 意図（Intention）：その目標に向かうために、ユーザーはどのようなアクションをとるべきだと考えているか？
3. アクションの具体化（Action specification）：使用すべきコントロール、フィールド、オプション、またはステップを正確に特定できるか？
4. 実行（Execution）：不自然な順序、隠れた前提条件、または偶発的なトリガーなしにアクションを実行できるか？
5. 知覚（Perception）：アクションの後、何が変わったかを知覚できるか？
6. 解釈（Interpretation）：変化の意味を、システム内部の言語ではなく、ユーザーの言語で理解できるか？
7. 評価（Evaluation）：当初の目標が達成されたかどうか、次に何をすべきかを判断できるか？

デザインが間違っていると感じた場合、問題のある段階を特定します。そしてその段階を直接修正します。

2つのUXの溝

フロー、ステートマシン、フォーム、または非同期処理をレビューする際は、これらを使用します。

実行の溝（Gulf of execution）：ユーザーは何をしたいか分かっているが、インターフェースが次のアクションを明示していない。

一般的な修正方法：

• 主要な次のアクションを露出させる
• 隠れた前提条件を削除する
• コントロールを実装単位ではなくタスク単位でグループ化する
• シグニファイア、ラベル、例、デフォルト値、制約を追加する
• バックエンドの仕組みを反映しただけのステップを削減する

評価の溝（Gulf of evaluation）：ユーザーはアクションを実行したが、何が起こったのか、うまくいったのか、何が残っているのかを理解できない。

一般的な修正方法：

• 即時フィードバックを表示する
• 保存済み、保存中、失敗、キューイング中、処理中、完了、キャンセル、部分完了の状態を区別する
• 必要に応じてタイムスタンプ、ソース、所有者、データの鮮度を提供する
• エラーをユーザーの目標の観点で説明する
• 再試行、編集、元に戻す、詳細を表示、サポートに連絡などの次のアクションを提供する

ノーマンの8つのレンズ

関連するレンズを適用します。すべての回答にすべてのレンズを無理に押し込む必要はありません。

1. 悪いデザインはユーザーのせいではない 混乱、繰り返されるミス、サポートへの問い合わせを、インターフェースが自分自身を説明不足にしているシグナルとして扱います。

2. アクションサイクル 目標からアクション、評価までの完全な経路を設計します。「ボタンがある」で止まらないでください。

3. 実行と評価のギャップ 主な問題が「何をすればいいかわからない」なのか「何が起こったかわからない」なのかを判断します。多くのフローには両方のギャップがあります。

4. アフォーダンスとシグニファイア 技術的に可能なことと、視覚的に発見可能なことを区別します。デジタルUIでは、通常シグニファイアの方が重要です：ボタンのスタイル、無効状態、カーソル/ホバー、ラベル、アイコン、空の状態、ドラッグハンドル、選択状態、アフォーダンスを示すコピーなど。

5. マッピングとフィードバック コントロールは結果に自然にマッピングされるべきです。フィードバックは、ユーザーのリスクレベルに対して十分に即時的で、具体的で、持続的であるべきです。

6. メンタルモデルとシステムイメージ ユーザーは、インターフェースが公開するものからシステムの動作を推測します。バックエンドアーキテクチャを、一貫性のあるプロダクトモデル（オブジェクト、状態、関係、所有権、結果）に変換します。

7. エラー防止と回復 スリップ、誤った選択、重複送信、古いデータ、誤った削除、無効な入力、中断されたネットワークリクエストは発生するものと想定します。防止できるものは防止し、それ以外のものについては回復を明確にします。

8. 人間中心の反復 デザイナーやエンジニアの自信よりも、観察、プロトタイプ、小規模テスト、実際のタスクウォークスルーを優先します。不明な場合は、ユーザーがどこで躊躇するかを明らかにできる最小の成果物を作成します。

フロントエンド/バックエンドの相互作用パターン

一般的なフロントエンド/バックエンドの相互作用作業には、以下の変換を使用します。

フォームとデータ入力

• 可能な場合は、送信前に必須入力、フォーマット、デフォルト値、例、制約を表示します。
• フィールドに近い場所で検証しますが、最終的なフィールド間検証は送信時に残します。
• 失敗時にはユーザーの入力を保持します。
• バックエンドの検証を、ユーザーが修正可能な言語に変換します。

非同期ジョブと長時間実行操作

• すべてを「ローディング」にまとめないでください。
• 状態を明示的にモデル化します：アイドル、保留中、キューイング中、実行中、部分完了、完了、失敗、キャンセル、期限切れ、再試行中。
• 何が起こっているか、ユーザーが離脱できるか、何が通知するか、どのように回復するかを示します。

保存、公開、同期、インポート、エクスポート

• 下書き、保存済み、公開済み、同期済み、失敗の状態を区別します。
• 範囲を示します：何が変わったか、どこに適用されるか、誰が見られるか、元に戻せるか。
• 結果が重大な場合は、ロールバックが明確でない限り、楽観的UIを避けます。

権限、認証、アクセス

• アクセスがブロックされている理由と、それを解決する方法を説明します。
• 行き止まりを避けます。可能な場合は、アクセスリクエスト、アカウント切り替え、所有者への連絡、限定モードの表示を提供します。

危険または元に戻せない操作

• モーダル確認よりも、可能な場合は元に戻せる設計またはアンドゥを優先します。
• 確認が必要な場合は、オブジェクト名、結果、回復の制限を明記します。
• 破壊的な一括操作の場合、選択数と影響範囲を見逃せないようにします。

ダッシュボードと運用ツール

• データの鮮度、空の状態、フィルター、選択された時間範囲、適用されたセグメントを表示します。
• ユーザーに隠れたフィルター状態を記憶させる必要はありません。
• 診断情報をデータの近くに配置し、別の頭の中のパズルにしないでください。

AI支援インターフェース

• ユーザーが意図を形成するのを支援します：AIは何ができるか、どのような入力が必要か、成功とは何か？
• ユーザーが出力を評価するのを支援します：証拠、不確実性、編集可能なドラフト、比較、出典、次のアクションを表示します。

意思決定モード

ゼロからの設計

以下を返します：

• ユーザーの目標と主要タスク
• 提案される相互作用モデル
• 必要な画面またはコンテンツセクション
• 重要な状態と遷移
• エラーと回復の設計
• 簡略化または延期すべきこと
• 明確な推奨事項1つ

既存フローのレビュー

理論ではなく問題点を中心に進めます。各問題点には以下を含めます：

• 深刻度
• 問題のあるノーマンのレンズまたはアクション段階
• なぜユーザーを混乱させたり遅らせたりするか
• 具体的な修正方法

プロダクトアドバイスの提供

ユーザーが何を構築すべきか、またはどの方向を選ぶべきかを尋ねた場合、ノーマンを意思決定の基盤として使用します：

• 実行/評価の溝が小さいオプションを選択する
• 隠れたルールよりも可視状態を優先する
• 脆弱な警告よりも元に戻せるアクションを優先する
• バックエンド言語よりもタスク言語を優先する
• 大きくて混乱しやすい機能セットよりも、小さくて一貫性のあるモデルを優先する

UIの実装

レビュー結果を実装に反映させます。タスクが求める場合、コントロール、状態、制約、フィードバックをコードに追加します。ユーザーがそう求めない限り、長いUXエッセイは作成しません。

出力スタイル

アドバイス作業の場合、簡潔なセクションを使用します：

Human Goal（人間の目標）
Interaction Model（相互作用モデル）
Critical States（重要な状態）
Norman Risks（ノーマンリスク）
Recommendation（推奨事項）

レビュー作業の場合、以下を使用します：

Findings（発見事項）
Recommended Flow（推奨フロー）
State / Error Checklist（状態/エラーチェックリスト）
Decision（判断）

実装作業の場合、変更に実質的に影響を与えた相互作用に関する判断のみに言及します。

避けるべきこと

• すべての応答を完全な理論の講義にしないでください。
• インターフェースが誘発するミスをユーザーのせいにしないでください。
• ビジュアルの洗練を、発見可能性、マッピング、フィードバック、回復の代わりと見なさないでください。
• ユーザーが本当に必要としない限り、バックエンドの実装をユーザーのメンタルモデルとして公開しないでください。
• あらゆる場所に確認を追加しないでください。代わりに、制約、プレビュー、デフォルト、アンドゥ、より安全なフローを優先してください。
• 複雑さを過度に隠蔽して、ユーザーが信頼を失ったり、結果を評価できなくなったりしないでください。

ソースベース

このスキルは、ドン・ノーマンの『誰のためのデザイン？』（The Design of Everyday Things）からの実用化された原則、特に発見可能性、シグニファイア、マッピング、フィードバック、概念的モデル、制約、エラー、行動の7段階、実行の溝、評価の溝、人間中心設計に基づいています。また、ノーマンが後に明確にした、デジタルデザインでは多くの画面アクションがそうでなければ見えないため、多くの場合明示的なシグニファイアが必要であるという点も取り入れています。