前提：需要有相对整体和成熟的设计方案，让大家对未知结果的投入达成一致；风险：风险大，耗费资源相对较大，时间周期较长；优势：可以从头思考、梳理，能从根本解决一些问题，优化的体感更强。（2）在老版的基础上进行优化，整体架构保持不变，局部体验优化。前提：业务合作中常见的设计合作模式，局部功能优化，跟产品同步迭代；风险：较难从根本上解决遗留的体验问题；整个产品体验较差，局部体验改善容易被忽略；优势：风险小，投入的资源相对较少，结果可控，见效时间快，较容易达到预期。
本次我所负责的产品改版选择的是「第一种方式，风险相对较高」。鉴于大部分设计师、尤其是新手设计师对前端技术可能都不太了解，对前后端的配合、开发的工作评估、工作流程等也不是很熟悉，以下四点「经验教训」给有相似经历的设计师以借鉴。2.1 经验：规则制定，“丑话”说在前面前期确定统一的“完成”标准和项目合作规则，这点很重要。
不妨先把“丑话”说在前面。项目合作规则在这个项目中，第一周期完成后，就出现了延期现象，虽然延期在很多项目中不可避免，但期望能够及时的发现问题、总结问题、反思工作，让问题不像滚雪球一样越滚越大。延期的原因主要有：（1）工作评估不充分，计划太理想现象：计划时间无法完成计划的工作，评估的时间不够准确结果：计划的时间起不到约束作用（2）“完成、进度100%”的标准定义不明确现象：了解工作进度时，可能统计已完成，但又会占用时间去测试、优化、调整；实现效果与需求不完全一致；结果：进度评估不准确。
2.2 经验：策略及时调整，有限时间内干更有意义的事承诺的交付时间是确认的，因此，我们只能以deadline倒推。在剩余的时间内，我们能完成什么，从而有针对性的做排兵布阵。如果把时间比作一个盒子，当盒子空间固定，若要塞进更重要的东西，则需要将不那么重要的东西去除，否则盒子会爆裂。同样项目管理中需要及时调整计划，在有限的时间内干更有意义的事，否则工作一直做不完，一直延期，产出的质量和项目目标都不如人意。
我们需要及时根据优先级调整策略，对需求区分主次，甚至在某个需求中再拆解，如高级功能暂缓，先保证基础功能的使用等。2.3 经验：核心体验提升才是对用户更有价值的事情看了那么多改版产品的反馈，第一时间的不适应必然存在，尤其对中后台运维产品来说“稳定”是用户的诉求之一。但紧抓核心体验，从功能层面解决用户问题，最后一定是正向的评价与结果。
