审批人只点了一次“批准”，此前却查过预算、附件和历史记录，还向申请人确认过用途。如果改版只统计点击，就会把最费力的判断留在界面之外。
任务分析研究人在具体环境中如何完成目标，包括身体动作、思考、信息交换、工具和系统反馈。它把大任务拆成子任务，说明顺序、条件和异常，帮助设计师判断哪些支持不能漏掉。
“打开审批页”之后，还发生了什么
以企业采购产品改善审批为假设场景。分析从审批人收到待审申请开始，到申请进入下一责任环节结束。付款和后续交付暂不在范围内，遇到相关问题先记录。
“点击审批页”是界面动作，“判断申请是否符合采购规则”才是子任务。后者需要用途、金额、预算、权限与附件；资料不足，还要决定补问、退回或转交。
请熟悉任务的人按实际条件演示，或用近期案例回顾，记录他查什么、问谁、何时中断。看不见的判断在适当时机追问，来自自述的片段注明来源，别用研究者的猜测填满。
熟练审批人可能说“检查一下就提交”。继续问他检查哪些依据，才会发现日期、历史价格或附件内容。不能只照专家表面操作设计，让新用户自行补全判断。
拆到能看出输入、判断和结果
层级拆解从总目标进入子任务，深度取决于设计问题，不需要列每次鼠标移动。将需要先后完成、可并行、条件触发和重复的部分标明。
| 子任务 | 需要什么 | 做什么判断 | 产生什么 |
|---|---|---|---|
| 理解申请 | 用途、金额、申请人 | 是否理解需求 | 可解释的概要 |
| 检查条件 | 预算、权限、附件 | 是否符合规则 | 批准或补问依据 |
| 处理缺失 | 缺少项、联系人 | 退回还是补充 | 要求与明确状态 |
| 完成处理 | 决定、下一接收人 | 提交并核对反馈 | 记录与后续责任 |
输出不一定是一条系统数据，也可能是人的判断。信息尚未支持判断，界面就不能假装这个子任务已完成。
正常路径之外，保留附件错误、预算变化、权限不足和提交失败。申请退回之后怎样恢复，补充后是否要重审，都需要能够沿图走到结束。把异常写成“另行处理”，等于把困难留给使用者。
临时表格，可能补着系统缺少的信息
现状图要保留绕行、口头沟通和临时工具。审批人打开另一张预算表，可能因为系统没有当前余额；问同事可能是在确认权限，未必是多余交流。
先弄清这些动作补足什么，再讨论是否整合。理想流程另画一个版本，新增能力标出来。若希望自动核预算，要写数据来源、权限和失败后的处理，不能只在原型里增加“通过”标签。
请任务执行者核对图，再让另一位同角色人员用自己的案例走一遍。差异可能来自权限、经验或申请类型，保留下来比急着形成唯一标准路径更有用。
成功标志是图能解释已经观察的审批过程，也能把一个资料缺失的申请走到明确结果；团队看得出哪些判断有依据，哪些情境尚未覆盖。
优先级不能只按步数排列
频率、目标重要性、失败后果和恢复成本要一起考虑。经常切换预算页可能值得减少查找；低频权限错误也可能阻断整条流程。
观察到的耗时注明来源和条件。某位新员工慢，可能与培训或资料缺失有关，不能直接概括所有用户。删一个确认也未必更快，如果因此不知道是否提交成功，用户可能反复操作。
本例可以提出“在当前申请内查看必要预算依据”的要求，再用原型检查审批人能否作出判断。是否仍需线下确认、异常怎样处理，都要保留业务规则。
涉及现场等待和交接时，可以结合行为地图看它们在哪里发生。任务分析回答要办成什么，环境观察补充实际条件。
从图转成可验证的界面要求
交付任务层级、分支规则、输入输出、困难与证据即可。每项改动连接到任务，例如减少查预算的来回切换，而非只写“优化审批效率”。
原型验证继续使用目标任务，别逐个指挥点击。判断用户是否获得必要依据、能否处理缺失与恢复错误，比单纯减少步骤更贴近审批工作。任务分析让设计看到判断过程，方案是否支持它还要实际检查。
给复杂工作留下必要支持
58UI在后台UI/UX设计中可整理审批、补填和交接任务，落实到页面状态、信息架构与响应式原型；企业官网设计开发和品牌视觉设计也可围绕明确任务组织信息。
你可以查看设计与开发服务与官网与界面案例。通过沟通具体设计问题提供一项任务的输入、判断和完成条件，能让改版从具体困难开始。
相关服务
