当你和产品，交互还有开发测试在进行UI评审时，他们凭借着对产品的理解，以及自认为站在用户的角度试图来说服设计师。然后设计师同样的习惯性从自我经验出发，主观下结论，并抗拒他人对设计方案的建议。如何停止这类无意义的争吵？学会科学找到用户需求很重要，今天这篇好文帮你掌握起来。
各位设计师有没有经历过无休止的针对一个按钮，一个线条，一个颜色的争论？
a：你用这个颜色用户（我）会觉得太抢眼。
b：你这个按钮做了太小用户（我）会觉得不好点。
c：用户（我）对于这个复杂的操作可能不理解吧？
是不是对这些场景都很熟悉？设计师的自尊心不想被挑战。然而虽然这是一种追求效率决策的本能，但是可能我们误以为两件毫无关系的事有关联，并提出一个主观的方案，最后以谁坚持的久，谁嗓门大来得出胜利者，这时候我们的产品就变成“我们的产品”，而不是用户的产品了。
方案设计的流程
所以，我们应该怎样客观的去为用户做设计。应该以客观事实为依据，以研究过程来驱动最后设计方案的敲定，并非是自我体验式的方法去定义设计方案，以及拍脑袋来决策一些“我认为”的方案。目前大部分的设计师的都存在这个问题，那么该如何解决这种给产品体验带来的死循环呢？Design Council有归纳一种设计流程：
目前很多设计师往往入手就是第三个Develop。而对前两个环节探究甚少，可能他们会说我们是为了效率，经验能帮助我们更快的落实方案，达到商业目标。但是我想说这样的商业目标的寿命是比较短的，可能虽然暂时达到了商业目标，但是依然不能支持其可持续发展的需求。然而现在却是本末倒置的去做设计，也是国内和国外设计比较明显的一个区别。
所以发现需求，并且定义需求才是我们需要花大量时间去研究的，并且在这个过程中，我们始终需要围绕这个被定义的需求去做设计过程。
那么我们考虑如何才能客观的以事实依据去做设计呢？毫无疑问，当然是回到源头，去接触用户，与用户互动从而我们能得知用户对于产品的反馈，并及时响应，修复，提升用户体验。
该如何做？
目前在我存在的产品团队中，视觉对于寻找需求并定义这一块做的还不够，我们经常在说用户体验用户体验，可能我们对于用户的认知，只是来源于熟悉产品，看过用户画像之后的经验，甚至用研团队给出的报告，其实这些已经是二手的信息了，作为UI设计师，更重要的是获取用户最原始的需求，并聆听用户的需求，长期并有规律的发现，整理，修复用户的反馈和问题。那么我们是否应该成立一套用户反馈解决方案的体系，来帮助用户提升体验，帮助团队提升解决问题的效率:
1. 建立一个长期的用户反馈系统，持续的收集用户反馈的问题，并将问题流转到相应的单元解决，以天或周的周期来规律性解决问题。问题收集后需要对问题进行分类，比如：该问题是主流程功能还是分支功能，再分该问题属于交互类，还是功能类，还是UI视觉类。分类问题的目的是为了解决源头的问题，而不是出现一个问题而解决一个问题，这样的话问题依然会源源不断的出现，当一个类别的问题一直出现的时候我们就应该追本溯源看看问题是不是出在起始点。
发现了问题之后我们需要每周固定的时间点来进行问题评审，召集所有利益相关者：产品，交互，视觉，开发，测试，并将问题进行程度排布，解决优先级划分，问题解决时间排期。在不同的角色对于不同问题的解决时间是不同的，所以这里对于问题严重程度进行分级，以便在定义问题的优先级的时候更好的参考，并定义问题。
当然这个是很理想的状态，只有当ued在整个产品环节中有足够地位的时候才有可能做这些，如果ued团队做不到这么高地位这些想法也是不可能被推动的，这和公司性质，文化，以及领导有关，不详细叙述（你们懂的）。
2. 在每次需求评审，交互评审，UI评审时记录有争议的地方，并走查上一个版本问题是否已解决的跟进，并整理出问题文档，每周固定时间可以采用线上电访或线下和用户交流，获得我们想要的反馈信息。
3. 自己发现需求，并验证需求。
用户反馈的问题分类：
1. 异常状态考虑不全
举个我们自己产品的例子，交互说明写的不完整，异常状态确实，导致用户觉得出现异常可能都是没有网络，而我们的用户群体是40岁左右文化程度较低的人群，他们不善于使用Wifi，所以一碰到异常情况他们可能都认为是没有网络造成的，长此以往，用户逐步流失。
2. 走查不到位
在上线之前，交互和视觉对于开发出来的产品没有做系统性，全面性的走查，导致出现交互上，用户体验上的bug。
3. 功能问题
目前很多公司的产品都出于探索阶段，甚至还没有盈利。这个时候功能缺失或者不完善可能是用户的一个痛点，这时候需要参考优先级来排期上线功能。
4. 行业生态圈的问题
就拿我们公司产品来说，我们是做公路物流的，就存在货代（发货）和司机两种角色，在这个生态圈中，司机需要靠货代发的货来赚取收益，货代而是收取一部分提成，那么货代提成收的多，司机收益就少。甚至司机有被货代骗的情况，这时候这些问题就需要运营，市场来解决，如何选择优质的货代，将平台整体水平提高。
最后，解决了问题，事情还没有完。还需要去关注问题解决的效果如何。对业务和用户是否带来实质的价值，请查看数据结果。问题的解决能带来业务指标上提升，或者功能实用量的激增。
总结：
讲事实讲依据，当我们在设计为用户服务的产品的时候，要尊重用户，你的想法不代表用户的想法。有些同学会问，我们只是个小公司，没有用研，甚至连交互都没有，老板还要求加班加点做，哪有时间去做这些。其实不然，我们可以在项目当中记录一些问题，分类好之后，再抽空闲的时间去找用户了解，一个小时的收获远远抵的上闷头做好几天的工作。