human-centered-design-fundamentals

人間中心設計の基本

人間が恣意的なシステム要件に適応することを求めるのではなく、実際の人間の認知や行動に対応する製品を設計します。

使用する場面

✅ 次の場合に使用します：

• 物理的な製品の設計（ドア、家電、操作部、ツール）
• デジタルインターフェースの設計（ソフトウェア、タッチスクリーン、ダッシュボード）
• 人的ミスが重大な結果を招くシステムの設計（医療機器、産業用制御装置、航空機）
• ユーザーのミスが繰り返し発生したシステムの再設計
• 手順書やドキュメントの作成
• エラーの防止と安全性が極めて重要なシステム

❌ 次の場合には使用しません：

• 機能的な要素を含まない純粋なビジュアルデザイン
• マーケティングやブランドアイデンティティ
• 人とのやり取りがない自律型システム
• ユーザーが無制限にトレーニングを受けられ、完全な記憶力を持つシステム

基本プロセス

行為の7段階に基づく意思決定ツリー

START: User encounters system
│
├─→ Is this GOAL-DRIVEN (user has objective)?
│   ├─→ YES: Begin at Stage 1 (Form Goal)
│   │   ├─→ Can user identify what they want? 
│   │   │   ├─→ NO: MISTAKE likely → Provide clear conceptual model
│   │   │   └─→ YES: Proceed to Stage 2
│   │   │
│   │   ├─→ Stage 2: Plan action sequence
│   │   │   ├─→ Are alternatives clear?
│   │   │   │   ├─→ NO: MISTAKE likely → Improve discoverability
│   │   │   │   └─→ YES: Proceed to Stage 3
│   │   │
│   │   ├─→ Stage 3: Specify action
│   │   │   ├─→ Is correct action obvious?
│   │   │   │   ├─→ NO: Gulf of Execution too wide → Add signifiers
│   │   │   │   └─→ YES: Proceed to Stage 4
│   │   │
│   │   └─→ Stage 4: Perform action
│   │       ├─→ Is user expert (subconscious execution)?
│   │       │   ├─→ YES: High SLIP risk → Add forcing functions
│   │       │   └─→ NO: Conscious execution → Provide clear affordances
│   │
└─→ Is this EVENT-DRIVEN (environmental trigger)?
    └─→ YES: Begin at Stage 5 (Perceive state)
        ├─→ Stage 5: Perceive world state
        │   ├─→ Is feedback immediate (<0.1s)?
        │   │   ├─→ NO: Add immediate feedback
        │   │   └─→ YES: Proceed to Stage 6
        │
        ├─→ Stage 6: Interpret perception
        │   ├─→ Does system state make sense?
        │   │   ├─→ NO: Gulf of Evaluation too wide → Improve conceptual model
        │   │   └─→ YES: Proceed to Stage 7
        │
        └─→ Stage 7: Compare with goal
            ├─→ Is outcome clear?
            │   ├─→ NO: Add better feedback + conceptual model
            │   └─→ YES: Action cycle complete
            │
            └─→ Goal achieved?
                ├─→ NO: Return to Stage 2 (new plan)
                └─→ YES: END

デザイン評価の意思決定ツリー

EVALUATE DESIGN: Start here
│
├─→ Discoverability Check
│   ├─→ Can user determine possible actions without instructions?
│   │   ├─→ NO: Missing signifiers → Add visible indicators
│   │   └─→ YES: Check constraints
│   │
│   ├─→ Are constraints visible and effective?
│   │   ├─→ NO: Add physical/semantic/cultural/logical constraints
│   │   └─→ YES: Check mapping
│   │
│   └─→ Is control-to-effect mapping natural?
│       ├─→ NO: Redesign spatial relationships or use cultural conventions
│       └─→ YES: Proceed to Understanding Check
│
├─→ Understanding Check
│   ├─→ Does system image communicate conceptual model?
│   │   ├─→ NO: Improve structure, labels, documentation
│   │   └─→ YES: Check feedback
│   │
│   ├─→ Is feedback immediate and informative?
│   │   ├─→ NO: Add/improve feedback mechanisms
│   │   └─→ YES: Check processing levels
│   │
│   └─→ Are all three levels addressed?
│       ├─→ Visceral: Is it aesthetically appealing?
│       ├─→ Behavioral: Does it support learned patterns?
│       └─→ Reflective: Will memory of use be positive?
│
└─→ Error Prevention Check
    ├─→ What error types are possible?
    │   ├─→ SLIPS (execution errors)?
    │   │   └─→ Add forcing functions, reduce steps, prevent capture
    │   ├─→ MISTAKES (planning errors)?
    │   │   └─→ Improve conceptual model, add feedforward
    │   └─→ MEMORY LAPSES?
    │       └─→ Put knowledge in world, add reminders, minimize steps
    │
    ├─→ Are modes present?
    │   ├─→ YES: MODE ERROR risk
    │   │   ├─→ Can you eliminate modes?
    │   │   │   ├─→ YES: Eliminate them
    │   │   │   └─→ NO: Make current mode extremely salient
    │   │
    └─→ Does security exceed human capability?
        └─→ YES: Users will create workarounds → Redesign for actual capabilities

根本原因分析プロセス

INCIDENT OCCURS
│
├─→ Ask: "What happened?" (Identify symptom)
│   └─→ Document observable failure
│
├─→ Ask: "Why did this happen?" (First cause)
│   ├─→ Answer: "Human error"
│   │   └─→ NEVER STOP HERE - This is anti-pattern
│   └─→ Continue investigation
│
├─→ Ask: "Why did the human make that error?" (Second why)
│   ├─→ Was signifier missing/unclear?
│   ├─→ Was feedback absent/poor?
│   ├─→ Was mapping unnatural?
│   ├─→ Was conceptual model wrong?
│   └─→ Continue for each factor
│
├─→ Ask: "Why was design inadequate?" (Third why)
│   └─→ Investigate design process failures
│
├─→ Ask: "Why did process fail?" (Fourth why)
│   └─→ Investigate organizational factors
│
├─→ Ask: "Why did organization allow this?" (Fifth why)
│   └─→ Reach fundamental systemic cause
│
└─→ DECISION: Fix person or fix system?
    ├─→ Multiple people made same error?
    │   └─→ YES: System design failure → REDESIGN SYSTEM
    └─→ Isolated incident with unique circumstances?
        └─→ Investigate further - may still be system issue

アンチパターン

🚫 人的ミスのせいにする

初心者のアプローチ：

• インシデントが発生する
• 調査により、オペレーターの行動が直接的な原因として特定される
• 結論：「人的ミス。オペレーターには再訓練が必要」
• 対応：オペレーターを懲戒・交代させ、警告を増やす
• タイムライン：数時間から数日以内に、すぐさま責任を押し付ける

専門家のアプローチ：

• インシデントが発生する
• 人の行動は原因ではなく、症状として捉える
• 「なぜオペレーターはその選択をしたのか？」と「なぜ」を5回繰り返す
• 発見：曖昧なシグニファイア、モードの混乱、不十分なフィードバック、過度な記憶負荷
• 結論：「システムが人間の能力を支援できていなかった」
• 対応：エラーが起きる状況を防ぐよう、インターフェースを再設計する
• タイムライン：システムに内在する要因を理解するため、数週間にわたって調査する

合言葉：「エラーが頻発するなら、それは設計の失敗です。人的ミスはたいてい設計の不備が原因です。システムエラーと呼ぶべきです。」

---

🚫 ノーマン・ドア（シグニファイアの失敗）

初心者のアプローチ：

• 見た目を損なわないよう、装飾を抑えた美しいドアを設計する
• 両側に同じ金具を使う
• 人が戸惑ったら、小さな「押す」サインを付ける
• サインを読まないユーザーのせいにする
• タイムライン：最初の苦情から数日後にサインを追加する

専門家のアプローチ：

• 操作方法がデザインから自然に伝わるようにする
• 押す側：引く操作を促さない、平らなプレート
• 引く側：握ることを促す、縦向きのハンドル
• 該当する場合は、ヒンジ側が見えるようにする
• サインは不要。金具そのものがシグニファイアとなる
• タイムライン：初期の設計仕様から正しく設計する

合言葉：「ドアのデザインは、サインを必要とせず、ましてや試行錯誤を必要とせずに、使い方を示すべきです。」

---

🚫 モードエラー

初心者のアプローチ：

• 1つのボタンが、モードによって異なる機能を実行する
• モードは小さなアイコンで示すか、メニューの奥に隠す
• モードの仕組みはユーザーマニュアルで説明する
• 「ユーザーは現在のモードを覚えておくべき」
• タイムライン：モードの混乱はすぐに起きるが、ユーザーのミスと見なされる

専門家のアプローチ：

• 異なる機能には異なる操作部を使い、モード自体を最小限にする
• モードを避けられない場合：現在のモードを極めて目立つ形で示す
• 危険なモード切り替えを防ぐ強制機能を使う
• 見落としようのない物理的なモード表示を設ける
• 割り込みがあってもモードが明確にわかるかテストする
• タイムライン：リリース前のプロトタイプテストでモードの明確さを検証する

合言葉：「モードエラーは設計エラーです。機器に複数のモードがあるなら、現在のモードを機器上ではっきり見えるようにしなければなりません。」

🚫 頭の中に知識があるという前提

初心者のアプローチ：

• 大文字・小文字、数字、記号を組み合わせた、8文字以上のパスワードをユーザーが暗記することを期待します
• 複数の手順を覚えておくことを求めます
• 一度だけトレーニングを行い、内容が定着したと想定します
• 「ユーザーはもっと注意を払う必要があります」
• タイムライン：パスワードポリシーを1回の会議で作成します

エキスパートのアプローチ：

• 作業記憶で保持できるのは3〜7項目であり、中断によって損なわれやすいと認識します
• 知識を環境に置くように設計します：構造、制約、目に見えるリマインダー
• 多要素認証：「所持しているもの」＋「知っていること」
• 手順がインターフェースの構造から自明になります
• 重要な手順にはチェックリストや外部の補助を使います
• タイムライン：反復テストで記憶の失敗が明らかになり、設計が進化します

識別の合言葉：「人々の記憶を助ける最も効果的な方法は、覚える必要をなくすことです。必要な知識を環境に置きましょう。」

---

🚫 フィードバックの欠如

初心者のアプローチ：

• ボタンを押すとバックグラウンドプロセスが起動します
• 操作が受け付けられたことを示す表示がありません
• ユーザーはクリックが認識されたかどうかわかりません
• ユーザーが何度もクリックします（「ボタンの連打」）
• システムが複数のリクエストを処理します
• タイムライン：ユーザーが重複に気づいた後、数日〜数週間で苦情が表面化します

エキスパートのアプローチ：

• 操作から0.1秒以内に即座にフィードバックします
• ボタンが押された状態を表示します
• 1秒を超える操作には進行状況インジケーターを表示します
• 完了を明確に確認できるようにします
• ロックインを強制する仕組みで重複操作を防ぎます
• タイムライン：フィードバックを初期プロトタイプの段階から設計に組み込みます

識別の合言葉：「フィードバックは即時で、有益であり、適切に優先順位付けされていなければなりません。質の悪いフィードバックは、フィードバックがないことよりも悪い場合があります。」

---

🚫 ユーザビリティより美観を優先

初心者のアプローチ：

• 視覚的なミニマリズムのために、すべての操作部を隠します
• ドアの金具を見えなくします（滑らかなガラス）
• 触覚フィードバックのないタッチセンサー式の表面を使います
• 「すっきりしたデザイン」とは、機能がないことを意味します
• タイムライン：賞を受賞し、ユーザビリティに関する苦情を何年も無視します

エキスパートのアプローチ：

• 美しさと使いやすさは必ずしも相反しないと考えます
• 操作部を見えるようにしつつ、洗練された形で一体化します
• アフォーダンスを美観の向上に役立て、損なわないようにします
• 本能レベル（美しさ）と行動レベル（使いやすさ）、さらに内省レベル（所有する誇り）に対処します
• タイムライン：反復的なプロトタイプで、3つすべての処理レベルのバランスを取ります

識別の合言葉：「魅力的なものはよりよく機能します。ただし、それらが実際によく機能する場合に限ります。優れたデザインは、ニーズに完璧に合っているため、意識されません。」

---

🚫 過剰なセキュリティ劇場

初心者のアプローチ：

• 12文字以上のパスワードを毎月変更します
• 複雑なルールを設けます：大文字、小文字、数字、記号を使い、辞書に載っている単語は使わない
• 日常的な作業にも複数の認証手順を設けます
• 3回失敗するとユーザーをロックアウトします
• タイムライン：セキュリティポリシーを1四半期でトップダウン方式により実施します

エキスパートのアプローチ：

• 人間は50個以上の複雑なパスワードを覚えられないと認識します
• 現実を受け入れます：過剰なセキュリティは、回避策によってかえってセキュリティを損ないます
• ユーザーはパスワードをモニターに貼り付けたり、「Password123!」を使ったり、ロックを無効にしたりします
• 人間の限界を前提に設計します：パスワードマネージャー、生体認証、トークン
• セキュリティと使いやすさのバランスを取り、逆効果な行動を防ぎます
• タイムライン：セキュリティのユーザビリティテストで実際のユーザー行動が明らかになり、ポリシーが調整されます

識別の合言葉：「システムを過度に安全にすると、かえって安全性が低下します。人間がこうあってほしいと思う姿ではなく、実際の行動を受け入れなければなりません。」

メンタルモデルと識別の手掛かり

湾のメタファー：

• 初心者：「ユーザーが湾を渡るにはトレーニングが必要です」
• 専門家：「デザイナーは、シニファイア（実行）とフィードバック＋概念モデル（評価）を通じて、湾を渡る橋を架けます」

知識の分布：

• 初心者：「ユーザーは手順を記憶するべきです」
• 専門家：「人と人工物の組み合わせが知性を生み出します。デザインは知識を世界の中に配置します」

エラーの帰属：

• 初心者：「オペレーターのミスが失敗の原因です」
• 専門家：「ヒューマンエラーで考察を止めてはいけません。ファイブ・ホワイを適用し、システム上の原因にたどり着きます」

スイスチーズモデル：

• 初心者：「単一の根本原因を見つけます」
• 専門家：「複数の防御層にある穴が同時に重なったときに、事故が発生します」

行動のサイクル：

• 初心者：「ユーザーは常に明確な目標を持って行動を開始します」
• 専門家：「行動は目標駆動型（トップダウン）にも、イベント駆動型（状況に応じた行動）にもなり得ます。デザインはその両方を支援します」

処理のレベル：

• 初心者：「機能性に注目します」
• 専門家：「本能レベル（即時的な美しさ）、行動レベル（学習されたパターン）、内省レベル（長期的な記憶と意味）に対応します」

時代ごとの知見

1988年（初版）： アフォーダンスに焦点を当て、学術的な認知心理学の視点を採用。「Psychology of Everyday Things」というタイトルで、科学的な基盤を強調

2013年（改訂版）： デジタルデザインのコミュニティで混乱が生じていることを受け、アフォーダンスからシニファイアへと重点を移行。感情、エクスペリエンスデザイン、デザイン思考に関する章を追加し、著者のApple／HPでの経験に基づくビジネスや業界の視点を取り入れた

自動化以前の時代（<1900s）： 物理的な対象を直接操作し、即座に機械的なフィードバックを得る。人間のオペレーターは、原因と結果の関係が明確な複雑なシステムを制御していた

近代的な自動化（1900s-2000s）： ユーザーとシステムの直接的な制御との分離、自動化に起因する新たなエラーモードの発生。また、自動化の進展によってオペレーターにより高いスキルが求められる「自動化の皮肉」

タッチスクリーンの時代（2000s+）： 物理的なアフォーダンスの喪失、ジェスチャーベースのインタラクション。「ウィンドウを動かす」から、スクロールによって「テキストを動かす」へとメタファーが変化。触覚フィードバックの排除により、より明確な視覚的シニファイアが必要に

現在の課題（2010s+）： セキュリティ要件と人間の認知能力の限界とのバランスを取ること、中断の多いマルチタスク環境に対応したデザイン、高齢化に伴う能力の低下への配慮

参考文献

• 出典：Don Norman著『The Design of Everyday Things』（改訂増補版、2013年）
• 初版：『The Psychology of Everyday Things』（1988年）
• 基礎：人間の知覚、記憶、行動、エラーに関する認知心理学研究