案例实战分析！为什么设计师也要学会判断优先级？

编者按：今天的案例也是同学们日常工作中会遇到的问题，如何兼顾业务目标和用户体验？这里边涉及到的判断优先级问题，其实大有学问。掌握这个思路，相当于半个产品经理，以后和产品的争执会大大减少，来自阿里交互专家@刘津legene ，特别推荐阅读。

我的主管经常对我们说：产品经理最重要的能力就是判断优先级，不然就不叫产品经理，而是需求经理。以前我听了总是不以为然，觉得判断优先级就是优先做紧急的和实现成本低的需求，毫无技术含量；而设计师需要从用户的整体使用流程综合考虑，给出一个理想而完整的方案。所以很长一段时间，我都觉得产品经理大多是在做救火的事情，而只有设计师才有条件和能力从用户的角度全盘考虑，从根本上解决问题。

直到今年遇到这两件事情，我才有了不一样的认识。

不会判断优先级的悲剧

年初时，主管发动了一场关于易用性方案的PK活动。一个产品经理拿出了弹层引导的方案（在每个页面都有若干引导），当时我简直笑坏了，心想这不是在破衣服上打补丁吗，完全是治标不治本的做法；我拿出了自己的方案：从深层次分析易用性不好的原因，重新梳理流程，给出了一个全新的方案，该方案从根本上改进了易用性问题，使用流程大幅缩减，信息结构简明易懂。当时我讲完我的方案，收获了全场的掌声。很多人表示开了眼界，从没想过还可以这么做，也见识了交互设计的专业性。

但最后主管选择了弹层的方案。理由是我们承办了一个活动，短期内将有非常大量的用户迅速涌入，而目前产品的易用性存在很大问题，我们必须在最短时间内以最小代价解决。两个方案摆在面前，怎么判断优先级，不是看哪个方案好就选哪个，而是要围绕业务目标。

我当时觉得主管说的也对，于是过了一段时间，我选择提出离开，因为在目前的业务环境中实在找不到自己的位置。当然最后我没有离开，也许是因为不想向困难低头，觉得自己还有很大提升空间，早晚有一天会克服困难。

最近一段时间，易用性的事情又重启了。因为之前经过几个月“打补丁”的改进方式，易用性还是没有很明显的起色，主管很不满意，让我也进入这个项目好好看看。我觉得机会终于来了，是时候把我当时的思路和方案重新拿出来了（由于时间已经过去大半年，业务方面发生了很多变化，于是我的方案也有所更新，但思路基本不变，还是从整体使用流程考虑，给出较完整的方案）。

review的时候主管说不想看这些看似正确却抓不住重点的东西，要看具体改进了哪些点。幸好我早有准备列出了一个list，里面罗列了和线上相比具体的改动点。主管一条一条的看，问我：你觉得哪条是最紧急的，是有关业务生死问题的？我愣了一下，回答：几乎都不是。主管说你们要把所有改动的list列出来，根据业务目标排好优先级，不然你们短期是一定拿不到结果的。

当时我很不解，我一直觉得用户体验是一个完整的过程，不是一个个零散的点。怎么能用改bug的方式去改进用户体验呢。以前好歹我也做过几年的交互设计，也没出现过什么问题，为什么在这里就玩不转呢。

问题出在哪里

我仔细思考了之前做交互设计的经历，发现忽略了这样几个客观事实：一是产品经理在向设计师提需求之前，其实已经分解并排好优先级了；二是改版和日常迭代往往是分开的，很多日常迭代的需求可能和界面无关，产品经理自己消化掉了；三是对于现在在做的复杂平台型产品，功能逻辑的设计远大于界面影响，所以必须从表层使用问题渗透到功能层面，易用性问题才有解（对比流畅而完整的设计方案，功能是相对独立的）。由于我们这里产品经理和交互设计师的分工并没有那么明确，当大家共同own易用性改进这件事情时，我还在按照以前交互设计师的思路做事情，而没有根据业务节奏排列优先级sense的缺点也就暴露无疑了。

产品经理侧重于从产品整体角度（包括业务目标、功能逻辑、技术资源、用户体验）去考虑问题，并排列优先级；而设计师侧重于在既定优先级判断基础上从用户角度考虑界面设计。太过考虑业务目标，难免忽视了用户体验；而太过于考虑用户体验，短期内又很难达成业务目标。怎样保证在产品设计过程中最大限度的不影响体验，又能按照业务要求拿结果呢？这里面其实大有学问。

如何围绕业务目标及用户价值判断优先级

一、高风险的大手术还是低风险的物理疗法

由于我们的产品有比较复杂的历史背景，所以易用性问题非常突出：功能设计复杂而冗余、信息结构冗余、操作流程复杂缺乏引导，所以我们首先要面临一个选择：是根据收集到的问题逐一改进，还是整体重构。之前就这个问题，我和产品经理发生了巨大的分歧，我强烈建议整体重构，因为用户的问题其实都是建立在目前糟糕的设计上的，所以不能哪儿痛医哪儿，而是要抓住问题根源，彻底根除；而产品经理的意见是先改容易改的以及可以快速见到成效的用户问题，这样才能拿到结果。

其实从产品整体视角来看，答案很明显：老用户已经养成较稳定的使用习惯，且目前正处在商业化进程中，一切不容有失；而新用户主动使用的场景还不明显。所以小步快跑的方式是最稳妥的。但是如果是站在设计师的角度来看，就比较容易迷失在其中。这也是我之前一直强调的“眼界”和“格局”，说出来容易，但真正做到其实很难。

二、迭代开发与增量开发

现在我们已经确定不做整体重构，而是定期、快速的产出，那么分解需求的标准、形式应该是怎样的呢？正巧上周公司有一个相关的培训，我听了后觉得收获很大。当时老师举了一个例子：如果你有五块钱，你又不想一下子花出去，你是拆成五个一块钱，还是撕成五瓣呢？如果是拆成五个一块钱，那每张一块钱都是可以立即花出去的，而撕成五瓣的话，每一瓣都无法使用了。这也是迭代开发的精髓，即把大块的需求拆分成独立的、可交付的若干完整需求，再开发上线。