分身乏术？来学学交互设计的优先级判断与排期协同.pdf

分身乏术 ？来学学交互设计的优先级判断与排期协同 在被密集需求轰炸 （需求 身都具备一定合理性 ，不包括那种应该拒掉不接的需求 ），同时自己还 有一堆想自发驱动去做的事情时 ，交互设计师该如何进行合理的设计优先级判断 ，分解需求排期推 进呢 ？来看今天的实战经验 ！ 在以往的项目中 ，我通常是完成一个设计需求的评审交付后 ，再去跟进下一个需求 ，而在需求相对 空闲的时间段里则做做系统的产品体验分析、构思想优化点的产品设计草案 ，整理设计组件和规 范等 ，并行应对 3个需求 （不包括日常迭代的小需求 ）的情况很少。 但在几周以前 ，项目组的 PD 们在两天内拉上设计和开发 ，一口气评审了 5 个 Prd ，在评审快结束 的时候 ，我已经没有任何专心听下去的心情 ，而是陷入了深深的苦恼和烦闷中去 ：一方面是感觉在 密集需求轰炸面前分身乏力、精力难以集中 （我是那种喜欢专注地做完一件事情再管其他的性格 ） ，另一方面则是因为之前干劲十足自发驱动的网站信息架构整体重构计划因此被延期 ，感觉自己又 变回了那个 「接需求的」。 不过在师兄和 PD 们的帮助下 ，我逐渐对这一大波密集需求有了清晰的优先级判断和排期规划 ，在 没怎么加班的情况下较为有条不紊地按期产出了其中 3 个需求具体的设计解决方案 ，甚至在 PD 需 求的基础上还完成了更多相关产品环节的设计 ，将单一页面改进推进成了相关完整场景下工作流的 整体优化。优先级与排期看似是 PD 们主导的事情 ，但交互设计师同样应该重视这一环节 ，而不是 让自己陷入被动加班应对不合理需求节奏、或是自己随心所欲但却拖累一群项目组小伙伴加班的 境地。 在被密集需求轰炸 （需求 身都具备一定合理性 ，不包括那种应该拒掉不接的需求 ），同时自己还 有一堆想自发驱动去做的事情时 ，交互设计师该如何进行合理的设计优先级判断 ，分解需求排期推 进呢 ？ 交叉并行 ，配合项目组成员进度 在我们产品 2.0 计划的这波需求 （有 PD 提出的 ，也有设计师想自发改进的 ）中 ，有重视觉轻交互 的运营设计 ，有界面简单但牵涉业务逻辑复杂、开发成 高的流程设计 ，有视觉需求弱、交互甚至 产品直接 Cover 的后台设计 ，有重情感化互动、需要设计师主动思考探索的跨 PC、移动平台创新 设计 ，还有影响面最广泛的全网整体重构…… 在这些对于各职能来说工作量不一的需求面前 ，如果按照传统的瀑布式 「Prd/用户研究 – 交互设计 – 视觉设计 – 前后端开发」流程逐一完成需求交付的话 ，当前面的职能花上较多时间来考虑解决方 案时 ，后面的职能就会在这段时间内变得无所事事 ，而之后又可能变得疲于奔命。 （举例子来说 ， 如果我先做需要较长思考和设计时间的某创新设计 ，花掉一周半的时间 ，这段时间我后面的视觉和 开发资源都会空闲 ；而等我交付掉了这个页面 ，再用两天不到的时间做完了某流程设计 ，对开发来 说之前的需求才刚启动 ， 又来了一个开发成 更高的 ，压力就会变大不少 ） 根据师兄和 PD 们的建议安排、以及开发们给出的排期估计 ，在整体 Deadline 已定 ，部分需求业务 优先级相近的前提下 ，我选择优先投入几个重开发/重视觉 ，而交互产出周期相对较短的需求 ，这样 视觉/开发们可以在更早的时候就介入 ，而不是等到接近 Deadline 时分身乏力 ；与此同时 ，用研也 启动对于整体重构这类计划的前期用户调研验证 ，而我在这个相对较长的周期里先完成那些明显能 帮助达成业务目标、满足用户诉求的设计 ，等用研结果出来之后 ，再跟进那些有较大影响面、风险 和不确定性 （可能激发强烈反弹 ）的设计。这种职能交叉并行的推进方式 ，可以将大家的压力更合 理均匀地分解 ，而不是在某一处发生 「集中堵塞」。 优先快速打包完结低成本、短排期的需求 在明确各需求的业务优先级时 ，PD 将 A 需求划为 P0 ，而 BCD 需求是 P1 ，业务优先级都比较 靠前 ，但实际执行过程中 ，我最先启动的却是 BCD 的设计 ，而它们成 相对较低、设计和部分开 发排期相对较短。 对于项目组来说 ，就如上一节里所说 ，快速完结部分需求的设计 ，可以让整个项目组资源在更早的 时候就有投入 ，更好地分散压力。对于交互设计师来说 ，多个短周期需求先并行 ，在一个需求进入 初稿产出-多方确认完成 （在大公司里 ，多方反复沟通和确认修改花费的时间成 有时会比设计 身 大不少 ，出现一段时间内找不到人确认不了方案又不方便继续做设计的情况 ）的空白期内 ，正好可 以把另一个需求也完成得差不多 ，最终差不多同时评审打包交付 ；而快速完结掉这些业务优先级不