在上一篇文章中，浅浅地讨论了什么是设计的价值，并得出一个没什么用的结论：设计的价值是产出更优更合理方案。那么在产出更合理方案之前，如何发现原方案的问题并推动更合理的方案落地？有些问题在分析之后，我们可以归类为明显的逻辑BUG，这类大BUG，因为问题明显，在与上游讨论的时候，只要理由充分，可以很快的推动自己的想法落地。但是有些并不是，如何提出这类问题，并更好的与上下游协作且推动方案落地呢？初入公司时，我也比较懵逼，好在身边都是优秀的同事，观察他们处事之余，我复盘了如下经验。
记得刚进公司的时候，因为与之前的公司协作流程有很大不同，无法很快适应公司节奏，公司业务很多，而交互加上组长，也就只有三位同学。由于大多产品多重视业务，原型方案第一时间给到的时候未必最优，而视觉同学多重视视觉的呈现，忽略背后逻辑，由此导致返工多，整个上下游工作效率低下。所以交互在整个工作流之中，最重要的一个职责就是审核评估产品经理给到的原型，在权衡业务和用户的角度，为下游的视觉同学排坑。
而我遇到的第一个难题就是，如何在众多需求中，判断需求优先级，且快速审核产品经理的方案，并提出合理建议，同时推动合理方案落地。
01 快速了解业务、用户
无论你是设计还是其他，作为刚入职的新人，应该需要尽快了解公司的业务。除了看公司内部资料，我把产品经理的历史PRD文档都重新看了一遍，在这个过程中，可以帮助自己了解整个业务走向，以及目前现存的问题，甚至于之后的业务重点发力方向。
看文档也有讲究，公司那么多产品经理，要把所有的文档看完，也要花费不少时间。由于我们公司的文档都是共享的，根据不同的业务线，我一般先看我主要对接的业务线的产品负责人的文档，负责人会清晰地记录他所属团队每个成员负责的版块，以及每一个季度的产品迭代方向。其次，其他业务线虽归属其他交互对接，但也要在空闲之间做了解，有时候，某个功能改版，会牵扯到其他业务线，而新来的产品经理并未做全局了解，这时候就需要交互在其中做风险预警。
除此以外，平常也多看看竞品，记录每个竞品每周迭代的东西，判断他们的方向。有些公司，这个工作会交给用研部门，用研会在每周周报里附上这些报告。如果对方周报没有@你，记得钉他一下。
以上，还有很多其他方法，网络上多搜集相关的行业资料，学会利用公司各种资源，帮助你站在前瞻视角，去了解整个业务全局，清晰业务走向。
02 快速了解对接的人
清楚对接需求的上下游。上游是哪个产品经理？他是什么背景？主负责哪一块业务？留心这些，会快速对需求有个大概的判断。
比如之前接到的一个需求，某产品经理期望在商详页中加科普的内容，且为了省开发周期，用户在商详页跳转的科普内容二级页，承接的是社区内容页，有很多二跳到社区的出口。
按照当前产品经理的PRD描述，本平台多品类对于小白用户具备较高价值认知以及学习门槛，期望通过「品类科普」形式提升用户对品类的兴趣度，进而促进后续交易转化。这听起来是好事，但是加在商详页，按照这样的方式，会让用户在原有的交易链路跳出，反而影响用户决策。且即使他们有意向做PGC科普，短期内的内容质量还有待考证，目前社区里的内容恐怕接不住他们想给用户的好意。回头看看这个产品经理，最近转到平台运营业务线，社区归他管。这看起来就是个背KPI的需求，本质目标是想为社区导流。
每个需求都是每个人做的，不同的人在做一个需求的时候，会有不同的考量，如果不清楚这个人，你也就无法摸清他需求的本质目标是什么。多留意每个人的特点，看清楚一些事实，而不是只看需求本身，跳脱它，你会对方案背后存在的问题有个更直观地认识。进而，针对这些问题本质，才能灵活攻破寻求新的解决方案，或者就问题本身给到产品经理他所需要的帮助。这些问题可能就是方案本身，或许是对方所需的对接资源，或许可能就老板认定的方案，需要你从中协助他和老板沟通所处的问题等等。
03 了解需求真正目标
这个需求的真正目标是什么？是的，真正的目标，就像上边的一个案例；还有一些需求，可能就是某个用户的一个想法，想清楚用户想法背后真正的原因，才能据此提出更合理的方案。这点大家应该都比较清楚，不再赘述了。
04 了解产品经理的方案
这个方案投资回报比怎样？他为什么要定这个方案？基于开发成本的考量？想要快速上线验证可行性？这个方案有什么风险？（会不会影响交易转化？会不会牵扯到其他业务线？有没有和其他业务线负责人沟通过风险？）目前的方案是接近目标还是远离目标？有没有其他方案可以替代他的方案？
就像上边说的，产品经理的每个方案背后都有其考量因素，我们不能只是看到问题之后，然后傻乎乎地直接向他发问：你为什么要这样做？这跟直接骂他「傻X」没什么区别。他的目标是希望UED能尽快将他的需求排上期，而不是需要一个设计在其中挑毛病。试着这样说：我想到一个其他方案，你看可不可行。如果对方觉得确实还不错，恭喜你，多了个战友，下次他遇到难题的时候，会直接找你一起想解决方案；如果对方不认同，那你也在不清楚对方为什么这样做的基础上，不伤和气之下，找到了更多原因。去探讨，而不是发问。
还是上边的案例，在了解产品经理的书面目的之后，我们告知风险，保守起见，建议先在社区试运营PGC科普内容+带货的模块，由内容导商品。如果看得人确实多，再将科普内容加入其他场景承接小白用户。
05 确定解决方案
在分析完之后，就该确定方案了。这个阶段我大致归类为两种情况，第一种情况：产品经理原方案不合理，有严重体验问题，在告知风险之后，依旧不愿意更改。
比如上边提到的那个案例，我们提出新的方案之后，产品经理依旧坚持原方案。这种情况下，告知方案可以先铺少量，不要铺全量；另外如果对方没有验证方案的话，让对方给出验证方案，评估验证方案可行性。我们让产品监控访问用户的复购和购买行为，商详页入口PV点击率，下单转化率，点击科普内容后返回率，下单转化还要看看是不是同品类的，验证教育内容的有用性…
另外一个乐观的情况就是，对方认同提的修改建议，并协助输出新的方案。在所有方案输出后，再交至下游，并验收上线。
