来源:优设 作者:窒息红Leon
如何判断产品经理提出的需求该不该接?今天窒息红Leon通过自己思考、请教前辈，列举了几条产品需求是否该接的「小原则」，希望通过这些依据来帮助自己判断需求的合理性。
对大团队来说，交互设计师常常会接触到不同产品线的需求，比如之前两周我就需要同时与四五个产品经理合作。产品经理是需求方，他们会带着 idea 以及 PRD 文档来找设计师，告诉我们需求的具体内容、目标、排期等等。不过，由于设计资源有限(开发资源也一样)，并不可能所有的需求都被能处理，，所以在产品经理提出需求的同时也需要设计师能够对需求的合理性有自己的判断。
需求的合理性判断非常依赖交互设计师对业务的熟悉程度，而新人却又在这方面最匮乏。如果对需求来者不拒，或者也没有帮助产品经理改善需求内容、指出不合理的部分，那可能忙忙碌碌一周下来发现自己完全没有时间思考，真的变成了纯粹的「执行者」。不是说执行者不好，而是执行者的不可替代性更弱，如果每一个阶段的工作不能串联起来、不能目标一致，可能就难以完成整个业务的目标，当然也难以体现自己的价值。
通过自己思考、请教前辈，我列举了几条产品需求是否该接的「小原则」，希望通过这些依据来帮助自己判断需求的合理性。不过，所谓的「小原则」也并不是绝对的，工作时可千万不能死脑筋地认为不满足某条原则的需求一定不做，几条原则都需要综合起来考虑。
原则一：符合主体业务目标的需求该接
大部分团队在年度、季度之初都会召开动员会议(又称 Kickoff)来宣布本阶段的业务重点及目标。对前线设计师而言，团队的主体业务目标也自然应是自己本阶段的工作重心和标杆。所以，深入理解团队的业务重心或发展路径是一件看起来虚但实际上非常非常重要的事，只有明白了团队最终想要什么成果，才能调整自己工作中的导向。
事实上，这是一种对需求合理性进行考量的首选方式。当面临业务方提过来的需求，首先就问问自己：
这件事与团队整体目标是否一致?
能够多大程度提高这个目标的达成率?
是否能够和已有的模块配合产生联动效应?
持续的规划和安排是怎么样的?
而当一个需求明显偏离团队业务目标时，就必须勇敢地向产品经理指出来。
最困难的是，日常中很多需求并不是简单的非黑即白，也不像代码一样只有True和False。因此在实际工作中必须时刻关注业务动态，避免只从小处着眼。同时，经常做竞品分析也可以帮助你进行决策。
总而言之，符合团队业务大方向的需求，肯定是需要优先处理的。
原则二：干扰用户主要目标的需求不接
对交互设计师这样的岗位，有一种被称为「中台能力」的素质非常重要。简而言之，业务方常常更多地关注自己所负责的业务或产品线，而有可能忽视了产品的主要功能和用户在产品中的主要目标。
知乎首页Feed流的主要功能是什么——是浏览关注对象的动态，本质上是找到自己感兴趣的话题;淘宝下单页的主要目标是什么——是了解宝贝付款信息、物流信息，并完成支付。那么，如果业务方的需求仅仅能够满足它自身的业务目标但却影响这些主要任务，就需要慎重对待了。
空间不是无限的，当在有限的页面里突出或增加了某个内容，势必会影响到其他功能。如果新内容的突出能够为产品整体提供帮助或在不影响其他功能的前提下提升某个数据，那无疑是个好需求。但如果需求过分强调自身目标，抢占了其他功能的空间，过分干预了用户正常使用产品的路径，就不应该接了。
因此，承接各方需求的设计师在日常工作中经常担任「中台」，判断不同需求之间是否融洽，是否影响到了主线，是否因小失大。这也是判断需求是否合理的一种重要标准。
原则三：用户群小但成本大的需求不接
有些需求本身是非常合理的，但是如果它仅能满足一小部分用户的诉求，却又可能花费较大的研发、设计成本，那就应该慎重一些。为什么我们常说不要把自己当成典型用户，其中一个原因就是从个体出发的诉求往往没有代表性，而这又是新人常犯的错误。
举个例子：以前我针对微信群的信息沉淀设计过很多有趣的小改进，甚至还包括群内分频道聊天的功能。但事实上，很多功能可能只对社群运营者本身有较大好处，或者对少数超重度社群玩家有益，而绝大部分普通社群用户都只是把这里当做一个闲聊的地方。
这种情况下，你说做这些需求正不正确?肯定是正确的。但如果花费了较多的人力物力实现需求后只满足了那一小部分用户的诉求，对大部分用户都没有实质性的好处，显然就显得很「不划算」了。
因此，明确评估投入产出比非常重要。
原则四：拓展性弱或互扰强的需求不接
需求的拓展性和独立性是一对看起来比较矛盾但实际上结合紧密的属性。
所谓拓展性，是说有些设计可能不仅仅只在当前这个页面里生效，后期也可能会拓展到其他地方。举个例子，电商产品中，我们针对家装类产品设计了上门安装的服务，那具体在订单页需要用户填写安装地址以及一系列其他要求。
后期，除了家装以外，可能大电器也需要送货上门和安装。因此，在前期设计的时候就必须考虑后面可能还有那些业务会用到这个功能，也要考虑不同业务的页面里是否都能妥善安放新功能。
说到在不同的业务中是否都能妥善安放新功能，其实也就是设计独立性的要求。不同的业务场景会有不同的视觉呈现，也许一个新需求在A场景中通过增加一个Tab就可以实现，但是拓展到B场景后就发现B场景已经非常拥挤，完全放不下这个Tab了。那我们就会说这个Tab的设计独立性不够好，或者说容易发生互扰。因此，在A场景中设计需求的时候就应该综合考虑B场景的情况。
综合来说，拓展性好、互扰性弱的需求可以优先处理，而设计师本身也可以通过设计方案来提高需求这两个属性上的表现能力。
原则五：明显提升个人能力的需求该接
工作以前开玩笑说，小公司做业务是看准了一个方向再跑，而大公司是选十个方向先跑，只要有一个跑对了就赚。毕竟小公司资源有限，所有力量必须用在刀刃上，而大公司讲究速度，快速试错快速占领市场。那么，如果不幸在团队中跑了一个错误的方向，难道这一阶段的工作就没有意义了吗?
显然不是的。试错之后，对团队而言获得了宝贵的经验，而更重要的是，个人获得了成长。幸运的是，大公司里不仅仅要求你为团队做出贡献，每次绩效考评也都会问你希望从团队获得什么。
所以，在承接需求的时候分一部分精力来考虑这个任务是仅仅机械地完成即可，还是能够从中挖掘出更多个人能力的提升机会，也非常重要。都说具有挑战性的任务帮助人成长，这一点也不错。面对与更厉害的同事合作，或者接触以前未涉足过的业务场景，或者创新性地使用新工具和新设计手法，都是能够让自己快速成长的有效方式。
遇到能够明显提升个人能力的需求，而又不违反前面几个原则时，就毫不犹豫地扑进去吧。
