准备一次设计方案评审：从一页需求到能拍板的方案
评审开不好，通常不是会上吵得不够，而是进场前没把目标、边界和分歧点摆出来。这套流程把准备工作做在会前。
怎么做
第一步：先写一页需求，而不是先画图
用「给设计师的需求书」把目标用户、要解决的唯一问题、这版不做什么、成功标准和约束写成一页。没有这一页，评审会很容易变成对审美的投票。写完后自己读一遍：如果换一个人执行，他能不能做出差不多的判断？
第二步：把需求展开成可评审的设计说明
用「把需求写成设计说明」把上一页展开成信息层级、关键状态、边界情况和验收标准。注意让它标出还没想清楚的地方，这些正是会上要讨论的，不要用漂亮的措辞盖过去。验收标准要写成能勾选的句子，比如「断网时提交，草稿不丢」。
第三步：自己先做一轮评审，把明显的问题留在会前
用「界面设计评审」把稿子或截图喂进去，要求按层级、可用性、状态覆盖挑问题并按严重度排序。先改掉自己能改的，别把一眼能看出的毛病带到会上；改不动的记下来，会上只讨论有分歧的部分。
第四步：反向挑错，准备被问倒的三个问题
用「反向挑错」让它扮演最挑剔的评审者，只攻击方案里最站不住的假设。把问题收成三个，每个配一句回答和一条证据：用户原话、数据或竞品做法。会上答不上来的，当场记成待办，不要硬圆。
第五步：把通过的结论写成开发能用的标注
用「给开发标注间距与层级」把会上确认的层级、间距、状态和交互写成交接说明。没确认的部分明确标成待定并写谁来决定，否则开发会按自己的理解实现，下一轮评审又要重来。
用到的提示词
常见问题
设计方案评审要提前准备什么？
一页写清目标和边界的需求、一版能指给人看的稿子，以及三个你最可能被问倒的问题。稿子不必完美，但每个决定要能说出理由。
评审会上和设计师意见不一致怎么办？
把分歧拉回成功标准和用户场景，而不是审美。用「反向挑错」把双方的假设摊开，会上只决定能验证的部分，剩下的约定用什么方式验证。
没有设计师，只有我自己画的原型，也能用这套流程吗？
能。把「给设计师的需求书」换成写给自己的约束，评审那步直接把截图或文字描述交给「界面设计评审」，重点看状态覆盖和层级是否说得通。