この記事の要点（UIXHERO視点） UIXHEROでは、メンタルモデルを「ユーザーが頭の中に持つ理解」、概念モデルを「デザイナーが意図した仕組み」と定義し区別する。 UIの使いにくさの多くは、メンタルモデルと概念モデルの「ズレ」から生じる。デザイナーの仕事は、このズレを埋めることである。
導入：「なぜこう動くと思ったのに、違う動きをするのか」
「戻るボタンを押したら、前の画面に戻ると思った」 「ドラッグしたら移動すると思ったのに、コピーされた」 「保存ボタンを押せば終わりだと思ったのに、さらに確認画面が出た」
こんな経験はないでしょうか。これらはすべて、ユーザーの期待とシステムの動作がズレている状態です。
このズレは、ユーザーの「こう動くはず」というメンタルモデルと、デザイナーが設計した概念モデルの不一致から生じます。
UIの使いにくさの大部分は、メンタルモデルと概念モデルのズレである。
メンタルモデルと概念モデルの違い（定義）
メンタルモデルは「ユーザーの理解」であり、概念モデルは「設計者の意図」である。
| 項目 | メンタルモデル | 概念モデル |
|---|---|---|
| 定義 | ユーザーが頭の中に持つ、システムの仕組みに関する理解 | デザイナーが意図した、システムの仕組みの設計 |
| 主体 | ユーザー | デザイナー/開発者 |
| 形成 | 過去の経験、学習、推測から自然に形成 | 意図的に設計される |
| 性質 | 不完全、個人差がある、変化する | 明示的、一貫性を目指す |
| 問い | 「ユーザーはどう理解しているか？」 | 「どう動くべきか設計したか？」 |
語源と背景
メンタルモデルは、認知心理学者ケネス・クレイクが1943年に提唱した概念です。人間は外界の「小さな模型」を頭の中に作り、それを使って予測や推論を行うという考え方です。
概念モデルは、ドン・ノーマンが『誰のためのデザイン？』（1988年）で体系化しました。概念モデルには、画面遷移、オブジェクトの関係、操作ルール、状態変化の前提などが含まれます。
ノーマンは、デザイナーの持つ「デザインモデル」、ユーザーの持つ「ユーザーモデル（メンタルモデル）」、そして製品が伝える「システムイメージ」の三角形を整理しました。ズレを埋める実務上の主戦場は、この「システムイメージ」の設計です。
研究からの引用: 「デザイナーはシステムイメージを通じて概念モデルをユーザーに伝える。ユーザーはシステムイメージからメンタルモデルを形成する。この間のコミュニケーションが成功するかどうかが、使いやすさを決める。」（Don Norman）
なぜ重要なのか
1. ズレが「使いにくさ」の正体
| メンタルモデル | 概念モデル | 結果 |
|---|---|---|
| 「戻る」= 前の画面 | 「戻る」= 前のステップ | 期待した画面に戻れずイライラ |
| ファイルは1箇所に存在 | ファイルはクラウドで同期 | 「消したはずなのにまだある」と混乱 |
| 「保存」で終わり | 「保存」の後に確認が必要 | 無駄なステップに感じる |
ユーザーが「使いにくい」と感じるとき、その原因の多くはこの「ズレ」です。
2. メンタルモデルは変えにくい
メンタルモデルは過去の経験から形成されるため、簡単には変わりません。
- PCで長年Windowsを使っていた人は、Macでも同じ操作を期待する
- 実店舗の買い物経験がある人は、ECでも同じ流れを期待する
- 他社の類似アプリを使っていた人は、同じUIパターンを期待する
ユーザーのメンタルモデルを変えようとするより、概念モデルを合わせる方が現実的です。
具体例・ケース比較
ケース1：ファイル管理
| 観点 | メンタルモデル（ユーザーの理解） | 概念モデル（設計の意図） |
|---|---|---|
| フォルダ | 「実際の書類棚と同じ。1つのファイルは1つの場所にある」 | 「フォルダはビュー。タグやエイリアスで複数箇所に表示可能」 |
| 削除 | 「ゴミ箱に入れたら消える」 | 「30日後に自動削除。その前は復元可能」 |
| ズレの影響 | 「同じファイルが2箇所にある。どっちが本物？」 | — |
対策: システムイメージで概念モデルを明示する（「このファイルはエイリアスです」などの表示）
ケース2：ECサイトのカート
| 観点 | メンタルモデル（ユーザーの理解） | 概念モデル（設計の意図） |
|---|---|---|
| カートの保持 | 「買い物かごに入れたら、しばらくは残っている」 | 「在庫確保のため、30分で自動削除」 |
| 価格 | 「カートに入れた時点の価格で買える」 | 「購入確定時の価格が適用される」 |
| ズレの影響 | 「さっきカートに入れたのに消えてる！」「価格が変わってる！」 | — |
対策: 事前にルールを明示する（「カート保持は30分」「価格は変動する可能性があります」）
ケース3：アプリの「戻る」ボタン
| 観点 | メンタルモデル（ユーザーの理解） | 概念モデル（設計の意図） |
|---|---|---|
| 戻る | 「直前の画面に戻る」 | 「直前のステップに戻る（入力内容はリセット）」 |
| キャンセル | 「操作を中止して元に戻る」 | 「保存せずに閉じる（途中入力は破棄）」 |
| ズレの影響 | 「戻ったら入力が消えた！」 | — |
対策: 破棄される内容がある場合は確認ダイアログを出す、または自動保存する
実務でなぜ区別すべきか
UIXHEROがこの2つを厳密に区別する理由は3つあります。
1. 問題の所在を特定できる
「使いにくい」というフィードバックを受けたとき、原因は2つ考えられます：
- 概念モデルの問題: 設計自体が不適切
- システムイメージの問題: 設計は正しいが、伝え方が悪い
メンタルモデルを理解することで、どちらの問題かを特定できます。
2. ユーザー調査の焦点が定まる
| 知りたいこと | 調査手法 |
|---|---|
| ユーザーのメンタルモデル | インタビュー、カードソート、思考発話 |
| 概念モデルとのズレ | ユーザビリティテスト、観察 |
「ユーザーはどう理解しているか」を知ることが、設計改善の第一歩です。
3. 新規性の高い製品で特に重要
既存カテゴリの製品は、ユーザーがすでにメンタルモデルを持っています。しかし、新しいカテゴリの製品（最初のスマートフォン、最初のAIアシスタントなど）では、メンタルモデルを「形成させる」設計が必要です。
この場合、システムイメージを通じて概念モデルを明確に伝えることが、採用の成否を分けます。
よくある質問 (FAQ)
Q1. メンタルモデルはどうやって調べますか？
以下の手法が有効です：
- インタビュー: 「〇〇はどういう仕組みだと思いますか？」と直接聞く
- 思考発話: 操作中に考えていることを声に出してもらう
- カードソート: 概念の分類方法からメンタルモデルを推測する
- 比喩を聞く: 「何に似ていますか？」と聞く（「銀行口座みたい」など）
Q2. メンタルモデルとユーザーの期待は同じですか？
近いですが、少し異なります。
- メンタルモデル: システムの仕組みに関する理解（構造）
- 期待: 特定の操作の結果に関する予測（行動）
メンタルモデルが期待を生み出しますが、期待はより具体的で状況依存的です。
Q3. 概念モデルはどこに文書化しますか？
以下の形で文書化できます：
- 概念モデル図: システムの構成要素と関係を視覚化
- ユーザーストーリー: 「ユーザーとして〜したい、〜のために」
- オブジェクト指向UI設計: オブジェクトとアクションの関係を定義
設計チーム全員が同じ概念モデルを共有することが重要です。
関連リンク
UIXHEROの関連記事
- ドン・ノーマンのデザイン原則 — 概念モデルを含む設計原則
- システムイメージの設計 — 概念モデルを伝える方法
- カードソート — メンタルモデルを調べる手法
- フィードバックとフィードフォワードの違い — ズレを埋める設計手法
用語集
メンタルモデルは「ユーザーが思う『こう動くはず』」である。 概念モデルは「デザイナーが決めた『こう動く』」である。 良いUIとは、この2つが一致しているUIである。
まとめ
- メンタルモデル: ユーザーが頭の中に持つ、システムの仕組みへの理解（不完全・個人差あり）
- 概念モデル: デザイナーが意図した、システムの仕組みの設計（明示的・一貫性あり）
- 使い分け: メンタルモデルを調査し、概念モデルとのズレを特定する。ズレを埋めるには、概念モデルを変えるか、システムイメージで伝え方を改善する。
「なぜこう動くと思ったのに、違う動きをするのか」——その問いの答えが、メンタルモデルと概念モデルの関係にある。このズレを見つけ、埋めることが、デザイナーの仕事である。
