D1.13.1Staged progress设计研究
多阶段任务需标出当前处于哪一段而非单一总进度
别名: phase indicator · multi-stage task · progress stages · task status
概念解释
分阶段进度（staged progress）将一个由性质不同步骤组成的长任务拆成用户可理解的阶段，并明确标出当前正在进行哪一段，例如「准备文件 → 上传 → 验证 → 发布」。总进度回答整体走了多远，阶段指示回答系统此刻正在做什么。对导入、安装、生成、支付、发布和同步等任务，后者往往决定用户能否理解等待、判断是否异常、预期下一步以及知道何时能介入。
机制
多阶段过程的单位成本和失败模式不同：上传可能受网络影响，验证可能短暂但不可跳过，审核可能等待外部系统。单一总条把这些异质工作压成一个数字，用户无法从停顿或速度变化推断发生了什么。阶段标签提供因果解释和局部参照点，让用户把当前行为与合理的不确定性联系起来；它也避免在某一步耗时变长时被误判为整体卡死。阶段不是技术日志，而是用户用于预测和行动的过程模型。
怎么研究
对同一多阶段任务比较仅总进度、阶段加总进度和阶段加可操作状态，测量用户对当前工作、下一步、可取消性和异常位置的判断。将延迟或错误分别注入不同阶段，观察用户能否正确定位问题和选择恰当恢复。测试不应只询问是否喜欢界面；要求用户在中途解释「系统在做什么」「为什么可能慢」「你现在能做什么」，才能验证阶段是否承载了理解。
边界
并非所有内部步骤都应暴露。过度拆分会把实现细节、短暂瞬间和不稳定的内部重试变成噪声，反而延长用户阅读负担。阶段应在任务语义、等待体验或可行动性发生变化处切分，而不是按服务调用数切分。若阶段顺序可能并行、回退或动态变化，应诚实表达当前范围，不能画出一条暗示绝对线性的虚假流水线。
怎么落地
- 按用户可理解的工作目的划分阶段，为每一段写明开始、结束、失败、可取消和可离开条件。
- 同时显示当前阶段和总体范围；对持续时间差异大的阶段给出相应说明或剩余信息，不让总条独自承担解释。
- 将可恢复错误定位到具体阶段，并提供该阶段的重试、返回或替代动作，而非只显示笼统的失败。
- 在每个阶段制造慢、失败和后台恢复条件测试；用户应能指出卡在哪里并知道下一步，而不是只能等待总进度变化。