デイリーシングスのデザインフレームワーク

直感的で発見しやすく、理解しやすい製品を作成するための基礎設計原則。「UXのバイブル」として知られており、物理製品、ソフトウェア、あらゆる人間が設計したシステムに適用可能です。

コアプリンシパル

優れたデザインは悪いデザインよりも目立たないというのが実情です。なぜなら、優れたデザインは私たちのニーズにぴったり合致するため、デザイン自体が見えなくなるからです。 何かが上手く機能すれば、私たちはそれを当たり前のように受け入れます。失敗すれば、自分たちを責めますが、その責任はほぼ常にデザインにあります。

基本原則: デザインは、人が何をしたいのかと製品が何をさせてくれるのかとの間の隔たりを埋める必要があります。最良のデザインは発見しやすく（何をすべきか理解できる）、理解しやすい（何が起きたか理解できる）ものです。

スコアリング

目標: 10/10。 デザインを検討または作成する際、発見しやすさ、理解しやすさ、エラー防止に基づいて0～10のスコアを付けます。10/10というのは、ユーザーが説明書なしで何をすべきかを理解でき、何が起きたかを理解でき、エラーから簡単に回復できることを意味します。常に現在のスコアと10/10に達するための改善案を提供してください。

2つのガルフ

製品との相互作用はすべて、2つのガルフを橋渡しする必要があります：

ユーザー                                    製品
  │                                        │
  ├──── 実行のガルフ ────────────────→│
  │     「私が望むことをするには?」      │
  │                                        │
  │←──── 評価のガルフ ──────────────┤
  │     「何が起きた? うまくいった?」    │

実行のガルフ

ユーザーが何をしたいのかと、製品が何をさせてくれるのかとの間の隔たり。

ユーザーが尋ねる質問:

• ここで何ができるのか?
• どうやってするのか?
• どのコントロールを使うのか?
• このコントロールをどう操作するのか?

橋渡し戦略:

• 何が可能かを示す明確なシグニファイア
• コントロールと結果の間の自然なマッピング
• 間違った行動を防ぐ制約
• 馴染み深いメンタルモデル

評価のガルフ

製品が何をしたのかと、ユーザーが何が起きたのかを理解することとの間の隔たり。

ユーザーが尋ねる質問:

• 何が起きた?
• うまくいった?
• これが私が望んでいたことなのか?
• システムは今どのような状態なのか?

橋渡し戦略:

• 即時で見える視覚的フィードバック
• 明確なシステム状態インジケータ
• 意味のあるエラーメッセージ
• 進捗インジケータ

デザインゴール: 両方のガルフを可能な限り狭くします。理想的なデザインではガルフを埋める必要がなく、アクションと理解は瞬時に起こります。

参照: references/two-gulfs.md ガルフ分析演習の詳細

7つの基本的なデザイン原則

1. 発見可能性 (Discoverability)

定義: ユーザーが可能なアクションと実行方法を理解できるか?

発見可能性の5つの要素:

• アフォーダンス
• シグニファイア
• コンストレイント
• マッピング
• フィードバック

(それぞれ以下で詳述)

テスト: 新しいユーザーを製品の前に座らせます。10秒以内に何をすべきかを理解できるか? できない場合、発見可能性が破綻しています。

アンチパターン: 「ユーザーマニュアルで説明しています。」ユーザーがマニュアルを必要とする場合、デザインは失敗しています。

2. アフォーダンス (Affordances)

定義: オブジェクトの特性とエージェント(ユーザー)の機能の間の関係で、オブジェクトがどのように使用される可能性があるかを決定するもの。

重要な洞察: アフォーダンスは、知覚されるかどうかに関わらず存在します。ドアは押されるべきことを知らなくても、押すというアフォーダンスを提供しています。重要なのは知覚されたアフォーダンスです。

タイプ:

タイプ	定義	例
実在するアフォーダンス	物理的な機能が存在する	ボタンは押すことができる
知覚されたアフォーダンス	ユーザーは機能が存在すると信じている	隆起したエリアがクリック可能に見える
隠れたアフォーダンス	機能は存在するが明白ではない	右クリックコンテキストメニュー
虚偽のアフォーダンス	アクションを提供するように見えるが、実際には提供しない	クリック可能に見えるが装飾的な要素
反アフォーダンス	アクションを防ぐ	動きを塞ぐバリア

デジタルアプリケーション:

要素	アフォーダンス	シグナル方法
ボタン	クリック/タップできる	隆起、色付き、影、ホバー状態
テキストフィールド	テキスト入力できる	ボーダー、プレースホルダーテキスト、ラベル
リンク	ナビゲーションできる	色、下線、カーソル変化
スライダー	ドラッグできる	ハンドル、トラック、視覚的範囲
スクロール領域	スクロールできる	スクロールバー、エッジのフェード、部分的な内容

一般的な失敗:

• フラットデザインが知覚されたアフォーダンスを削除している(ボタン? ラベル?)
• タッチターゲットが小さすぎる(ファットフィンガー問題)
• インタラクティブな要素と装飾的な要素の視覚的区別がない

参照: references/affordances.md アフォーダンスデザインパターンの詳細

3. シグニファイア (Signifiers)

定義: アクションがどこで起こるべきかを伝えるシグナル。

重要な洞察: アフォーダンスは何が可能かを決定します。シグニファイアはどこで、どのようにするかを伝えます。

アフォーダンスは何ができるかです。シグニファイアはそれをどのように行うかを示します。

タイプ:

タイプ	定義	例
意図的なシグニファイア	伝える目的でデザインされている	ドアの「Push」ラベル、プレースホルダーテキスト
偶然的なシグニファイア	無意図的だが有益である	草の中の踏み跡(人が歩く)
社会的シグニファイア	他の人の行動	行列(入口を示唆)

デジタルシグニファイア:

シグニファイア	伝える内容	例
カーソル変化	これはインタラクティブです	ポインタ → リンク上の手
ホバー状態	これはインタラクションに応答します	ボタンの色がホバーで変わる
プレースホルダーテキスト	ここに何を入力するか	「メールアドレスを入力...」
アイコン	要素の機能	虫眼鏡 = 検索
ラベル	このコントロールが何をするか	「送信」、「キャンセル」、「次へ」
色	ステータスまたはカテゴリー	赤 = エラー、緑 = 成功
位置	関係と階層	閉じるボタンが右上隅

デザインルール: 疑わしい場合は、シグニファイアを追加します。ユーザーを推測させるより、過度に伝えるほうがましです。

参照: references/signifiers.md シグニファイアパターンと例の詳細

4. マッピング (Mappings)

定義: コントロールとその効果の間の関係。

自然なマッピング: コントロールの空間的レイアウトが、制御対象のレイアウトと一致する場合。

例:

マッピング品質	例	機能する/機能しない理由
自然	ハンドルが車の方向を変える	直接的な空間的対応
自然	ボリュームスライダー(上 = より大きい)	メンタルモデルと一致
不十分	ライトスイッチパネル(どのスイッチ = どのライト?)	空間的対応なし
不十分	一列のストーブコントロール(どのノブ = どのバーナー?)	レイアウトが一致しない

デジタルマッピング原則:

• コントロールは影響を受けるものの近くにあるべき
• コントロールのレイアウトはコンテンツのレイアウトを反映すべき
• アクションの方向は期待と一致すべき(下にスクロール = コンテンツが上に移動)
• 関連するコントロールをグループ化

マッピング技術:

技術	動作方法	例
近接	コントロールがターゲットの近くにある	コンテンツの横にある編集ボタン
空間的	レイアウトが現実世界を反映している	地図コントロールが羅針盤方向と一致
文化的	慣例に従う	赤 = 停止/危険、緑 = 進行/安全
順序的	自然な順序に従う	ステップ1、2、3が左から右(または上から下)

参照: references/mappings.md マッピング分析演習の詳細

5. コンストレイント (Constraints)

定義: 可能なアクションを制限してエラーを防ぐ。

4つのタイプ:

タイプ	メカニズム	例
物理的	形/サイズが間違ったアクションを防ぐ	USBプラグは1つの方向にのみ装着(USB-Cは両方)
文化的	社会規範が行動を導く	赤は停止、緑は進行
意味的	意味が選択肢を制限する	バックミラーは後ろを向いてのみ意味がある
論理的	ロジックが選択肢を制限する	最後のねじ用に残された穴は1つだけ(消去法)

デジタルコンストレイント:

コンストレイントタイプ	実装	例
入力検証	入力内容を制限	自由テキストではなく日付ピッカー
無効化状態	利用不可能なオプションをグレーアウト	フォームが有効になるまで「送信」を無効化
段階的な開示	関連するときのみオプションを表示	「購入」を選択した後に支払いフィールドが表示
強制順序	ステップは順序で完了する必要がある	ロックされたステップを伴うウィザード/ステッパー
取り消し/やり直し	反転を許可	Gmailの「送信を取り消し」

コンストレイントの力: 追加するすべてのコンストレイントは、ユーザーが犯す可能性のある1つのエラーが少なくなります。

デザインルール: ユーザーに間違った行動をさせないようにしてください。間違った行動をした場合にペナルティを与えるのではなく。

参照: references/constraints.md コンストレイントデザインパターンの詳細

6. フィードバック (Feedback)

定義: アクションの結果をユーザーに伝える。

フィードバックは以下でなければなりません:

• 即時: 直接操作の場合は0.1秒以内
• 有益: 何が起きたか、現在のステータスをユーザーに伝える
• 適切: 多すぎない(うるさい)、少なすぎない(混乱)
• 邪魔でない: ユーザーのワークフローを塞がない

フィードバックのタイプ:

タイプ	使用時期	例
視覚的	ほとんどのアクション	ボタンプレスアニメーション、色の変化、チェックマーク
聴覚的	重要なイベント、確認	成功音、エラー音、通知
触覚的	タッチデバイス、確認	キープレスの振動、フォースフィードバック
進捗	長時間のオペレーション	プログレスバー、スピナー、スケルトンスクリーン

デジタルフィードバックパターン:

状況	必要なフィードバック	例
ボタンクリック	視覚的状態変化	ボタンが押下、色が変わる
フォーム送信	成功/エラーメッセージ	「保存されました!」トースト、または文中エラー
読み込み中	進捗インジケータ	スピナー、スケルトンスクリーン、パーセンテージ
エラー	何が間違ったか + 修正方法	「無効なメール。形式を確認してください。」
ホバー	インタラクティブ要素インジケータ	背景色の変化、下線
ドラッグ	オブジェクトがカーソルに従う	要素がマウスと一緒に移動

一般的な失敗:

• フィードバックなし(クリックは登録された?)
• 遅延されたフィードバック(システムが壊れたように見える)
• 不明なフィードバック(何かが起きたが何?)
• 多すぎるフィードバック(すべてのアクションがアラートをトリガー)

応答時間ガイドライン:

• 0.1秒: 瞬時に感じる(直接操作)
• 1.0秒: 遅延が目立つ(カーソル変化を表示)
• 10秒: 注意が散らかる(プログレスバーを表示)

• 10秒: ユーザーが去る(パーセンテージを表示、バックグラウンドを許可)

参照: references/feedback.md フィードバックデザインパターンの詳細

7. メンタルモデル (Conceptual Models)

定義: ユーザーが製品がどのように機能するかについて持つメンタルモデル。

3つのモデル:

モデル	保有者	説明
デザインモデル	デザイナー	デザイナーが思う動作方法
ユーザーのモデル	ユーザー	ユーザーが思う動作方法
システムイメージ	製品	製品が実際に伝えること

ゴール: ユーザーのモデルがデザインモデルと一致すべきです。システムイメージはその架け橋です。

モデルが一致するとき:

• ユーザーは結果を正しく予測できる
• ユーザーはエラーから簡単に回復できる
• ユーザーは自信を持ち、管理下にあると感じる

モデルが一致しないとき:

• ユーザーは混乱して落ち込む
• ユーザーは自分たちを責める
• ユーザーはあきらめるか、サポートに電話する

例: サーモスタット

• デザインモデル: 温度を設定するとシステムが維持する
• 一般的なユーザーモデル: より高い設定 = より速い加熱(間違い!)
• 結果: ユーザーがより速い温暖化を期待して、サーモスタットを90°Fに上げる

正しいメンタルモデルの構築:

• 馴染み深いメタファーを使用(デスクトップ、フォルダ、ゴミ箱)
• システムの状態を見えるようにする
• 明確なフィードバックを提供する
• 一貫した動作(同じアクション = 同じ結果)を使用する
• 段階的な開示(最初はシンプルモデル、詳細は利用可能)

参照: references/conceptual-models.md モデルデザインフレームワークの詳細

ヒューマンエラー

ノーマンの重要な洞察: 「ヒューマンエラー」というものは存在しません。悪いデザインが存在するだけです。

誰かがエラーを犯したとき、その人の欠陥ではなく、デザインの欠陥を探してください。

エラーの種類

スリップ: 正しい意図、間違ったアクション

スリップタイプ	原因	例	デザイン修正
アクションスリップ	正しいターゲットの間違ったアクション	「編集」の代わりに「削除」をクリック	破壊的なアクションを分離
メモリラプス	シーケンスのステップを忘れる	「添付」と書いた後、添付を忘れる	Gmailの添付リマインダー
モードエラー	正しいアクション、間違ったモード	Caps Lockで入力	モード状態を明確に表示
キャプチャーエラー	馴染み深いアクションが意図を上書き	自動操縦で古いオフィスに向かって運転	決定ポイントでの割り込み

ミステイク: 間違った意図、正しく実行

ミステイクタイプ	原因	例	デザイン修正
ルールベース	間違ったルールを適用	状況に適さない公式を使用	文脈を提供、確認
ナレッジベース	不完全/間違ったメンタルモデル	システムの動作を誤解	より優れたメンタルモデル
メモリラプス	ゴールまたはプランを忘れる	冷蔵庫を開いた理由を忘れる	リマインダー、履歴を提供

エラーのためのデザイン

エラー防止:

• エラーを不可能にするコンストレイント
• すべてのアクションの取り消し/やり直し
• 破壊的なアクションの確認
• 賢いデフォルト
• 寛容な入力(変動を受け入れる)

エラー復旧:

• 明確なエラーメッセージ(何が起きた + 修正方法)
• エラーでユーザーの作業を削除しない
• 部分的な保存を許可
• 既知の良好な状態へのリセットが簡単

エラーメッセージチェックリスト:

• 何が間違ったかを明記(人間の言語で)
• 修正方法を明記
• ユーザーを責めない
• ユーザーの作業を保持
• 代替パスを提供

参照: references/human-error.md エラー防止パターンの詳細

7つのアクションステージ

ノーマンの製品との相互作用方法のモデル:

1. ゴール      → 「温度を調整したい」
2. プラン      → 「サーモスタットを使う」
3. 指定        → 「上矢印を押す」
4. 実行        → (ボタンを押す)
   ─── 実行のガルフ ───
5. 知覚        → (表示が変わるのを見る)
6. 解釈        → 「数字が上がった」
7. 比較        → 「これが私が望んでいたことか?」
   ─── 評価のガルフ ───

デザインの含意:

• ステージ1-3(実行): 明確なシグニファイア、マッピング、コンストレイントでサポート
• ステージ4(アクション): 良好なアフォーダンスでサポート
• ステージ5-7(評価): 明確なフィードバック、システム状態でサポート

評価ツールとして使用: すべてのインタラクションについて各ステージをウォークスルーします。ユーザーはどこで立ち往生しますか?

参照: references/seven-stages.md ステージごとの分析の詳細

ヒューマンセンタードデザイン(HCD)プロセス

ノーマンのデザインプロセス:

観察 → アイデア生成 → プロトタイピング → テスト → (繰り返す)

1. 観察

• 現実の文脈で実際のユーザーを観察する
• 彼らが何を望んでいるか尋ねないでください(彼らは知らない)
• 回避策、欲求不満、適応を探す
• 個別のタスクではなく、アクティビティに焦点を当てる

2. アイデア生成

• 多くのアイデアを生成(収束する前に発散)
• アイデア出しの際に批判しない
• 他のアイデアを基に構築する
• 判断を遅延させる

3. プロトタイピング

• 迅速、安価、使い捨て
• ポーランドではなく、概念をテストする
• 初期のアイデアについては紙のプロトタイプ
• 検証のためのインタラクティブなプロトタイプ

4. テスト

• 実際のユーザーでテストする(デザイナーではなく)
• 5人のユーザーが問題の85%を明らかにする
• 意見だけでなく、行動を観察する
• 調査結果に基づいて繰り返す

重要な原則: デザインプロセスは反復的です。複数のサイクルを実行し、毎回学習に基づいてデザインを改善します。

一般的な間違い

間違い	なぜ失敗するか	修正
シグニファイアなし	ユーザーは機能を見つけられない	すべてのインタラクティブ要素に視覚的な手がかりを追加
フィードバックなし	ユーザーはアクションが機能したかどうかを知らない	0.1秒以内にすべてのアクションに応答
ユーザーを責める	デザインの欠陥を無視	すべての「ユーザーエラー」のデザイン上の原因を探す
機能の肥大化	複雑性が圧倒する	コンストレイント、段階的な開示を適用
不一貫性	メンタルモデルを壊す	同じアクション = すべての場所で同じ結果
コンテキストを無視	理想的な条件に設計	実際の使用環境を観察

クイック診断

すべてのデザインを監査します:

質問	イエスでない場合	アクション
ユーザーは何をすべきかを理解できるか?	発見可能性が悪い	シグニファイアを追加、アフォーダンスを改善
ユーザーは何が起きたかを理解できるか?	評価のガルフが広い	フィードバックを追加、システム状態を表示
ユーザーはエラーから回復できるか?	エラー耐性がない	取り消し、確認、明確なメッセージを追加
コントロールレイアウトが出力レイアウトと一致するか?	マッピングが悪い	コントロールを再編成して空間的なレイアウトと一致させる
不可能/無関連なオプションは隠れているか?	コンストレイントが足りない	無効なオプションを無効化、非表示、または削除

参考ファイル

• two-gulfs.md: ガルフ分析演習、橋渡し戦略
• affordances.md: アフォーダンスタイプ、デザインパターン
• signifiers.md: シグニファイアパターン、例、ベストプラクティス
• mappings.md: 自然なマッピング分析、空間的レイアウト
• constraints.md: コンストレイントタイプ、デジタル実装
• feedback.md: フィードバックパターン、タイミング、モダリティ
• conceptual-models.md: モデルデザイン、メタファー、メンタルモデル
• human-error.md: エラーのタイプ、防止、復旧
• seven-stages.md: ステージ分析、評価ツール
• case-studies.md: ドアハンドル、サーモスタット、デジタル製品

さらに詳しく

このスキルはDon Normanの基礎的なデザイン原則に基づいています。完全なフレームワークについては:

• "The Design of Everyday Things" Don Norman著(改訂・拡大版、2013年)
• "Emotional Design" Don Norman著(デザインと感情)

著者について

Don Norman, PhD はNielsen Norman Groupの共同創業者で、UC San DiegoのThe Design Labのディレクターです。1990年代にAppleで「ユーザーエクスペリエンス」という用語を作り出しました。The Design of Everyday Things(元々1988年に「The Psychology of Everyday Things」として出版)は、これまでに書かれた最も影響力あるデザイン書と見なされており、世界中のほぼすべてのデザインプログラムで必読とされています。ノーマンはAppleの最先端技術の副社長を務めており、Northwestern、UC San Diego、KAIST(韓国)で教授を務めています。