在产品经理的日常工作里，设计系统往往被视为代码仓库的延伸，却忽略了它在用户心智模型中的角色。设计系统并非仅是排版与色板的集合，它是用户与产品交互时“默认的思维路径”。如果组件与心智模型脱节，用户就会在使用时产生二次认知成本，导致体验碎片化。

先说说什么是心智模型。心理学家称之为「用户对某一系统工作方式的内部表征」。当他们看到一个按钮时，期望得到的反馈、行为顺序以及可预见的结果都已在心里预先编织好。如果设计系统中同一功能的组件因样式不同、交互不同而产生不一致，用户就会被迫重新学习，体验即被削弱。

以 Shopify 的 Polaris 为例。Polaris 自 2018 年发布以来，已维护 200+ 组件，所有按钮、表单、对话框等都遵循同一交互规则：点击即立即反馈、错误状态一目了然。Polaris 的文档里更专门开设「核心交互」章节，明确说明按钮在不同状态下的视觉提示与行为逻辑，保证无论是前端开发者还是内容编辑者都在同一基准上进行设计。

同理，Atlassian Design System（ADS）自 2017 年起，面向 Jira、Confluence 等产品提供统一组件库。ADS 在「一致性原则」里强调「同一概念即同一交互」。这不仅让跨团队协作更高效，也让新加入的 PM 能在几分钟内理解各组件的行为预期。ADS 的“组件卡片”展示中，还附带了使用场景与可预期结果，让用户的心智模型更快速对齐。

再来看看 IBM Carbon。Carbon 自 2015 年发布，凭借强大的可访问性与一致性，成为企业级设计系统的标杆。Carbon 的文档里详细列出了「交互层级」与「视觉语言」的对应表，帮助开发者在实现时不偏离原始心智模型。Carbon 通过「设计令牌」将颜色、间距、字体统一抽象，任何偏离都会在 CI 阶段被检测到。

如果你想让设计系统真正服务于心智模型，建议按以下步骤操作：

1. 先梳理核心交互模型：列举最常见的业务场景，明确每一步的预期用户行为。
2. 在设计系统文档中创建「核心交互」章节，记录每个组件在各种状态下的行为与视觉反馈。
3. 在组件迭代时，设置自动化回归测试，验证新版本是否仍符合核心交互规范。
4. 定期邀请 PM 与 UX 进行「心智模型对齐」评审，确保产品线与设计系统保持同步。

常见的偏差往往来自三个方面：①文档不完整，导致实现方自由度过大；②组件版本太多，出现功能重叠；③缺乏跨团队沟通，导致同一交互在不同产品中被拆解。对这些问题，建议使用 Storybook 结合 Storyshots 进行视觉回归，并在 Lerna 里维持组件版本控制。

回顾亚马逊的按钮迁移案例：在 2019 年，亚马逊将旧的「Add to Cart」按钮从多色变为统一深蓝色，并统一了点击反馈动画。此举虽然看似小改动，却显著提升了结账过程的流畅度，用户对「加入购物车」的心智模型得到强化，复购率上升 3%。

总结来说，设计系统与心智模型的结合是一个双向的约束：系统必须提供可复用的、行为一致的组件；用户则在使用过程中不断校准心智模型。你是否已经在自己的产品中看到，因设计系统与心智模型不一致而导致的使用痛点？如果还没有，那是不是该给自己的设计系统一个“思维定标”的机会？