MVP版本精简APP页面数量，核心不是把页面“砍得越少越好”，而是只保留验证核心业务闭环所必需的页面。页面数量应由用户完成关键任务所需的流程决定，而不是由功能清单的长度决定。若用户无法完成注册、浏览、提交或反馈等核心动作，页面再少也只是半成品。
先画核心流程，再确定页面
精简页面前，先明确MVP只验证哪一个核心假设，并把用户从入口到目标结果的路径画出来。流程中能够直接支撑目标的页面保留，暂时不影响验证结果的功能后置。首页、核心功能页、结果页和必要的账户或反馈页面，通常比完整的平台结构更重要。
页面合并也要有边界。相近且操作目标一致的内容，可以通过分区、标签或状态切换放在同一页面；但不要为了减少数量，把多个复杂任务硬塞进一个页面。这样虽然页面数下降，交互复杂度却会上升，用户理解成本和设计返工风险也会增加。
统计页面时，别漏掉状态和分支
供应商口中的“页面”，可能只指一张视觉稿，而实际交互还包括输入状态、错误提示态、空状态和流程分支。MVP阶段可以减少不必要的异常场景，但登录失败、提交失败、无内容等影响任务完成的状态不能完全省略。
因此，页面清单应同时标明主页面、关键状态和流程分支。页面数量相同，流程复杂度不同，交互工作量可能相差很大。工具类或社交类产品尤其不能只按画面数量估算。
用分阶段交付控制预算
预算有限时，优先减少功能范围和页面类型，而不是单纯压低单页价格。原文给出的经验是，30页的精简版本相较于60页的完整版本，设计预算通常可节省30%到40%，但前提是核心流程没有被破坏。
实际执行时，建议先形成MVP页面清单，分别标注“必须上线”“验证后补充”和“暂不设计”，再让团队按清单报价。同时提前约定页面口径、交付物和改稿轮次，避免因页面定义不一致或反复修改，让精简后的预算重新失控。
