迭代式开发模型下，假设某项目，对用户体验环节的目的、方法都清晰明确，实际执行过程配合顺利，在产品验证环节，大家提出了 N 多条建议。
我们遇到的问题是：这么多条建议，能否实现我们用户体验环节的目的？
答案是不能实现目的，或者延迟到非常延迟，才能实现目的。
这和迭代式开发模型和产品开发节奏有关：
在迭代式、瀑布式的开发模型下，所有的需求都是经过一系列流程走下来的，概念落实成为设计，设计分级为架构设计和详细设计，经过多次评审评估，然后进入开发、验证阶段。
那么，在验证阶段提出了 N 多的用户体验修改建议，这个时候，在本次发布的产品上做修改，肯定是来不及：
A 、产品计划不可能在进行较大时间的延期，箭在弦上不得不发；
B 、需求的提出，要出发变更流程，又是劳民伤财的大动作，评估下来，成本太大，性价不不高。
所以，针对这个版本提出的 N 多用户体验建议和意见，几乎不可能在此版本就得到采纳，也就是说，针对这款产品这个版本的用户体验，实际上只是对后续产品才会起到作用。
那么，接下来的版本，就会采纳这 N 条建议和意见么？
往往也是不会，这就是和产品开发节奏有关系。
如上图所示，在产品设计阶段，通常会出现过度设计，比如一开始规划100条功能——经过产品开发周期，最后发现原始计划的 100 个需求 / 功能点，只实现了 60 个，剩余的 40 个需求 / 功能点需要融入到下一个迭代版本中。那么假设在此时，用户体验环节提出了 10 条建议，同理，也会纳入到下个迭代版本。
下个迭代版本（ Build2 ），本身就有 30 个增量需求，继承上一版本（ Build1 ）未实现的 40 个功能和 10 个用户体验建议，那么就是 80 个需求 / 功能。根据需求的优先级，几乎可以肯定未实现功能的优先级大于优化改善已有功能。所以此版本发布时，很可能就是 80 个实现 50 ，还遗留 23 个功能和大部分（ 7 个）第一版本的用户体验。
依次类推： Build3 会规划 45 个功能，最后实际发布版本遗留 10 个功能和 5 个第一版本的用户体验建议。
以此类推，即使后续的 build 版本不再做用户体验环节，第一次的 N 条建议意见，也不可能在下一个版本立刻解决。实际能采纳并改进的时间，在迭代式开发的软件项目中，无法预估。
所以，即使能够在目前的用户体验环节，提出一些高质量的建议，在迭代式开发模型下，也不会达到最开始预期的结果：提高产品易用性，提高客户满意度，提高产品美誉度等等。因为最终建议被采纳的周期，相当漫长，甚至完全不可控。
这是迭代式开发的一个模型问题，所以在强调用户体验和感受的项目，多是采用敏捷模式。当然，对敏捷模式的理解不一致，也会导致很多似是而非的敏捷，这是另外一个话题，在此不表。