DOMAIN · PRODUCT
产品与需求
想法如何变成范围明确、可以验收的产品任务。从用户常说的话进入，逐步看懂背后的技术关系与验收边界。
User Story 用户故事
02用“谁、为什么、要做什么”描述用户需要获得的结果。
“作为项目经理，我想导出周报，以便提交给业主。”Jobs to Be Done 待办任务
03从用户要完成的进步或任务出发，而不是从产品功能出发。
“用户真正要的是按时交付可信报告，不只是点一个导出按钮。”Persona 用户角色
04基于真实研究总结的一类典型用户及其目标、能力和限制。
“现场工程师主要用手机，网络不稳定，操作时间短。”User Flow 用户流程
05描述用户从入口到完成目标经过的页面、动作和分支。
“画出从选择文件、校验、上传到成功或失败重试的流程。”Wireframe 线框图
06用低细节结构草图确定页面信息和操作位置。
“先用灰框确认布局，不要一开始纠结颜色和阴影。”Prototype 交互原型
07用可点击或可运行的模型模拟关键流程和状态。
“做一个能切换标签、提交表单并展示错误的原型。”MVP 最小可行产品
08用最小完整范围验证核心价值，而不是发布一个残缺页面。
“首版只做上传、转换和下载，但三个步骤都必须可靠。”Acceptance Criteria 验收标准
09用可观察、可重复的条件定义一个需求何时算完成。
“在 390px 手机上按钮不溢出，提交失败时显示可重试原因。”Roadmap 与 Backlog
10Roadmap 表达阶段目标，Backlog 保存按优先级排列的候选工作。
“路线图看季度成果，积压列表看下一批具体任务。”Analytics Event 行为事件
按统一名称记录用户在产品中的关键动作及必要上下文。
“记录下载按钮点击、平台和版本，但不采集个人敏感信息。”