刚开始做业务系统的时候，我也会自然地把注意力放在页面本身。
页面怎么排版，表单怎么拆，表格怎么做，按钮放哪里更顺手，交互是不是清晰——这些都很重要，而且也确实是用户第一眼会看到的部分。但做得越久，我越清楚地意识到，真正决定一个业务系统能不能成立的，往往不是页面，而是页面背后那套关系能不能跑通。
这里的“关系”包括很多东西：角色之间的关系、权限之间的关系、状态流转之间的关系、数据归属之间的关系、业务环节之间的关系。页面只是这些东西的外显结果。一个页面可以做得很完整，但如果它背后的业务结构没有理顺，整个系统依然会非常脆弱。
页面只是业务结构的投影
很多时候，一个后台页面看起来只是“增删改查”，但一旦进入真实业务，问题就不会这么简单。
比如一个培训管理页面，表面上只是录入培训计划、关联人员、查看结果。可一旦往下走，就会碰到很多具体问题：
- 谁可以创建，谁可以编辑，谁只能查看
- 培训计划发布之后还能不能改
- 已经有人参与后，哪些字段必须冻结
- 记录是按组织维度看，还是按个人维度看
- 异常状态怎么处理，补录算不算正式记录
- 统计口径是按场次、按人员，还是按完成状态
这些东西如果没提前想清楚，前端做出来的页面只能算一个外壳。真正上线以后，业务方会不断提新需求，而你会发现每一个需求都像是在“补洞”。
真正的难点是状态，而不是组件
我现在越来越觉得，业务系统里最难的东西不是组件，而是状态。
组件是可见的，也相对好拆。状态不一样，状态是跨页面、跨角色、跨流程的。一个状态定义不清，后面所有页面都会受到影响。
尤其是那种带审批、带留痕、带监管要求的系统，状态不是“显示不同文案”那么简单，而是直接决定一个动作能不能发生、一个数据能不能被改、一个结果能不能被认定有效。
这时候前端如果只停留在页面层思维，很容易写着写着就乱掉。因为你会发现自己在不同页面里重复判断类似的业务条件，而且这些判断还不一定一致。到最后系统不是不能用，而是很难维护。
业务系统开发，本质上是在做信息组织
我后面做项目时，会刻意先不急着画页面，而是先把几件事写清楚：
第一，系统里有哪些核心对象。第二，这些对象之间是什么关系。第三，它们各自有哪些状态。第四，状态怎么流转。第五，不同角色在不同状态下能做什么。
这些东西一旦梳理清楚，页面反而会变得容易很多。因为页面不再是“我想怎么做”，而是“系统现在需要怎样被表达”。
换句话说，页面设计不应该从视觉开始，而应该从业务结构开始。视觉和交互是必要的，但它们应该建立在正确的业务表达上，而不是反过来主导业务。
为什么我越来越重视“可维护性”
很多业务系统刚上线的时候，看起来都还能用。真正拉开差距的是半年之后。
有些系统做了一个月就开始变形，因为每次加需求都只能在原来逻辑上继续堆。还有些系统虽然功能不花哨，但因为结构清楚，后来不管怎么加模块都还能稳住。
我现在会把“后面还能不能接着改”看得很重。因为真实项目不是一次性交付，尤其是 ToB 场景，业务变化几乎是必然的。前期多花一点时间把状态和边界讲清楚，后期会省下大量返工成本。
结语
页面当然重要，但页面只是业务系统里最容易被看见的那一层。
真正决定系统质量的，是你有没有把角色、流程、权限、状态和数据组织成一个合理的结构。把这些想清楚之后，页面只是落地手段；如果这些没想清楚，页面再漂亮，也只是一个临时壳子。
这也是我现在做业务系统时越来越明确的一个判断：真正难的，从来不是把页面做出来，而是把系统真正做成立。