时间: 2021-07-30 10:23:28 人气: 7 评论: 0
在我们平常的设计工作中，和需求方产生各种争论的情况很常见，双方都比较偏执强势的时候，很容易陷在各自的立场中，谁也说服不了谁；如果设计师本身就离自己负责业务的用户有一定距离（比如大多数的 B 类产品），就更容易在需求方面前陷入被动。这种时候，我们更需要从自己的专业思考角度走出来，用科学的方式去收集、分析、定位、验证问题，洞见问题本质，来和对方更好地达成一致。
先让我们还原这么一个工作场景：
产品经理 A：我们的首页好久没改版了，要不要来点动作？
设计师：好啊好啊，我也正想和你提议呢，早就看不下去了！
（省略双方需求沟通过程若干字）
***进入设计评审阶段***
运营：哎，这个内容对我们推广 XX 很重要的，怎么能去掉呢？
产品经理 B：我负责的这块业务你是不是漏掉了，要首页首屏重点透出！
产品经理 C：你要考虑万一某某用户来访怎么办，他们的诉求得满足~
老板：我需要什么什么感觉，没体现出来啊！
设计师：塞这么多东西用户都想看吗？
众人：我不管，这块内容很重要的！
***设计师吭哧吭哧改了一版新的***
众人：感觉好复杂啊！是不是还是别改了……
在传统的接需求做设计模式中，我们往往是和一个需求方单点沟通确认，然后产出方案、评审、开发、上线。对于比较小、权责明确的需求来说，这么做问题不大，但当牵涉到的利益相关方多起来，就很容易给后续的推动过程挖坑。
在 Google 的设计方法 Design Sprint 中，有提到一个 360 度快速访谈法，请 PM/老板阐述商业目标和成功标准，请开发阐述技术能力和挑战，请用研阐述用户研究结论等。这样做可以帮助设计师从多个角度综合看待和分析问题，做出能平衡各个利益相关方的最佳设计决策，而不是陷在「这么做不符合设计规范」、「破坏了体验一致性」、「没有创新亮点」等比较狭隘的思维里。
在积累了一定工作经验后，设计师可能**遇到从纯粹的 Designer 转变为 PMD（独立负责一块产品设计及其项目管理，直接背 KPI）的契机，变为 PMD 之后，就不能再是老一套的等着需求文档提过来、或只和自己的上游产品经理对接，而要自己主动多方出击，360 度向其他运营/开发/测试/老大/真实用户等收集各种原始反馈和建议，分商业/用户/技术等不同角度整理、归纳、提炼，像产品经理那样把需求阶段的各种问题回答清楚（为怎样的用户解决什么问题？能带来怎样的商业/用户价值？如何衡量解决方案是否成功？有什么潜在的风险和限制？而不是只**站在设计师的角度说现在的方案太 Low了啊要保持体验一致性啊），定位要解决的核心问题并和核心利益相关方达成一致后，再推进下一步的设计工作。
我们都知道，信息在传递过程中**有失真情况的发生，当产品经理找到我们信誓旦旦地说「用户想要这个」时，如果凭经验感觉有些难以理喻，相比直接否认拒接这个需求，更为妥当的做法应该是尽量争取机**去接触真实场景下的用户，验证需求本质的合理性。
昨天去听了 IXDC 杭州站的分享，来分享的一位菜鸟的嘉宾就提到了走进真实场景做设计的重要性，设计师们出差到全国各地去观察快递小哥的实际工作场景，进而从中有效洞察出真实用户痛点和设计机**。
走近真实场景也能让我们发现一些靠听用户反馈可能注意不到的问题，比如很多设计师都习惯用 Mac、大屏电脑做设计，却忽视了在小屏幕、低性能电脑上设计方案的最终呈现效果，造成终端体验受到损害。
在比较快的项目迭代节奏下，有时并不能给设计师多少做充分的前期调研准备的时间，双方争执不下时，**有一种比较常用的解决方案，就是先上线看数据反馈效果，好就继续，不行就下掉。
但是，影响一个数据的因素可能是非常多元化的，而设计方案的好坏只能起到一小部分的影响，这时候我们不能只看短时间内单个数据指标的变化（对于一些从无到有的刚需项目，只要做出来了，不管设计做得有多差反馈都可能是正面的），而应多方面结合地看、持续追踪地看。
比如大规模的改版项目，在上线之初比较容易因为用户的不适应，产生满意度指标大幅下降的情况，相比匆匆滚回旧版，也许更理性的做法是逐步灰度铺开、监测一段时间过后满意度指标的恢复情况，验证满意度下降究竟只是因为用户短期的不适应，还是设计上确实出现了问题。
而一些新上线的项目，前期运营推广力度**比较强，整体数据也**相对好看，作为设计师不应就此满足，而要主动持续跟踪后续数据趋势和用户反馈，寻找是否还有体验优化的空间。
之前我在朋友圈提了一个让自己非常困惑的问题：
当所有人都觉得一匹更快的马已经够用时，该如何说服他们接受相对昂贵、不容易习惯的汽车呢？
当然，现在我也给不出一个好的答案，但结合本文所写，我觉得可以有以下几种思考角度：
也欢迎一起交流你的看法啦：）
本文由人人都是产品经理专栏作家 @鸿影 原创发布于人人都是产品经理 。未经许可,禁止转载。
