我做这个项目，是为了训练把一个小 UI 问题向上拆解为产品体验问题、基础组件能力、数据指标和项目复盘闭环的能力。
项目概览
为什么要做这个项目？
很多数字产品里，文件上传、数据导出、AI 内容生成、视频转码、订单提交和内容审核都不是瞬时完成的。用户点击后，系统可能还在后台处理，但如果界面没有及时、可信、可解释的反馈，用户就会进入“不确定等待”。
这个项目从进度条 UI 出发，但最终处理的不是视觉样式，而是任务状态反馈系统：操作是否被接收、任务是否还在处理、现在处于哪一步、失败后怎么恢复、不同业务模块如何使用统一组件、后续如何通过埋点复盘。
问题定义
原始问题不是字段，而是需要被解释的场景。
很多数字产品存在文件上传、数据导出、AI 内容生成、视频转码、订单提交、内容审核等耗时任务，但界面反馈不足时，用户无法判断系统是否响应、任务是否卡住、是否可以离开页面，以及失败后如何处理。
- 操作反馈不足：用户点击后不知道系统是否响应，容易重复点击或重复提交。
- 进度不可见：用户不知道任务完成到哪一步，也不知道是否卡住。
- 状态文案模糊：只显示“处理中”“加载中”，无法解释系统正在做什么。
- 异常处理不足：失败、超时、断网、权限不足等状态缺少清晰原因和下一步操作。
- 体验不统一：不同业务模块各自实现 loading、进度条和错误提示，造成体验割裂。
项目背景
为什么这个问题值得拆解？
用户不是不能接受等待，而是不能接受不确定等待。进度反馈的本质不是动效，而是降低等待不确定性，建立用户对系统的信任。
工作流 / 方法
我如何推进这个项目？
我先把耗时任务分成不同类型：短任务、中等任务、可计算长任务、不可计算长任务、超长任务和异常任务。不同任务不应该使用同一种进度表达方式。
可计算任务适合百分比进度，不可计算任务不能伪造百分比，更适合阶段型反馈。失败状态必须给出原因和下一步，长任务则需要考虑后台运行、完成通知和任务中心的后续扩展。
- 梳理上传、导出、AI 生成、转码、审核等等待场景
- 拆解用户在等待过程中的疑问和焦虑来源
- 区分短任务、中等任务、可计算长任务、不可计算长任务和异常任务
- 设计按钮 loading、普通 loading、百分比进度条、阶段型进度和异常恢复
- 定义 task_start、progress_show、progress_update、task_success、task_failed 等埋点
- 用 MVP 覆盖基础反馈能力，再通过示例复盘验证优化方向
输出结果
当前形成了哪些可复盘产出？
统一进度反馈组件方案、任务状态规则、异常处理规则、埋点指标、MVP 范围和模拟复盘结论。
- 项目前分析报告：判断项目是否值得做，覆盖背景、问题定义、场景、目标、可行性、收益成本、风险、MVP 和立项建议。
- PRD 产品需求文档：说明具体怎么做，覆盖业务流程、功能流程、页面交互、状态逻辑、异常处理、埋点、验收标准和上线策略。
- 项目复盘报告：用示例数据展示如何回顾目标、上线范围、数据结果、用户反馈、问题归因和后续优化。
- 作品集展示文档：把项目整理成适合个人主页展示的 case study 结构。
项目沉淀
这个项目沉淀了什么？
- 用户真正害怕的不是慢，而是不确定。
- 基础组件也可以成为跨场景的产品能力。
- 产品必须告诉用户系统是否响应、任务是否进行、当前处于哪一步、失败后如何恢复。
- AI 生成类任务不适合伪造百分比，更适合阶段型进度和解释性文案。
- 一个产品优化项目也应该具备立项分析、PRD、MVP、埋点、验收和复盘。
项目定位
不是一个进度条 UI，而是一套任务状态反馈系统
如果只把这个项目理解为“加一个进度条”，就会低估问题。真正需要解决的是一整套任务状态反馈：操作是否被接收、任务是否在处理、处理到了哪一步、失败后如何恢复、不同业务场景如何保持一致。
- 把“加载中”升级为可感知、可解释、可恢复、可复用的任务状态反馈机制。
- 覆盖上传、下载、导出、AI 生成、视频转码、审核等待等场景。
- 通过统一组件减少体验割裂和重复开发。
用户与场景
等待场景的关键问题是不确定性
- 文件上传：需要显示百分比、文件大小、速度、剩余时间、成功状态和失败重试。
- AI 生成：不适合伪造百分比，更适合“已接收任务、正在理解、正在生成、正在优化、正在保存”的阶段反馈。
- 数据导出：需要区分任务已创建、文件生成中、可下载、失败可重试。
- 订单 / 表单提交：点击后按钮立即进入提交中，避免重复点击。
- 视频转码：必须区分上传完成和处理完成，避免 100% 但实际不可用。
解决方案
不同任务，用不同的进度表达
- 短任务：按钮 loading。
- 中等任务：loading + 状态文案。
- 可计算长任务：百分比进度条。
- 不可计算长任务：阶段型进度。
- 超长任务：后台运行 + 完成通知。
- 异常任务：失败原因 + 重试 / 取消 / 返回 / 联系客服。
功能模块
从按钮反馈到数据埋点的组件体系
- 按钮反馈：适用于提交表单、保存设置、确认操作，点击后立即 loading 并禁用重复点击。
- 普通 loading：适用于中等耗时任务，展示 loading 动画和状态文案。
- 百分比进度条：适用于上传、下载、文件处理等可计算任务。
- 阶段型进度：适用于 AI 生成、视频转码、内容审核等不可准确计算百分比的任务。
- 异常处理：覆盖失败、超时、断网、权限不足、文件过大、格式不支持等状态。
- 数据埋点：记录任务开始、进度展示、进度更新、用户取消、用户重试、任务成功、任务失败、任务超时和中途退出。
数据指标与埋点
用指标验证等待体验是否真的改善
- 核心指标：任务完成率、中途退出率、重复点击率、失败率、重试成功率、客服咨询量、等待页停留时长、取消率。
- 埋点事件：task_start、progress_show、progress_update、task_cancel、task_retry、task_success、task_failed、task_timeout、task_exit。
- 这些指标用于判断组件是否改善任务完成率、等待体验、重复操作和客服成本。
MVP 范围
先覆盖基础反馈能力，再扩展任务中心
- MVP 包含按钮 loading、普通 loading、百分比进度条、阶段型进度反馈、成功提示、失败提示、取消入口、重试入口、基础异常文案和基础埋点。
- MVP 暂不包含完整后台任务中心、多任务并行管理、跨设备同步、系统级通知中心、复杂断点续传和完整任务历史页。
- 第一阶段先解决用户点击后有反馈、等待时知道系统在处理、失败后能恢复。
项目复盘
示例数据 / 模拟复盘，不代表真实线上结果
本项目的复盘数据为示例数据，用于展示产品经理如何建立复盘逻辑，而不是声明真实线上结果。复盘重点在于：目标是否达成、哪些场景收益明显、哪些问题仍需优化，以及下一阶段如何从进度展示升级为任务管理。
- 文件上传场景改善最明显，因为上传任务天然适合百分比进度。
- 数据导出场景中，按钮 loading 和任务处理中提示能减少重复点击。
- AI 生成场景改善有限，因为 AI 任务不可准确百分比化，需要更精细的阶段反馈和后台任务能力。
- 后续应从单点进度展示扩展为任务中心、通知系统和 AI Agent 执行流反馈。
项目文档
完整文档与交付物
项目文档已放入 public/docs/unified-progress-feedback/。其中复盘报告使用示例数据 / 模拟复盘，不代表真实线上结果。
复盘反思
目前最需要克制的地方是什么？
这个项目提醒我，小组件背后往往藏着很大的产品问题。用户不是要求系统永远足够快，而是希望等待过程可理解、可预期、可恢复。
从产品经理视角看，统一进度反馈组件不是纯 UI 细节，而是连接用户心理、业务转化、异常恢复、数据验证和组件复用的基础能力。