跨屏幕的不一致会叠加复杂度，超出单屏幕内部复杂度的简单加总
别名: consistency debt · 一致性负债 · 跨屏认知成本
概念解释
如果一款产品的每个屏幕单独看都不复杂，但屏幕与屏幕之间在术语、导航方式、控件含义上互不一致，用户要承担的总负荷会比"把每个屏幕的复杂度加起来"更高。多出来的这部分负荷不来自任何一个屏幕本身，而来自屏幕之间的不一致：用户在切换情境时不能直接沿用刚学会的操作模式，要重新判断这一屏和上一屏用的是不是同一套规则。这解释了为什么整体产品的复杂度不能靠给每个屏幕分别打分再求和来估计。
机制
用户理解一个屏幕，很大程度上依赖把当前屏幕和之前见过的屏幕做类比——同样的图标应该表示同样的操作，同样位置的控件应该有同样的行为。这种类比之所以省力，是因为它把"重新学习这一屏怎么用"替换成了"确认这一屏和之前学的是不是一样"，后者远比前者省认知资源。屏幕之间一旦出现不一致——同一个图标在一屏里表示"删除"、在另一屏里表示"归档"，同一个手势在不同页面触发不同操作——这种类比会失效甚至产生误导：用户不仅要重新学习当前屏幕的规则，还要主动压制刚从上一屏学到的、此刻不适用的规则，这份额外的压制工作是纯粹由不一致产生的，不会出现在任何一个屏幕单独的复杂度评估里，只有跨屏幕一起看才能测出来。
怎么研究
常见做法是让被试依次使用同一产品里术语、导航结构或控件含义存在差异的多个屏幕，完成一个跨屏幕的连续任务，比较这种"不一致组合"与一套内部完全一致的屏幕组合之间，总完成时间、总错误数以及"用上一屏的规则去操作当前屏幕"这类特有错误的发生率。
常见自变量：屏幕之间在术语、导航、控件含义上的一致程度、涉及的屏幕数量。 常见因变量：完成跨屏幕任务的总耗时与总错误数、特定的"规则误用"错误发生率。
这套比较在人机交互里常用于评估大型产品或多团队协作产品的整体可用性——单个页面的可用性测试可能都通过，但把多个页面串起来走一遍流程时，暴露出的问题往往是页面间的规则不一致，而不是任何单页本身的缺陷。
方法论注意点：这条效应必须通过跨屏幕的连续任务才能测出来，只对单个屏幕分别做可用性测试无法发现，需要专门设计涵盖多个屏幕切换的测试流程。
边界
- 如果用户在两个屏幕之间的使用间隔很长（比如相隔几天，中间发生了大量无关的其他活动），跨屏幕的类比本身就不太会发生，不一致造成的额外负荷也会随之减弱。
- 这条讲的是不一致本身产生的叠加负荷，不涉及应该用什么规范或流程去维持一致性，那属于团队协作与落地层面的具体做法。
- 如果不一致只出现在用户几乎不会同时接触的两个屏幕之间（使用场景完全不重叠），实际发生类比冲突的机会很少，这条效应的影响会明显减弱。
怎么落地
- 评估一个多屏幕产品的复杂度时，不要只对每个屏幕分别做可用性测试后简单相加，专门设计一条跨越多个屏幕的连续任务，观察用户在屏幕切换处是否出现额外的迟疑或错误。
- 对于同一个图标、同一个手势、同一个术语，在产品内部的不同屏幕上保持完全一致的含义；如果确实需要在某个屏幕上赋予不同含义，用明显不同的视觉呈现避免被误认成同一个规则。
- 验证办法：统计用户在跨屏幕任务中"用上一屏的规则操作当前屏幕"这类特定错误的发生位置和频率；如果这类错误集中出现在术语或控件含义不一致的屏幕切换点，说明当前产品的跨屏幕一致性存在实际的负荷代价，需要优先修正。