THINKING · №05 · 认知设计概念

概念模型Conceptual Models

用户以为系统是怎么工作的页面之间的关系要一致不要把站点地图叫用户心智模型

先看什么时候调用

概念模型是产品用来解释“系统里有什么、它们如何关联、操作会导致什么”的一致规则；界面通过可见线索把它传达给用户。

触发条件: 导航、对象关系和状态变化彼此矛盾；用户反复问“它保存在哪里”“返回会不会丢”“这个和那个是什么关系”。
改变什么: 明确系统里的对象、动作、状态和关系，并让 URL、命名、导航与反馈持续表达同一套规则。
适用边界: 概念模型不是站点地图、数据表结构或设计师脑内结构；用户会带着既有经验形成自己的心理模型，需要研究而不能代写。
如何验证: 让用户解释系统如何工作、预测下一步结果并完成跨页面任务；记录预测错误和恢复路径，而不是只问“是否理解”。

直接发给 agent

Define and audit the conceptual model for this product.

Describe the core objects, actions, states, and relationships in plain language. Then trace how navigation, URLs, labels, controls, and feedback communicate that model. Flag any place where the interface implies a different rule. Propose the smallest repair and a task that tests whether users can predict the result before acting.

来源与证据

Norman 将设计者的概念模型、系统呈现出的形象与用户形成的心理模型区分开来。该框架用于解释用户为何会根据界面线索形成正确或错误预期。

深入理解

让页面说同一种世界观

用户不会先读产品架构图。他们会从标签、URL、按钮和操作结果里推断系统是怎样工作的。如果列表说“草稿”，编辑页却叫“未发布文章”，返回后内容又消失，用户形成的规则就会不断被推翻。

概念模型不是页面清单

站点地图描述页面组织，数据模型描述系统存储，概念模型则解释用户应该如何理解对象、动作和状态。三者可以相关，但不能混为一谈。

个人博客里，“文章”是核心对象，“草稿—已发布”是状态，“作者编辑、访客阅读”是角色关系。公开页面和后台可以采用不同技术架构，但不应对同一篇文章给出矛盾的状态解释。

最好的检查是预测

在点击前问用户：“你觉得接下来会发生什么？内容会保存在哪里？返回后还在吗？”预测错误比“你觉得清楚吗”更能暴露模型冲突。