A7.08.1System image设计
系统映像由界面外观、文档、错误提示与他人转述共同构成
别名: system image · 三模型框架 · design model
概念解释
设计者脑子里的构想叫设计模型（design model），用户实际持有的理解叫用户模型，两者从不直接接触，中间隔着系统映像（system image）——用户能接触到的一切外部证据的总和：界面本身的外观与交互方式，帮助文档，错误提示的措辞，安装包与营销页面上的说法，甚至身边人演示时说的"你这样点就行"。这一整套东西才是系统映像，不是单指用户正在盯着的那个屏幕。
用户构建自己的模型时，用的原料只有系统映像，没有别的渠道能绕过它直接触及设计者的构想。
机制
系统映像之所以是拼起来的，是因为它从来不是同一个人、同一个时刻做出来的东西：界面视觉与交互由设计团队定，帮助文档往往由另一批人写，错误提示的文案可能是工程师顺手加的，营销页面又是另一条产线的产物，用户听到的转述更是完全在产品团队控制之外发生的。这些碎片各自独立产生，却要在用户脑子里被当成同一个系统的证据拼在一起——系统映像的"整体性"是用户构建模型时强加上去的，不是它本来就有的属性。
正因为这些碎片来自不同来源、不同时间、不同人手，它们不会自动保持一致，而用户没有能力也没有理由去区分"这句话来自官方文档，那句来自朋友的经验之谈，权重应该不一样"——一旦某个碎片进入了用户的视野，它就成为构建模型的原料之一，不管它出自谁手、可靠不可靠。
边界
- 只有真正抵达用户、被用户接触到的部分才算数。设计者内部的构想文档、没有对外发布的方案、从未上线的功能说明，即使精确反映了设计意图，只要用户接触不到，就不构成系统映像的一部分，对用户模型没有任何直接影响。
- 系统映像的边界会随产品生命周期移动：一次改版可能同时留下旧版本的截图、旧文档的缓存页面、老用户对旧行为的转述，这些"过期"的碎片依然在被新用户或老用户接触到，依然算作当下系统映像的一部分，即使它们描述的已经不是当前系统的真实行为。
- 这条只讲系统映像由什么构成，不涉及这些碎片之间是否一致、谁的权重更大——那是另外两层问题。
怎么落地
- 把系统映像当作一份需要主动管理的清单，而不是"界面设计好了就完事"：逐一列出会被用户接触到的每一类碎片——首屏引导、常驻状态提示、帮助中心文章、错误文案、应用商店描述、客服话术模板——确认它们都被纳入设计与审核范围，而不是各自归不同团队维护、互不知会。
- 对营销页面、安装引导这类容易被设计团队忽略的边缘触点，专门做一次审查，确认它们对系统行为的描述与当前实现一致，而不是沿用几个版本前的旧说法。
- 验证办法：找一个从没接触过产品的人，把能收集到的全部碎片（不只是界面本身）摆在TA面前，让TA说出对这个系统的理解；再拿这份理解去对照实际行为，偏差点几乎都能追溯到某一份具体碎片的问题，而不是笼统的"用户没搞懂"。