为什么设计师也要学会判断优先级

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

直到今年碰到这两件事情，我才有了不一样的熟悉。

不会判断优先级的悲剧

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

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

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

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

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

题目出在哪里

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

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

如何围绕营业目标及用户价值判断优先级 一、高风险的大手术照旧低风险的物理疗法

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

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

二、迭代开发与增量开发

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

用一幅图来说明（图片来源于网络）：

迭代开发

增量开发

迭代开发中，每一次的交付物都是完备、用户可用的。如同上图的蒙娜丽莎像，虽然第一幅图比较粗糙，但是用户可以看到完备的轮廓，不影响对团体的理解，而且过程比较可控，可以随时修改；而增量开发中，每一次的交付物虽然邃密，但对用户来说不可用，必须悉数完成才能拼成一个完备的、用户可用的产品，且风险不可控，一旦发现之前的存在题目，也很难回头了。

而学过绘画的人也都知道，画画是先从轮廓开始、渐渐迭代、邃密化的过程，而不是增量的过程，除非是画过千百次如许的画，已经完全胸中有数。但显然这对我们如许一个创新型、充满各种不确定的产品来说不太合适。

三、MVP原则拆分需求

如今我们已经确定要以迭代开发而非增量开发的情势来拆分需求了，那么详细该怎样分解呢？

在培训课堂上我们做了如许一个演习：听课人员分成两个小组，每个小组的成员分别在贴纸上写出本身天天早上从起床到出门必要做的所有事情，组长把所有的内容汇总，再分类展示，得到用户故事地图:

先生问大家，整个过程也许要多久？大家回答：一个小时左右。先生说：假设有一天你起晚了，并且这一天你要参加一个异常紧张的会议，不能迟到。如今你只有五分钟的时间出门，你会从其中选择哪些？

大家同等选择了上厕所、刷牙、洗脸、换衣服、关门、锁门这几项。虽然大部分事项被省略掉了，但其实并不影响大家出门。这也就是MVP的理念，即“最小化可行产品”，它无疑是简陋的、粗糙的，但是它是完备的、基本流畅的、用户可使用的产品。如许，既可以在最短时间内有所产出，又保证了用户体验的延续性（不至于由于砍掉太多功能而根本无法使用）；同时使用这种方法，可以让项目所有成员都看到一个完备的用户场景，可据此快速讨论出优先级，避免“只见树木、不见森林”的情况，节省了大量的时间。

对于一个老产品的快速迭代，通过这种方法也可以快速判断出功能的优先级。然后我们可以重点看该功能对应的用户反馈，归纳出题目的核心缘故原由，得出解决方案，再通过营业价值、题目程度、预计结果、开发成本等因素综合判断详细的优先级。

最后总结一下心得：曩昔我会认为排优先级是产品经理考虑的事情，设计高质量的方案才是设计师的事情。就好比我用专业技能打造一个完善的工艺品，我不应该由于对方买不起就自降身价，偷工减料。而如今我会认为根据市场必要判断该产出什么样的工艺品，如何把握制作节奏，如何更快市场化才是最考验能力的事情。在此与广大设计师共勉！

本文系作者@刘津 授权发布。

注：相干网站建设技巧阅读请移步到建站教程频道。

>> 查看更多相似文章