系统不能假定用户按预设流程行事
别名: 预设流程 · 流程刚性 · 例外设计 · 脏数据
概念解释
预设向导、线性状态机和强顺序表单只描述一种可能路径。真实用户会中断、跳过、重复、并行处理、改变顺序或由他人接手。系统若把预设流程当作必然条件，会在例外时锁死任务或产生脏数据。这一条是前两条道理落到工程实现上的结果：如果计划只是资源、实际行动依赖现场调整，那么把预设流程直接写死成系统里唯一被允许的路径，就是在用工程实现去否定这套理论已经说明的现实，冲突迟早会在真实使用中爆发出来。
机制
预设流程之所以会和现实脱节，是因为它通常是从"理想情况下这件事应该怎么做"这个角度推导出来的，推导过程里天然会遗漏几类真实存在的情况：多个角色需要并行处理同一件事、某个环节要等待外部信息到位才能继续、一次操作被撤销之后系统应该回到什么状态、任务进行到一半被另一个人接手该怎么衔接。当真实用户的行为恰好落进这些没有被考虑到的情况——从流程中间直接进入、稍后才补交缺失的材料、同事代为填写某一部分——系统里往往根本不存在与之对应的状态、权限或者校验逻辑，用户要么被卡住动弹不得，要么被迫绕开系统本身用别的方式先把事情做完，再回头把结果生硬地塞回系统里，后一种情况正是"脏数据"的来源：数据本身不假，但它记录的不是事情实际发生的顺序，而是被系统流程反向拗成的、看起来合规的假象。这种刚性限制的代价，最终不是让例外消失，而是把处理例外的真实过程逼到了系统之外、逼到了线下，系统里留下的记录和真实发生的事情之间出现了一道系统本身完全看不见的裂缝。
边界
不假定线性不等于允许任意顺序、放弃一切约束。安全相关的操作顺序、法律上必须履行的签署环节、真正存在先后依赖的数据关系，仍然需要硬约束去强制执行，这些约束本身没有问题；真正的问题在于约束呈现给用户的方式——一个硬约束应该显式说明为什么存在这道限制、满足什么条件可以解除、如果暂时无法满足又有什么替代路径，而不是只单纯显示一个"不可点击"的按钮，让用户自己去猜到底是权限不够、前置条件没满足，还是这一步本身就设计错了。有些流程也确实必须按特定角色的固定顺序完成，这种情况下系统需要能够区分"这一步现在还不被允许，因为前置条件没有满足"和"这一步操作本身有错误"这两种性质完全不同的状态，不能把它们混为一谈，用同一种报错方式呈现给用户。
怎么落地
- 为核心流程建立更丰富的状态模型，除了"进行中"和"完成"，还要覆盖前置、可选、并行、等待、取消、重复和交接这几类真实会出现的状态。
- 允许保存部分完成的进度、稍后继续、以及由其他人接手未完成的部分，并且在交接过程中保留清楚的责任归属和时间线记录。
- 每一个硬约束旁边都写明具体原因、解除这个约束需要满足什么条件，以及当下如果暂时无法满足，有没有可用的替代路径，不要只呈现一个不能点的按钮。
- 验证办法：用真实发生过的中断场景和异常情况写成测试剧本去走一遍流程，专门寻找流程死锁——用户走到某一步之后既不能前进也不能后退——和缺失状态——用户实际所处的情况在系统里根本没有对应的选项可选。