交互设计的优先级判断与排期协同

相关推荐

交互设计的优先级判断与排期协同

　　交互设计师该如何进行合理的设计优先级判断，分解需求排期推进呢?下面是小编精心整理的交互设计的优先级判断与排期协同，欢迎大家分享。

　　交互设计的优先级判断与排期协同

　　在以往的项目中，我通常是完成一个设计需求的评审交付后，再去跟进下一个需求，而在需求相对空闲的时间段里则做做系统的产品体验分析、构思想优化点的产品设计草案，整理设计组件和规范等，并行应对 > 3个需求(不包括日常迭代的小需求)的情况很少。

　　但在几周以前，项目组的 PD 们在两天内拉上设计和开发，一口气评审了 5 个 Prd ，在评审快结束的时候，我已经没有任何专心听下去的心情，而是陷入了深深的苦恼和烦闷中去：一方面是感觉在密集需求轰炸面前分身乏力、精力难以集中(我是那种喜欢专注地做完一件事情再管其他的性格)，另一方面则是因为之前干劲十足自发驱动的网站信息架构整体重构计划因此被延期，感觉自己又变回了那个「接需求的」。

　　不过在师兄和 PD 们的帮助下，我逐渐对这一大波密集需求有了清晰的优先级判断和排期规划，在没怎么加班的情况下较为有条不紊地按期产出了其中 3 个需求具体的设计解决方案，甚至在 PD 需求的基础上还完成了更多相关产品环节的设计，将单一页面改进推进成了相关完整场景下工作流的整体优化。优先级与排期看似是 PD 们主导的事情，但交互设计师同样应该重视这一环节，而不是让自己陷入被动加班应对不合理需求节奏、或是自己随心所欲但却拖累一群项目组小伙伴加班的境地。

　　在被密集需求轰炸(需求本身都具备一定合理性，不包括那种应该拒掉不接的需求)，同时自己还有一堆想自发驱动去做的事情时，交互设计师该如何进行合理的设计优先级判断，分解需求排期推进呢?

　　交叉并行，配合项目组成员进度

　　在我们产品 2.0 计划的这波需求(有 PD 提出的，也有设计师想自发改进的)中，有重视觉轻交互的运营设计，有界面简单但牵涉业务逻辑复杂、开发成本高的流程设计，有视觉需求弱、交互甚至产品直接 Cover 的后台设计，有重情感化互动、需要设计师主动思考探索的跨 PC、移动平台创新设计，还有影响面最广泛的全网整体重构……

　　在这些对于各职能来说工作量不一的需求面前，如果按照传统的瀑布式「Prd/用户研究 – 交互设计 – 视觉设计 – 前后端开发」流程逐一完成需求交付的话，当前面的职能花上较多时间来考虑解决方案时，后面的职能就会在这段时间内变得无所事事，而之后又可能变得疲于奔命。(举例子来说，如果我先做需要较长思考和设计时间的某创新设计，花掉一周半的时间，这段时间我后面的视觉和开发资源都会空闲;而等我交付掉了这个页面，再用两天不到的时间做完了某流程设计，对开发来说之前的需求才刚启动，又来了一个开发成本更高的，压力就会变大不少)

　　根据师兄和 PD 们的建议安排、以及开发们给出的排期估计，在整体 Deadline 已定，部分需求业务优先级相近的前提下，我选择优先投入几个重开发/重视觉，而交互产出周期相对较短的需求，这样视觉/开发们可以在更早的时候就介入，而不是等到接近 Deadline 时分身乏力;与此同时，用研也启动对于整体重构这类计划的前期用户调研验证，而我在这个相对较长的周期里先完成那些明显能帮助达成业务目标、满足用户诉求的设计，等用研结果出来之后，再跟进那些有较大影响面、风险和不确定性(可能激发强烈反弹)的设计。这种职能交叉并行的推进方式，可以将大家的压力更合理均匀地分解，而不是在某一处发生「集中堵塞」。

　　优先快速打包完结低成本、短排期的需求

　　在明确各需求的业务优先级时，PD 将 A 需求划为 P0，而 BCD 需求是 P1，业务优先级都比较靠前，但实际执行过程中，我最先启动的却是 BCD 的设计，而它们成本相对较低、设计和部分开发排期相对较短。

　　对于项目组来说，就如上一节里所说，快速完结部分需求的设计，可以让整个项目组资源在更早的时候就有投入，更好地分散压力。对于交互设计师来说，多个短周期需求先并行，在一个需求进入初稿产出-多方确认完成(在大公司里，多方反复沟通和确认修改花费的时间成本有时会比设计本身大不少，出现一段时间内找不到人确认不了方案又不方便继续做设计的情况)的空白期内，正好可以把另一个需求也完成得差不多，最终差不多同时评审打包交付;而快速完结掉这些业务优先级不低的短周期需求后，就可以集中精力投入到设计思考成本更高、周期更长、自主驱动力更足的事情中去了，而不是在执行后者时被反复分心干扰(对于我这种讨厌分心的人来说，能集中精力做事情还是很重要的)。

　　谨慎对待全局重构，充分验证再执行

　　刚被 Prd 轰炸完时，我一度为自己酝酿已久的全局信息架构、一级页面整体重构优化的大计划被暂时搁浅而不爽，也考虑过将新的业务产品需求纳入进这个大计划里整体考虑。

　　但这在产品周期里不太现实，这个大计划从用户体验设计师的视角来看可能是一次治本的体验提升，让信息架构和功能流程得到充分的精简优化，但激进的变革也容易让用户在固有认知操作习惯下无所适从，引发强烈的用户反弹。而我们的产品又缺失合理的数据埋点，无法通过直观的某几个数据指标升降情况来判断改版的成败，如果有几个声音很大的反对用户跳出来，也拿不出合理的数据论证来支撑自己的观点。

　　正是基于这样的风险预判，师兄建议我谨慎对待全局信息重构的事情，等用研有了专业的调研输出、充分验证想法后再正式介入考虑方案，而不是自己随便总结出一些体验不好(从专业视角来看这些痛点也许都客观存在，但缺乏充足的用户研究反馈作为论据)的地方就开始大动干戈;而另一个建议延后跟进整体重构的理由则是「先有菜再摆盘」，2.0 中新增了很多需求模块，先把这些模块涉及到的独立页面都分解设计完成，再统一考虑整合入口的信息架构，如果一开始就想统筹兼顾，则容易陷入很长一段时间都没有结果产出的境地，万一中途发生方向等不可控变更也会波及到更广的范围，需要复出更高的代价来修正。

　　交互设计的优先级判断

　　在交互设计过程中，优先级判断是首要任务，它决定了哪些设计需求应该首先得到满足，哪些可以稍后处理。以下是一些判断优先级的关键因素：

　　1. 业务目标：

　　评估设计需求对业务目标的影响程度。那些能够显著提升用户体验、增加用户粘性、提高转化率或降低用户流失率的需求应优先考虑。

　　2. 用户价值：

　　分析设计需求对用户价值的提升作用。高频次、高重要性且用户反馈强烈的需求应给予更高的优先级。

　　3. 开发成本：

　　考虑设计需求的实现难度和开发成本。在资源有限的情况下，应优先处理成本低、见效快的需求。

　　4. 风险与不确定性：

　　评估设计需求可能带来的风险和不确定性。对于存在较大风险或不确定性较高的需求，应谨慎对待，并可能需要更多的前期研究和验证。

　　5. 产品阶段：

　　根据产品所处的不同阶段（如初期、成长期、成熟期等）来调整优先级。在初期阶段，可能更注重核心功能的完善和用户体验的提升；而在成熟期，则可能更关注细节优化和性能提升。

　　排期协同

　　排期协同是确保设计需求按时、按质完成的重要环节。以下是一些排期协同的关键策略：

　　1. 明确截止日期：

　　与项目组成员共同确定项目的截止日期，并以此为基准制定详细的排期计划。

　　2. 分解任务：

　　将复杂的设计需求分解为若干个具体、可执行的任务，并为每个任务分配责任人、截止时间和所需资源。

　　3. 交叉并行：

　　采用交叉并行的推进方式，将不同设计需求的任务分配给不同的设计师或团队，以充分利用资源并提高效率。同时，关注项目组成员的进度，确保各项任务能够按时完成。

　　4. 定期评审与调整：

　　定期组织设计评审会议，对已完成的设计方案进行评估和反馈。根据评审结果及时调整排期计划和任务分配，确保项目顺利进行。

　　5. 沟通协调：

　　加强与项目组成员之间的沟通协调，确保信息的及时传递和共享。对于遇到的问题和困难，及时寻求帮助和支持，共同解决。

　　6. 风险管理：

　　识别潜在的风险因素，并制定相应的应对措施。对于可能出现的延期或变更情况，提前做好准备和调整计划。

　　实际案例

　　在以往的项目中，交互设计师可能会面临多个设计需求同时出现的情况。此时，合理的优先级判断和排期协同显得尤为重要。例如，在评审多个Prd时，交互设计师可以根据业务目标、用户价值、开发成本等因素综合评估各个需求的优先级，并制定相应的排期计划。通过交叉并行的推进方式，可以在有限的时间内完成多个设计需求的任务，并确保项目按时、按质完成。

　　综上所述，交互设计的优先级判断与排期协同是确保项目成功的关键。通过合理的优先级判断和科学的排期协同策略，可以充分利用资源、提高效率，并为用户提供更好的产品和服务。

【交互设计的优先级判断与排期协同】相关文章：