*全文3000字左右，约花费您6-10分钟左右读完。

在设计实践中，我认为很难用正确和错误来简单评价设计方案。当然一定有很傻的，错误的方案，但是多数方案是游离在完美解决和刚刚能够解决体验目标之间的“差不多正确”方案。给出最合适的设计方案的首要决定因素在于需求沟通。美国通用汽车公司管理顾问查尔斯·吉德林说过：把难题清清楚楚地写出来，便已经解决了一半。在我看来，只有把需求沟通清楚，才能基本保证最终设计方案的质量。

怎样澄清设计需求，这一套方法并非我原创，而是在前司的WW老师和LV老师指导下，结合工作中踩过的坑慢慢领悟的。还不算全然掌握，只是做一个阶段性总结与反思。接下来进入正题。

“

总的来说，设计需求需要搞清楚三样东西：数据，逻辑，竞品。

”

1- 数据：最原始的需求来源

设计不同于艺术，在我理解设计应当是通过创新和优化的方法解决现实的问题。问题就是我们日常面对的需求，数据可以理解为需求的原始来源。这里数据不局限于以数字呈现的数据，还包括原始用户的语言描述，截屏记录等。提出需求的人一般并不是傻子，但他们不站在交互体验立场，提出来的需求不一定能解决真正的体验问题。需求来源的原始数据是什么样的，数据反映出的用户场景和行为是怎样，该场景下用户的真实需求是什么，需求的影响面和优先级有多高，这是每一个设计师在沟通需求的时候最先要考虑的一个问题。

从设计思维角度来说，设计师必须考虑真实场景，从真实的用户那里发现需要实现的体验目标。传统发现体验目标的方法包括访谈，观察等等，这些依然有效。举一个例子，我有一次收到的一个需求是：将某个特定筛选浮层上的按钮控件变矮一些。这个需求的体验目标是什么？为什么要将按钮变矮？影响到视觉一致性和可点击区域问题怎么解决？向我提出需求的那位仁兄也说不清楚，只说这是某总提出的一个必须要修掉的问题。为确认需求的原始数据，我就直接找到某总，当面问他这个浮层上出现了什么问题。他对我说他使用这个浮层的时候，总有一行按钮在屏幕外，这种展示很傻很不合理。问询后我得出的结论是，用户的原始需求是看不到最下面一行的按钮，而并不是认为按钮过高。按钮样式有整体一致性，也有可点击区域的问题，因为一个浮层的显示问题而创造一个新的样式并不合理。而根据原始需求，设计上只需要调整这个特定浮层高度，或将浮层改为模态页面即可解决。

互联网产品拥有巨大而详实的线上数据，通过不同的数据分析方法，可以窥探出用户的行为、偏好、习惯甚至思维方式。针对各种各样的产品有各种各样的数据来源与分析方法，各个公司也有不同的取数规定，我并不算特别了解，因此不在此赘述。只是基于我有限的与数据打交道的经验看来，设计对数据的理解不能仅限于线上数据及常规分析。设计解决的不是“这里数据不对我来试几种方案fix一下”的工作，这种探针一样的设计方法多半是抱着碰运气的心态，靠直觉尝试解决问题，并不是真正在做设计工作。数据真正体现的是用户的场景和行为。在观察日常数据的同时，需要结合访谈和观察等用户研究建立该产品对应的场景与用户角色模型，梳理用户的体验流程。场景会越来越细，越来越具体；用户角色也会随着对日常数据的观察分析及对真实用户的洞察越来越具象。只有清楚了真实场景下用户的体验流程和痛点爽点，才能有的放矢，结合有效的设计方法做出能实现体验目标的设计。

2- 逻辑：解决问题的思路

虽然被冠以“用户体验设计”设计者的名号，但交互设计师很多情况下处理并不是纯粹感性的体验，而是复杂的逻辑问题。流程图是和线框图并列的交互设计师两大法宝。一个需求的交互逻辑是怎样的，很大程度上决定了这个需求的体验目标能不能被优雅而有效地实现。

但是梳理需求逻辑本身就是一件复杂的事情。一层一层拨开看，一个常见需求对应的逻辑包括业务逻辑，产品逻辑，技术逻辑，用户行为逻辑，交互逻辑，视觉逻辑。交互设计师需要理解前四层逻辑，才能梳理出适合的交互逻辑。

理解前4层逻辑的复杂之处往往在于，跟你沟通的人并不理解其它层次的逻辑，他往往只能理解自己岗位下所需要的逻辑，以及由此得出的“他想要的交互逻辑”。这有时候会很可怕，往往会出现产品经理对你大吼大叫“我就要这个设计”，或者技术对你微微一笑“这个设计做不出来”。如果此时设计师也陷入情绪化，或者对需求层次理解的不清晰，往往机会是半天的鸡同鸭讲，然后出现一个折中的蠢方案。

为避免陷入这样的僵局，交互设计师必须要清楚地知道自己此时在处理的需求逻辑是哪一个层面的，以及怎样获取正确的前四层逻辑。就业务逻辑来说，设计师不能只埋头于设计，需要有一定的业务背景知识。这种知识不管是和业务交流需求的时候获知的也好，还是从产品经理哪里挖出来的，或者结交几个业务的小伙伴平时唠嗑唠出来的，甚至是让领导安排去一线观察得来的，总之必须能够支持自己理解完整的业务逻辑。技术逻辑也类似，不过有时间精力的小伙伴还可以通过慕课网、w3school等等平台自学一些技术知识以备撕逼之需。用户行为逻辑可以通过数据和用户研究建立。比较困难的是产品逻辑，这一层逻辑是关于产品目标，很容易和交互逻辑混淆。因此在这个层面更重要的是和产品经理本人的沟通，需要明确什么是他关心的产品目标，这个产品目标里的商业目标、用户目标分别是什么，而体验目标是在什么程度上实现商业目标与用户目标的平衡，从而最合适地实现产品目标。在这个过程中，不宜过早地进入细节，这样容易演变为“我就要这个交互方式”的争论。此时需要确认产品逻辑后再结合业务逻辑、技术逻辑和用户行为逻辑，梳理出合适的交互逻辑。

3- 竞品：解决方案的参照物

竞品不是拿来抄的。这是我想表达的第一句话。如果需求是“我就要抄这个竞品”，那么设计时需要格外当心。当我们不了解竞品的数据和逻辑的前提下，盲目照搬竞品，那么设计完成之后应该做的就是烧香拜佛，祈祷这个竞品的设计在我们的产品上也奏效。竞品面对的场景、用户和自己团队的产品往往不会完全相同，并且竞品也不能保证他的设计就一定是好的，照抄是很蠢的行为。

竞品是可以用来抄的。这句话似乎与上一句矛盾，但这里需要强调的是，抄竞品并不是照抄形式，而是“抄”解决问题的思路。交互设计本身就是解决交互问题，实现体验目标的，就像思想不会专属于任何一个人，交互思路也不专属于任何一个产品。只要设计思路可以最好地解决当前问题，并非不能“抄”过来。抄形式容易陷入产品品牌特征不明显，格调变LOW的囧境；而“抄”思路，通过一个更优的套路来解决当前问题，甚至优化竞品的套路来实现整个行业解决方案的进化，并非是一件坏事。

因此，需求沟通的时候如果有可以参照的竞品，将会更容易理解需求对应的设计思路。使用竞品进行沟通时，往往需要注意竞品的使用场景和用户角色是否和自己的产品相对应。如果没有对竞品的细致研究和精心挑选，很容易陷入“当我觉得有用的时候就说竞品也是这么做的，当我觉得没用的时候就说竞品做得不好”这层境地。竞品长期使用或有数据支持或广受业界承认的做法可以作为设计支撑，竞品偶尔呈现或在测试之中的方案往往只能作为“灵感来源”，并不适合作为参考。总体来说，Best practice是否best并不好判断，因此需求沟通时更需要注重的还是数据和逻辑的支撑。

此外还有一点，就是初步沟通完成后，在进行设计时如果有参考竞品，最好是能够保留竞品的完整截图或者录屏。即便是放在文件夹或者单独一页备用集合里也可以，当后期设计方案发生争执的时候，也好说明当初需求澄清时的逻辑以及设计时的思路。

以上就是我对设计需求澄清时基本思路的理解。经验粗浅，也许总结得有失偏颇，这里只当是给各位同行一些思路，也许能提供一些帮助。