在 UI 之前设计审批矩阵：先绘制规则再画界面

没有明确矩阵时，界面为何会失败

干净的界面可能掩盖混乱的流程。如果审批逻辑没有先被定义清楚，人们可能会看到“通过”和“拒绝”按钮，却不知道应该由谁操作、何时操作或接下来会发生什么。

这种困惑在真实工作场景中很快就会显现。有人提交请求，它进入应用，首个问题就是：“这应该发给经理、财务，还是两者都要？”界面看着完成了，但决策路径却缺失。

之所以会这样，是因为界面让规则看起来比实际更简单。表单可以显示状态、评论和操作按钮，但不能猜出背后的真实审批矩阵。如果业务有金额限额、部门规则或临时代替人，一旦这些情况出现，UI 就会开始出问题。

通常只需一个例外就会把工作推到应用之外。也许通常审批会发给部门负责人，但在紧急情况下、超出某个金额，或审批人在休假时则另有安排。如果这些情况从未被映射清楚，人们就会退回到邮件、聊天或电子表格中处理。

随后更大的问题出现：每个团队开始按自己的方式应用规则。运营按一种方式发送请求，财务按另一种方式发送，支持对异常的处理又与人力不同。应用变成了一个共享的界面，但决策不一致，流程并未共享。

预警信号通常很容易发现：

• 用户会问下一步由谁负责
• 相似的请求在不同团队收到不同结果
• 异常通过聊天或邮件处理
• 政策变更迫使界面改动，而不是规则改动

政策更新会很快暴露这一弱点。当逻辑藏在界面里而不是清晰的工作流规则中时，每次阈值或角色变更都会变成界面重做。这会减慢团队速度，产生新的错误，并让用户失去信任。

界面应该反映决策路径，而不是去定义它。当矩阵先被理清，UI 会更简单、更稳定、更易用。

在任何线框之前要映射的内容

从决策逻辑开始，而不是从界面开始。稳健的审批矩阵起初是一个简单的表格，显示谁在何种条件下有审批权，以及某人不可用时会发生什么。如果这些逻辑模糊，即使是精美的界面也会让人困惑。

对每种请求类型，按顺序映射审批层级。写清每一步由哪个角色负责，以及该步骤允许的操作：通过、拒绝、审核或退回。用角色胜过使用具体姓名，因为人会变动，团队会变更，而流程必须持续有效。

然后定义会改变路径的规则。金额是显而易见的触发条件，但通常不是唯一的。审批工作流规则往往还依赖于地域、部门、供应商类型、请求类别或风险级别。相同金额在一个团队可能是常规，在另一个团队却可能很敏感。

缺勤也需要规则。如果主要审批人在岗外，谁立即接手？如果备用只是临时的，哪些日期适用？没有这些信息，请求会停滞，因为没人知道本周谁负责。

时间限制同样重要。决定当请求无人响应时会发生什么。你可能选择一天后发送提醒、两天后升级、三天后通知运营。这些选择会影响状态标签、通知和队列视图，因此应在界面设计前确定。

一个实用的矩阵通常回答五个基本问题：

• 什么条件触发这条规则？
• 该阶段哪个角色有审批权？
• 谁是备用审批人？
• 审批人有多少时间执行？
• 如果超期会发生什么？

如果你尽早映射这些答案，其余的开发工作会容易得多。

逐步构建矩阵的方法

使用表格、白板或电子表格。保持简单，让经理、团队负责人和流程所有者都能一次性看懂。

首先，列出每种需要审批的请求类型。不要强行把所有事务塞进一个通用流程，如果业务已经区分不同请求。采购请求、退款、折扣审批和访问请求通常需要不同的审批人、限额和时限。

接着，写下首个审批人以及之后的每个决策点。对每种请求类型，记录谁先审查以及通过或拒绝后的后续处理。沿着路径追踪，直到达到最终结果，如已通过、已拒绝、退回修改或取消。

之后，加入会改变路径的阈值。这是许多团队后来卡住的地方。如果 500 美元以下的请求交给团队负责人，而超过 500 美元的交给部门负责人，现在就把它写下来。如果紧急请求会跳过某一步或走更快的路径，也要记录。

然后记录例外、时限和结束状态。包括缺少文件、重复请求、政策违规和过期审批等情况。规则只有在知道出错时如何处理才算完成。

最后，与目前负责审批的人审查草案。询问工作通常在哪儿停滞，哪些步骤会被跳过，以及正常审批人不可用时会怎样。真实的习惯常常揭示那些从未被记录的规则。

一个小例子能说明问题。想象一个采购请求：办公用品在 200 美元以下交给团队负责人，软件在 200 到 2,000 美元之间交给部门经理，而高于此的还需要财务审批。如果表单没有尽早捕获金额和类别，UI 就无法把请求送到正确的路径。

设定大家都能执行的阈值

阈值只有在人人都能快速识别并每次做出相同选择时才有效。如果规则写成“少额采购”或“高风险供应商”，不同人会有不同解释。使用固定数字、日期和明确条件替代模糊描述。

更清晰的规则应像这样写："不超过 $1,000 的由团队负责人审批。$1,001 到 $5,000 由部门经理审批。超过 $5,000 的由财务和主管共同审批。"这样没人需要猜测请求归属。

金额常见，但如果流程还依赖其他因素，它不应是唯一触发条件。来自新供应商的低金额软件采购，可能比来自已核准供应商的大额订单更需要审查。

大多数团队只需要一小组路由规则。常见示例包括金额区间、供应商状态、采购类别、所属部门和紧急程度。重要的不是规则数量，而是每个人是否以同样方式应用它们。

规则的顺序也很关键。如果人们不知道哪个条件优先，他们会把相同请求路由到不同地方。选定一种顺序并保持一致即可。你可以先检查供应商状态、再看类别、最后看金额；也可以先看金额再处理例外。只要大家按同一序列执行，任一方法都能工作。

同时定义谁可以覆盖阈值以及在何种情况下可以覆盖也很有帮助。没有这点，员工要么等得太久，要么通过邮件和聊天绕过流程。"财务总监可在月末期间审批超限请求" 是有用的规则；而 "高层可以例外处理" 则太模糊。

一个简单测试很管用：把同一个示例请求给三个人，问它该发到哪儿。如果三个人给出三种答案，阈值还是太模糊。

规划备用审批人、临时代替人和升级规则

一个强壮的矩阵不会停留在主要审批人上。现实工作在有人休假、生病或只是没有及时响应时仍需推进。如果你不提前规划，界面看起来整洁，流程却可能悄悄停滞。

先为每个重要步骤指定备用审批人。这个人应当是有正确背景的具体人员或角色，而不是默认的“下一级经理”。例如，如果财务负责人审批超过某个金额的费用，就要决定当该负责人不可用时由谁接手。

临时代替人需要有期限限制。替代者应在定义好的期间内拥有审批权，例如休假日期或计划离岗时间。这样责任清晰，避免有人在不该继续拥有审批权时仍然保有访问权限。

一个简单的设置应回答四个问题：谁是主要审批人，谁是备用，替代者能行为的时长，以及何时把请求上抬到更高层级。

升级应基于清晰的触发条件，而不是凭猜测。常见触发包括时间、金额、风险或缺失信息。例如，如果超过 $10,000 的采购请求 24 小时无人处理，就可以升级到部门负责人。

保持升级路径简短。如果人们需要复杂图表才能明白下一步给谁，说明规则可能太复杂。通常一到两个明确跳转就足够。

记录每一次决策也很重要。保存谁审批了、谁替代了、何时交接及为何升级。当有人事后询问为什么请求延迟或为何由替代人审批时，这些历史记录很关键。

还有一条看似不起眼但很重要的规则：避免循环。请求不应返回到已经审批过它的人，或返回给为同一人代理的替代人。先在矩阵中检查并防止循环路径，然后再实现应用逻辑。

简单示例：采购请求审批

想象一家小公司购买日常用品。员工提交一条采购请求，包含物品、金额、理由和所需日期。路由由规则驱动，而不是由谁在线决定。

如果请求金额为 $420，它会直接发给团队负责人，这能让小额采购流转顺畅。$3,200 的请求跳过团队负责人，直接发给部门经理，因为预算影响更大。

再看一条 $7,800 的设备采购请求。部门经理仍会审查，但仅此还不够。因为金额超过 $5,000，还需财务复核。清晰的矩阵能做到：较高金额增加控制，但不增加猜测。

缺勤在这里也很重要。如果部门经理休假，请求不应停滞。指定的替代者会自动收到请求，并在限定期间内代为处理。

时间限制也需同样明确。如果无人在两天内处理，请求就升级到运营。运营可跟进、重新分配或确保它不会阻塞工作。

在此示例中，矩阵回答了几个简单但重要的问题：申请金额多少、每个金额段由哪个角色审批、何时加入财务、谁覆盖缺勤以及超期会怎样处理。

一旦这些答案被定义，界面设计就变得直接。表单只需收集正确的数据，请求页面只需显示当前审批人、任何替代人以及升级计时器是否在运行。

导致返工的常见错误

大多数返工在绘制第一张界面图之前就开始了。团队猜测审批路径，然后试图让 UI 适配那些从未真正达成一致的规则。

一个常见错误是复制组织结构图并称之为工作流。看起来整齐，但真实请求通常按金额、风险、地点或请求类型移动。如果矩阵忽略这些因素，界面随后就需要额外字段、额外状态和尴尬的例外处理。

另一个问题是忘记特殊情况。紧急请求、受监管的采购或跨团队请求常常需要不同路径。如果这些例外没有提前映射，人们会开始要求人工变通，界面就会充斥各种一次性选项，令人困惑。

当团队给两个人相同职责但没有决胜规则时，也会造成麻烦。如果两人都能审批，谁先行动？如果他们意见不合，哪一方的决定生效？没有答案，请求就会互相推来推去，用户信任也会丧失。

替代规则也是薄弱环节。替代人应覆盖缺勤，而不是悄悄成为长期第二负责人。当临时覆盖与永久所有权混淆时，报表会变得混乱，责任感消失。

在路由未确定前设计表单会带来另一轮返工。表单看似完整，但当审批规则最终确定后，你常会发现缺少字段，例如金额区间、部门、紧急程度或政策标记，然后布局、验证和通知都要改动。

一个快速的现实检查有助于早期发现问题：

• 两个审批人能否同时收到同一请求？
• 临时备份和永久所有者之间有明显区分吗？
• 紧急或受监管的案件是否走不同路径？
• 每个路由决策是否依赖于已存在的字段？
• 如果某个审批人离职，流程仍能成立吗？

如果任何答案不清晰，就停下来。在润色界面前先修正矩阵。

在设计界面前的快速检查

在绘制表单或状态徽章前，用简明语言测试逻辑。一个好的审批矩阵应能在不开图表的情况下被轻松解释。如果经理、财务负责人或运营同事无法在大约一分钟内描述完整路径，流程对 UI 工作来说仍然太模糊。

用真实示例做快速评审。请一人解释从提交到最终决策的完整路径。检查每个可能结果是否都有命名的下一位审批人，而不仅仅是成功路径。把模糊阈值改写为精确规则，例如 "$1,000 及以下" 或 "超过 10% 的折扣"。确认备用与升级规则使用明确的时间限制，如 "24 小时后" 或 "2 个工作日后"。

然后测试可追溯性。事后总有人会问为什么请求被延迟、谁批准了例外或替代者何时介入。你的流程应提前回答这些问题。时间戳、决策历史和清晰的状态变更不是额外项，而是规则集的一部分。

一个简单场景通常会暴露薄弱点。想象一个 $4,800 的采购请求在周五下午到达，而常规审批人不在。接下来谁处理？系统等待多久才移动？如果备用也不行动又会怎样？若这些答案未写明，界面只会掩盖混乱而非解决它。

当这些检查通过后，界面设计就容易多了。你不再猜测界面该展示什么，而是在给明确规则一个明确的呈现形式。

后续步骤：把矩阵变成可运行的应用

规则清楚后，先构建流程再精修界面。先实现逻辑、数据字段和审批状态。如果路由可行，界面设计就容易得多；若路由仍在变动，漂亮的界面只会掩盖问题。

实用的第一个版本通常包括基本项：请求类型、金额、部门、当前审批人、最终状态和每次决策的清晰历史。然后再加入推动请求前进、发送给备用审批人或在无人响应时触发升级的规则。

保持首批界面简洁。提交者应能提交、查看状态并回应后续问题。审批人应能审核、批准、拒绝或重新分配。这就足以测试工作流在日常使用中的合理性。

一个合乎逻辑的构建顺序很直接：

• 定义核心数据字段和状态值
• 为阈值、备用审批人、临时代替人和升级添加路由规则
• 为提交者和审批人创建基础界面
• 确保每个渠道使用相同的数据源
• 在更大范围推广前，先用一条真实请求从头到尾测试

这个共享的数据源比许多团队预期的更重要。如果移动端显示一个状态、Web 面板显示另一个，而后端又按不同阈值运行，信任会迅速消失。

如果你在用 AppMaster 构建，一个清晰的矩阵会让设置更容易。你可以先建模数据、业务逻辑和审批流程，然后把同一流程在后端、Web 与移动端复用，而无需在不同工具里重写规则。

用一个真实案例做第一次测试。运行一条带阈值、替代审批人和超期升级的采购请求。观察人们在哪儿犹豫、缺少了哪些数据以及哪些状态标签让他们困惑。

然后改进措辞和布局。当流程在真实请求上运行良好时，界面设计会更容易，且更不容易在一周后被重做。