交叉并行，配合项目组成员进度 在我们产品 2.0 计划的这波需求（有 PD 提出的，也有设计师想自发改进的）中，有重视觉轻交互的运营设计，有界面简单但牵涉业务逻辑复杂、开发成本高的流程设计，有视觉需求弱、交互甚至产品直接 Cover 的后台设计，有重情感化互动、需要设计师主动思考探索的跨 PC、移动平台创新设计，还有影响面最广泛的全网整体重构…… 在这些对于各职能来说工作量不一的需求面前，如果按照传统的瀑布式「Prd/用户研究 – 交互设计 – 视觉设计 – 前后端开发」流程逐一完成需求交付的话，当前面的职能花上较多时间来考虑解决方案时，后面的职能就会在这段时间内变得无所事事，而之后又可能变得疲于奔命。（举例子来说，如果我先做需要较长思考和设计时间的某创新设计，花掉一周半的时间，这段时间我后面的视觉和开发资源都会空闲；而等我交付掉了这个页面，再用两天不到的时间做完了某流程设计，对开发来说之前的需求才刚启动， 又来了一个开发成本更高的，压力就会变大不少） 根据师兄和 PD 们的建议安排、以及开发们给出的排期估计，在整体 Deadline 已定，部分需求业务优先级相近的前提下，我选择优先投入几个重开发/重视觉，而交互产出周期相对较短的需求，这样视觉/开发们可以在更早的时候就介入，而不是等到接近 Deadline 时分身乏力；与此同时，用研也启动对于整体重构这类计划的前期用户调研验证，而我在这个相对较长的周期里先完成那些明显能帮助达成业务目标、满足用户诉求的设计，等用研结果出来之后，再跟进那些有较大影响面、风险和不确定性（可能激发强烈反弹）的设计。这种职能交叉并行的推进方式，可以将大家的压力更合理均匀地分解，而不是在某一处发生「集中堵塞」。 
优先快速打包完结低成本、短排期的需求 在明确各需求的业务优先级时，PD 将 A 需求划为 P0，而 BCD 需求是 P1，业务优先级都比较靠前，但实际执行过程中，我最先启动的却是 BCD 的设计，而它们成本相对较低、设计和部分开发排期相对较短。 对于项目组来说，就如上一节里所说，快速完结部分需求的设计，可以让整个项目组资源在更早的时候就有投入，更好地分散压力。对于交互设计师来说，多个短周期需求先并行，在一个需求进入初稿产出-多方确认完成（在大公司里，多方反复沟通和确认修改花费的时间成本有时会比设计本身大不少，出现一段时间内找不到人确认不了方案又不方便继续做设计的情况）的空白期内，正好可以把另一个需求也完成得差不多，最终差不多同时评审打包交付；而快速完结掉这些业务优先级不低的短周期需求后，就可以集中精力投入到设计思考成本更高、周期更长、自主驱动力更足的事情中去了，而不是在执行后者时被反复分心干扰（对于我这种讨厌分心的人来说，能集中精力做事情还是很重要的）。
谨慎对待全局重构，充分验证再执行 刚被 Prd 轰炸完时，我一度为自己酝酿已久的全局信息架构、一级页面整体重构优化的大计划被暂时搁浅而不爽，也考虑过将新的业务产品需求纳入进这个大计划里整体考虑。 但这在产品周期里不太现实，这个大计划从用户体验设计师的视角来看可能是一次治本的体验提升，让信息架构和功能流程得到充分的精简优化，但激进的变革也容易让用户在固有认知操作习惯下无所适从，引发强烈的用户反弹。而我们的产品又缺失合理的数据埋点，无法通过直观的某几个数据指标升降情况来判断改版的成败，如果有几个声音很大的反对用户跳出来，也拿不出合理的数据论证来支撑自己的观点。 正是基于这样的风险预判，师兄建议我谨慎对待全局信息重构的事情，等用研有了专业的调研输出、充分验证想法后再正式介入考虑方案，而不是自己随便总结出一些体验不好（从专业视角来看这些痛点也许都客观存在，但缺乏充足的用户研究反馈作为论据）的地方就开始大动干戈；而另一个建议延后跟进整体重构的理由则是「先有菜再摆盘」，2.0 中新增了很多需求模块，先把这些模块涉及到的独立页面都分解设计完成，再统一考虑整合入口的信息架构，如果一开始就想统筹兼顾，则容易陷入很长一段时间都没有结果产出的境地，万一中途发生方向等不可控变更也会波及到更广的范围，需要复出更高的代价来修正。 
