做 ToB 页面时，一个很容易被忽略的问题是：你以为页面只是给当前操作者用的，但很多时候，它同时也是给监管者、复核者、管理者看的。
这个视角一变，很多页面设计判断都会跟着变。
操作视角和监管视角完全不是一回事
如果只从操作者视角设计页面，通常会优先考虑这些事：
- 操作步骤是不是顺手
- 输入路径是不是短
- 页面是否干净聚焦
- 当前任务是否能高效完成
这些当然都重要。但一旦业务里存在监管要求，页面就不能只服务“当前动作”，还要服务“后续解释”。
比如答题场景里，用户关心的是怎么完成答题；监管者关心的是这个过程是否真实、是否完整、有没有异常。审批场景里，提交者关心的是怎么发起；管理者关心的是这个申请处于哪个状态、依据是否充分、是谁处理的。培训场景里，参与者关心的是怎么学；组织者关心的是谁参加了、谁没完成、过程有没有留痕。
这时页面承载的已经不是单一操作，而是一个业务事实的表达。
为什么有些页面不能过度“极简”
现在很多设计趋势都喜欢极简，喜欢把信息压缩，把界面做得更干净。但在 ToB 场景里，极简有时并不一定是好事。
因为有些信息不是“可有可无的辅助信息”，而是业务判断所必需的依据。
比如：
- 当前状态是什么
- 上一步是谁处理的
- 有没有录制中
- 是否存在异常提示
- 数据最后更新时间是什么
- 当前结果是系统判断还是人工确认
如果这些信息都为了视觉简洁被藏得太深，页面确实更干净了，但业务会变得更难理解，后续监管也会更困难。
所以我现在看 ToB 页面时，会刻意去判断：这个页面到底是在服务操作，还是也在服务理解和监管。很多时候答案不是二选一，而是同时存在。
页面不是只承载“动作”，也承载“解释权”
这一点是我后来慢慢意识到的。
很多业务场景里，页面不只是让人完成一个动作，还承担了一个很重要的职责：让系统在事后能够解释自己。
比如一个异常记录页面，如果用户只能看到“失败”，但看不到失败原因、失败时间、对应环节、处理建议，那这个页面对操作来说也许够了，但对业务来说远远不够。
因为业务最终不是只关心“事情发生了”，而是关心“为什么发生”“能不能证明”“谁来处理”。
所以我现在做页面，会更在意页面有没有把必要的上下文一起呈现出来。不是每一屏都要塞满信息，而是要保证关键事实在关键场景里能被看到。
为什么这会影响信息层级设计
一旦你意识到页面同时服务两类角色，信息层级就会发生变化。
原来你可能会把结果放在最前面，把过程信息折叠到详情里。但如果监管需求很强，你就会发现过程本身也很重要。原来你可能只想突出主操作按钮，但如果页面也承担状态确认功能，那状态信息的可见性就必须提升。原来你可能觉得“附加说明”不重要，但一旦涉及复核和追责，它反而会变成核心信息之一。
这也是为什么 ToB 页面设计，常常不能完全照搬消费类产品的思路。因为它要解决的问题本来就不一样。
结语
很多 ToB 页面不只是给“当前操作的人”看的，也是给“后续判断的人”看的。
当你从这个角度重新看页面时，会发现很多原来觉得理所当然的设计判断，其实都需要重来。信息不只是为了操作效率存在的，也是在为业务事实提供支撑。
对我来说，这个认知很重要。它让我在做页面时，不再只问“好不好用”，也会多问一句：这个页面能不能把业务说清楚。