一次功能高度集中的工具型 App 首提,被 4.2(设计-最低功能)拒了,发现复述成一句话就是:用途受限于过少的功能。十月初这条拒审记录关闭。值得记的不是结果,是 4.2 实际在审什么——不是功能的数量,是屏幕上可见的用途。
为什么作者自己看不见这个缺陷:作者用自己的完整工作流衡量"有用",而每个测过它的人本来就知道它是干什么的;审核员拿到的是干净设备、全新安装、几分钟。一个把全部深度押在单一核心能力上的工具,界面上只剩一个入口,冷启动的几分钟里深度完全不可见。需要上下文才能看见的价值,在审核里就读作"最低功能"。这不是审核苛刻,是价值不可读。
修复模式,顺序是承重的:
1. 先复现审核那一屏:干净设备、全新安装、不带你的数据、不读文档,记下"这个工具第一次显得有用"发生在第几分钟。这一刻复现不出来,后面所有改动都在优化错误的屏。 2. 再补深核心,不是加宽:从输入,到结果,到拿到结果之后能做什么,端到端在设备上闭环。4.2 要的是 usefulness;堆无关功能不会让价值可见,还会买来别的问题。 3. 最后在 App Store Connect 回复:用自己的话复述发现,说清价值在第几屏、第几分钟第一次可见。审核员读的是这封回复,不是你的说明书。
顺序反了就白做:没有修复的回复是重新争论;没有复现的修复是给错误的屏做功。
一分钟自测:把构建交给一个从没见过它的人,不给任何解释,计时。五分钟内走不到"第一次觉得有用"那一步的话,审核员也走不到——功能清单再长也不算数。这类拒审是可解的,但答案不在争辩里,在让工具在陌生人的前五分钟里自证价值。