原型要验证的是流程而不是外观
很多人把原型理解为提前看看界面好不好看，这个理解会浪费掉原型最有价值的部分。原型真正要回答的是：业务动作能不能顺畅走完，哪些环节会卡住。
因此原型的重点在于页面之间的流转关系、字段的输入输出、状态的变化路径。把这些串起来走一遍，通常能发现描述阶段被忽略的空档。
外观可以粗糙，流程必须完整。一个画得精致但只有首页的原型，对项目风险识别几乎没有帮助。
原型应该做到什么颗粒度
颗粒度取决于用途。用于内部对齐流程的原型，覆盖主要角色和核心路径即可，次要分支可以用文字列表补充说明。
用于对外演示或者给非直接使用方确认的原型，则需要覆盖关键异常分支，因为演示时最常见的问题恰恰来自异常路径。
有一个实用的判断方法：如果拿原型让一线操作人员走一遍，他能说出如果遇到某种情况该怎么办，说明颗粒度基本够了；如果他只能评价按钮颜色，说明还停留在外观层面。
用原型组织内部评审
评审应当邀请实际操作者，而不是只有管理者。管理者关注的是整体效率与风险控制，操作者关注的是每一步是否顺手，两类反馈都重要，但后者更容易被遗漏。
评审过程中不要急于解释设计意图。让参与者先自行操作，观察他们在哪里犹豫、在哪里问问题，这些犹豫的位置往往就是需求描述中最含糊的地方。
评审结束后要产出明确的记录：哪些流程确认通过、哪些需要调整、哪些属于本轮不纳入范围。没有记录，评审就会变成一次没有结论的讨论。
从原型到开发之间的衔接
原型确认之后，需要把界面背后的规则补齐。原型只呈现了输入与输出，还要说明数据从哪里来、校验规则是什么、权限如何区分，这些内容应当补充到需求说明中。
原型的页面结构可以直接成为开发与测试的共同参照。测试用例按原型路径编写，能保证覆盖范围与确认范围一致，减少验收阶段的争议。
需要提醒的是，原型不是最终设计。进入开发前仍需要完成视觉与交互细节的设计调整，把原型直接当作成品界面，会在实施阶段带来大量返工。
原型还能承担记录决策过程的作用。当后续有人提出调整时，可以先确认这个想法是在原型确认之前就遗漏了，还是确认之后才新增的，两种情况对应的处理方式完全不同。这种记录能把讨论拉回具体的流程节点，而不是停留在感受层面。对于内部意见分歧较大的项目，原型也是一种有效的折中手段：先按其中一种方案做出可操作的原型，让持不同立场的同事各自在具体界面上操作一遍，分歧往往会迅速收敛到几个明确的问题上，比反复开会讨论更容易得出结论。
