我现在做 ToB 页面，已经越来越少从“页面长什么样”开始想了。
不是说视觉不重要，而是 ToB 场景里，页面设计如果只从视觉或组件层开始，最后很容易做出一个“看起来完整，但业务并不成立”的东西。尤其是涉及培训、考试、管理、审批、留痕、监管这类场景时，页面本身其实只是业务结构的一层外显。
所以我现在更习惯从业务约束出发，再一路往下走到交互和界面表达。
第一步：先看这个页面到底承载什么业务职责
ToB 页面和很多消费类页面的一个明显差别，是它们往往不只是“让用户完成一个动作”，而是在承载一个业务环节。
比如一个答题页面，看起来只是“展示题目 + 输入答案 + 提交”，但如果放到真实业务里，它可能同时承担这些职责：
- 告诉用户当前在做什么
- 告诉系统当前是否在录制
- 告诉业务这个过程是否合规
- 记录用户的作答路径
- 给后台留下后续监管依据
- 在必要时反馈结果或异常状态
这时候页面就不再只是一个操作容器，而是一个业务事实的展示层。如果一开始没有把这个页面承担的职责想清楚，后面交互再怎么细调，也只是局部优化。
第二步：明确有哪些约束是不能被页面“美化掉”的
ToB 页面设计里，我很在意一个问题：哪些信息是业务必须被看见的，而不是可以为了“简洁”被弱化掉的。
比如：
- 当前状态是不是录制中
- 当前动作是否受监管
- 数据有没有成功提交
- 是否存在异常提醒
- 当前结果是临时结果还是最终结果
- 这个环节能不能返回、能不能修改
这些东西在很多业务里都不是附加信息，而是核心信息。页面如果为了看起来清爽，把这些信息藏得太深，最后反而会让用户更不确定，也让业务更难判断。
所以我在做信息层级时，通常不会先问“页面能不能更干净”，而是先问“哪些信息必须明确存在”。
第三步：把业务流程翻译成用户可理解的状态
很多 ToB 页面难用，不是因为功能少，而是因为状态表达不清楚。
业务流程在系统里通常是连续的，但用户看到的是一个个页面片段。如果页面没有把当前所处阶段、系统正在做什么、用户接下来该做什么表达清楚，用户就很容易迷失。
所以我会特别关注几个问题：
- 用户当前处在哪个阶段
- 系统当前正在处理什么
- 用户能执行哪些动作
- 哪些动作是被限制的
- 当前结果是不是已经生效
- 如果出错，用户下一步该怎么办
这些问题其实都属于“状态可理解性”。页面如果能把这些状态表达清楚，交互就会稳定很多。
第四步：平衡严肃性和易用性
我做过一些偏培训、考试、监管的页面，这类场景有一个特别明显的特点：页面既不能太轻，也不能太重。
太轻，会显得不够严肃，用户可能意识不到这个动作的正式性；太重，又会让页面变得压迫，影响操作效率。
所以我会比较在意一种平衡：页面要让用户明确感受到这是一个正式业务环节，但又不能让所有提示都变成干扰。
比如哪些信息需要一直可见，哪些信息可以分层呈现；哪些反馈应该即时出现，哪些反馈适合在阶段结束后统一展示；哪些控件必须突出，哪些信息更适合做辅助说明。这些取舍，决定了页面最终是不是既严肃又可用。
第五步：交互不是为了炫，而是为了让业务更稳定
我现在越来越少追求那种“很有设计感但不确定是否适合业务”的交互。
ToB 页面里的交互，最终还是要服务业务稳定性。也就是说，它不只是要让人觉得顺，还要让人不容易误操作、不容易误解、不容易漏掉关键状态。
从这个角度看，好的 ToB 交互很多时候不是更花，而是更稳。它知道哪里应该明确，哪里应该克制，哪里应该强化反馈，哪里应该减少干扰。
结语
对我来说，ToB 页面设计不是从视觉开始的，而是从业务约束开始的。
先看页面承载什么职责，再看哪些约束不能被弱化，再把业务流程翻译成用户能理解的状态，最后才是交互和界面的具体表达。这条路径会比直接画页面慢一点，但它更容易做出真正能进入业务场景、而不是只适合展示的页面。
也正因为这样，我现在做 ToB 页面时，越来越把自己当成是在做“业务表达”，而不只是“界面设计”。