APP定制开发前的原型评审：页面、流程与异常状态怎么过
APP定制项目进入开发前，原型评审常常被当成“看一遍页面”的会议。实际上，原型决定的是开发范围、交互规则和验收口径。页面画得完整，不代表流程能走通；主流程顺畅，也不代表异常状态有处理办法。评审要围绕可执行性，而不是只讨论视觉偏好。
原型评审先对齐三件事
如果范围、角色和外部依赖没有对齐，讨论很快会跑偏：有人关注按钮位置，有人追问后台谁审核，还有人以为某个功能本期就会上线。评审开始前，先把这三类信息摆出来，能减少不少无效争论。
- 范围：本期做哪些页面和功能，哪些明确放到后续版本。
- 角色：游客、注册用户、管理员等分别能做什么，哪些操作需要权限。
- 依赖：登录、消息通知、地图定位、支付或已有系统接口，是否需要第三方配合。
这三件事不必等到需求文档完全写完才确认，但必须在原型评审中有明确结论。没有结论的部分，应标记为待定，而不是让开发人员自行假设。
页面清单：先看有没有“无主页面”
页面清单不是简单罗列名称，而要说明入口、使用角色、主要任务和跳转关系。评审时可以逐页问：用户从哪里进入，页面解决什么问题，完成后去哪里。没有入口的页面、只有设计稿没有数据来源的页面、重复承担同一任务的页面，都应在开发前处理。
- 每个页面是否有明确入口，是否能在导航或流程中被找到。
- 页面上的数据来自哪里，是用户填写、后台录入还是外部接口返回。
- 列表页与详情页是否成对出现，空列表和内容删除后如何显示。
- 同一功能是否在多个页面重复出现，能否合并以减少维护成本。
页面数量多并不一定代表功能完整。对定制APP来说，减少一个无实际任务目标的页面，往往比增加一个“看起来丰富”的模块更有价值。
主流程按角色走一遍
主流程评审不能只看静态页面，而要按角色实际走路径。可以由业务方描述操作，由产品或设计人员对照原型逐步确认。每一步都要说清楚：用户看到什么、需要填什么、系统给出什么反馈、失败后能做什么。
- 以新用户身份走注册、浏览、提交或下单等核心路径，记录每一步需要的数据和提示。
- 以老用户身份走再次使用路径，检查登录状态、历史记录、默认值和消息提醒。
- 以管理员身份走内容审核、订单处理或用户管理路径，确认后台操作与前端状态一致。
主流程评审要明确成功条件。例如提交成功后是停留在当前页、跳转结果页，还是返回列表；审核通过后前端多久能看到变化。这些细节如果等到开发阶段再补，容易造成前后端理解不一致。
异常状态是评审重点
很多原型会把正常路径画得很顺，却把失败情况留成一句“提示错误”。真正进入开发后，异常状态往往需要额外页面、文案和交互。评审时至少要覆盖以下几类情况。
- 空状态：没有列表数据时显示什么，是否提供下一步入口。
- 失败状态：请求超时、提交失败、上传中断时，用户能否重试，已填内容是否保留。
- 权限状态：未登录、登录过期、角色无权限时，页面如何提示和跳转。
- 边界状态：长文本、大量图片、重复点击、弱网环境下的显示与操作限制。
异常状态不需要在原型阶段画到像素级，但处理原则要定下来。比如提交失败后是保留表单还是清空，删除操作是否需要二次确认，未登录用户点击受限功能时是跳转登录页还是弹窗提示。这些规则会影响开发和测试用例。
评审记录怎么写才有用
评审会如果没有记录，修改意见很容易散落在聊天记录里。建议把结论分为确认、待定和不做三类，每条记录注明页面、问题、处理方式和负责人。待定项要设定确认时间，否则开发排期会被反复打断。原型版本也需要保留，避免口头修改后无法对照。
- 会前发送页面清单和主流程，要求参与人提前标注问题。
- 会中按角色走流程，不在单个视觉细节上停留过久。
- 会后输出修改清单，区分必须改、可优化和不采纳。
- 修改后的原型再次确认关键页面，再进入开发排期。
记录的作用不是增加文档量，而是让后续开发知道哪一版是准的。尤其是页面跳转、字段必填、状态变化这类规则，口头确认很容易出现偏差。
适用边界：原型不能替代全部需求
原型评审能解决页面结构、主流程和常见交互问题，但不能替代技术方案、接口文档和测试验收。涉及复杂算法、硬件调用、第三方系统对接时，还需要单独确认技术可行性和责任边界。原型也不是越细越好；如果业务方向尚未稳定，可以先做低保真流程，等核心路径确认后再补视觉细节。
当核心流程仍有多处待定、异常状态没有结论、外部接口未确认时，不宜直接进入开发。对页面多、角色多的APP，分阶段评审通常比一次看完更有效。先确认范围与主流程，再补充异常状态和细节页面，开发排期才有可靠依据。
原型评审的目标不是把每个按钮都定死，而是让开发知道要做什么，让业务方知道验收什么。页面、流程、异常状态和记录四件事对齐后，APP定制才更容易按范围推进，减少中途返工。