设计交付与原型

产品设计交付产品文档与产品逻辑原型。让用户既能检查规则，也能沿具体场景看清产品如何运作，在投入体验细节之前确认是否做对了产品。

文档与原型共同形成产品决定

从代表性任务出发，边写规则边制作粗原型：把规则落实成具体对象、状态和路径，用走读暴露遗漏、矛盾和未决问题，再同步修订。用户确认的是两份产物共同表达的产品逻辑。

新产品或完整产品方案交付两者；已有产品的局部变更更新受影响的规则与路径。用户明确只请求文档或先梳理流程时，先完成该范围，交代尚未覆盖的原型或验证，不自动扩大任务。纯讨论、规则核查和价值评估按任务交付结论。

两份产物的分工

内容	产品文档：规则依据	产品逻辑原型：场景演示
用户、问题与目标	服务谁、解决什么、怎样算达到目标	用具体角色与场景体现目标
范围	包含内容、非目标、适用条件	展示本次覆盖部分，标明未覆盖处
对象及关系	对象含义、彼此关系	用代表性假数据让关系可见
业务规则	条件、权限、限制、状态变化与结果	在影响路径的位置体现规则，按需标注
用户路径	主要场景、入口条件与完成结果	展示业务动作、选择、重要分支与终点
异常与中断	失败、取消、恢复后的业务结果	演示改变用户去向或结果的重要情形
决策与未决问题	理由、代价、待决定事项及影响	在对应位置标注待定项和必要解释

同一决定可以在两处出现：文档保持准确完整，原型使其具体可见。规则变更时同步更新相关演示，交付时核对一致性。

产品文档如何说明完整过程

沿用项目中的原始需求作为意图依据，产品文档将其展开为可讨论、可检查的方案。区分已明确的需求、建议方案与待确认事项；生成文档本身不代表其中新增取舍已获确认。

按产品实际复杂度组织内容，不强制固定章节。读者应能理解：

• 谁在什么情境下使用，想得到什么结果，以及本次覆盖到哪里。
• 核心对象是什么、如何关联，避免为方便描述而强加不存在的层级。
• 从入口到结果的完整过程：用户做什么、系统做什么、需要哪些输入、产生什么输出，以及影响后续操作的重要分支。
• 哪些规则影响结果和判断，包括完成条件、异常处理，以及产品实际依赖的数据或证据口径。
• 怎样用一个代表性场景走完流程，并据此判断方案是否成立。

需要讨论首版时，给出建议范围、验证顺序和可观察的验收结果；未确定的取舍集中列出并说明影响。页面组织可以作为理解流程的候选表达，不能在未经确认时成为体验设计必须沿用的布局。原始需求保持意图来源，产品文档维护当前方案，原型演示方案中的路径与结果。

产品逻辑原型怎样做

产品逻辑原型与体验原型都面向最终用户，共享产品的基本对象、功能关系和任务逻辑。用可打开的简陋产品呈现真实入口、主要操作和结果，让用户按实际用途探索与完成任务。演示控制放在独立的辅助区域。

逻辑原型可降低实现和视觉保真度，仍须具备基本的可理解性：

• 用用户熟悉的语言呈现处理对象、当前情况、可做的动作和结果，让人无需作者讲解就知道怎样开始和继续。
• 用假数据、静态内容、箭头、跳转与标注表达逻辑；真实后台与数据处理可模拟。
• 主要路径上的动作能跳到下一状态，或明确指出后果及对应位置。辅助按钮可以不实现，并标明用途。
• 产品自身的入口、文案和反馈承担主要表达；标注补充未实现部分、业务条件及待定项。
• 使用简单样式和假数据即可；主要任务应可理解、可追踪，视觉品质、操作效率和细节打磨在体验阶段深化。

路径表达的是“在什么情境下作出什么业务动作，得到什么结果”。原型应已具备面向用户的基本结构；体验阶段在此基础上优化页面、布局、控件和操作衔接。

讨论布局、目录或导航关系时，用代表性内容展示入口与点击后的页面，让用户沿一条路径看清内容怎样关联。已有真实材料时优先选取其中的内容；涉及资料展示与维护时，同时说明内容来自哪里、以后在哪里修改。这些关系可以用相连的页面样张或可点击原型表达，保真度以足以判断当前方案为准。

例如报销申请：草稿 → 提交 → 待审核 → 模拟拒绝 → 查看原因 → 修改重提。文档定义待审核时可撤回、拒绝后可修改等规则，原型展示这些条件下可以去哪里。审核结果用演示按钮切换即可。

共同走读与确认

用代表性任务逐条走读主要路径及影响业务结果的重要分支，检查：

• 最终用户能否从产品本身辨认用途，找到任务入口，而无需先学习内部术语或阅读评审说明？
• 当前是谁、处理什么、处于什么状态？
• 能作出哪些业务动作或选择，各自有什么条件和后果？
• 能否从入口走到预期结果，中断或失败后去哪里？
• 文档规则与原型表现是否一致，未决项是否清楚？

走读发现的问题回写文档和原型，向用户呈现具体取舍与建议。确认覆盖目标、范围、对象、规则、主要路径及结果；交接时说明已确认内容、待定项、模拟范围与验证依据。逻辑走读证明方案的连贯性，真实需求、使用理解及工程能力仍需各自的证据。

演进为体验设计原型

产品逻辑确认后，由 interface-design 研究如何让用户理解并顺畅完成任务，再形成体验原型。需要新视觉方向时，在这一阶段制作样张与推荐，按用户选定方向继续。

体验设计可以合并或拆分页面、调整入口、选择控件、改变操作顺序，只要保持已确认的业务含义与控制边界。例如粗原型中的填写、检查、结果三个画面，可以在体验设计中合成一页。

粗原型可直接改造，也可依据同一产品逻辑重新制作。体验原型成为当前表达后，旧粗原型保留为阶段记录并标明已被替代；产品文档持续维护当前规则。体验探索发现规则缺口或冲突时，提出影响与建议，确认重要取舍后同步修订文档和当前原型。

两种原型都通过产品自身的界面与行为让用户理解；差异在于细节与验证深度。逻辑原型确认产品结构和任务是否成立，体验原型深化操作质量、状态反馈与视觉表达。交互与视觉验证采用 interface-design 的方法。