设计阶段的沟通触点

先列出交互设计阶段会产生的一些沟通触点：

合理的需求是用户体验存在的前提，但是需求描述不清时如何高效获得自己想要的信息？

怀疑是伪需求是如何确定需求来源的及其合理性呢？

汇报交互设计时如何向boss及上下游展示工作量与专业度？

如何让视觉或前端一眼看到自己关注的点？

怎么面对上下游对方案的质疑？

与开发利益和产品排期冲突时怎样可以避免合理的设计沦为飞机稿？

形式追随功能，交互如何应对视觉改方案只为更美观？还原度有问题怎样推进修改？

针对以上问题，接下来的内容会一一阐述。

事例：认为某需求是伪需求

设计师：添加这个功能的需求来源什么呢？

产品：客户反馈的，某大客户提出有加这个功能的需求，他们用的到。

设计师：这个功能用来做什么呢（使用场景有哪些）？

产品：方便……有利于……

设计师：这样做又能达到什么目的呢？

客户：这样就可以内部交流了啊

设计师：哦，原来是要一个协同的功能，可不可以考虑A这样呢？

客户：好像也可以的。

【点评】怀疑是伪需求时需要先了解到底是UCD还是BCD（Boss Centered Design），如果是大boss提出的，一般是很难撼动的，但如果是用户／客户提出的，就可以继续提问追溯本体真相，获得最原始需求了，在一步步提问中可以开辟新的思路，推动产品／业务思考。

如何行之有效地汇报设计方案

汇报交互设计方案也是一对多的沟通，“三分靠画，七分靠裱”说的没毛病。

总结了几点外审方案时注意的点：

简述设计流程，简单说明设计思路与考虑的过程，有助于对设计方案的理解，合作初期也可提高在同事前的专业度；

确定需求无误，业务流程与逻辑梳理应该与产品同步；

标注并明确需注意的细节，汇报会上确认有争议的点并做记录，说明需要注意的点，防止后期被忽略；

交互说明分开注释，视觉与开发在看交互稿时关注的内容不同，可区分颜色进行交互标注。

如何面对上下游的质疑

应该会有一些交互同学跟我一样，初入团队的时候并没有交互设计师的岗位，PM做了大部分交互的工作（我一向认为专业的事情让专业的人做，站的角度多了很难在各种要素中寻求平衡）或者是项目组成员初期合作阶段，因此方案出来后经常会受到质疑，为此我同样总结了以下四点：

参考竞品：市场份额占有率较高的竞品在同等问题的处理上一定是踩过坑的，可以借鉴；

引经（zhuang）据典（bi）：通过权威的理论依据与专业术语，如fitts law、Gestalt等；

数据支撑与用户研究：后台数据定量分析，用户访谈、可用性测试等的定性分析；

用户同理心：秒变小白用户，从用户和使用场景的角度描述方案的合理性

其实每个角色关注的点不同，运营关注的是营收指标，产品是KPI，而开发则担心开发成本，所以如果有可能的话在最后提一句：这样的方案不会影响甚至是有利于营收指标 / KPI /开发成本 。

在构思架构时及时沟通喜好

产品本期该迭代优化的需求，里面会记录需求对应的功能设计，让用户了解需求解决的进度

沟通完需求后再重新进入状态思考产品设计

1、前期看需求

当需求文档提过来时先用最短的时间看一遍，主要是看看大概内容和有没有遗漏什么。之后可以预计一下开始时间和收集相关资料，当然，假如对项目很熟悉的话就不用再收集了。假如发现那些位子没看明白或遗漏要立即找需求人员沟通。

有些需求人员写的需求不规范即使需求很简单一看就明白也应该让他修改好，因为这关系到以后合作流畅度的问题，模棱两可只会让今后的合作越来越困难。而且需求方也不段有新进人员，如果让他们对照不规范的需求文档提新需求，岂不是照猫画虎。

看完需求假如没什么问题可以把你预计的时间安排反馈给需求人员也让他好作计划。不过开始设计前还是要与需求人当面沟通一次，主要是把你大概的想法、风格等给对方说明，行就继续，否则再沟通，总之事先达成一个初步的共识。

2、引导需求人员

在修改方案过程中最容易产生争执，之前那篇写了些修改方案过程需求人员常出现的问题，这里就说说设计人员碰到这些问题时应该如何化解。

有时候需求人员提的修改意见会不知道怎么改，主要是因为意见太虚。比如说“大气”，你这个图不大气，那里显得太小气！之前看过篇介绍什么样做大气图的文章，大概就是说“大气”等于“简洁”，其实不然，现在很多类似“大气”这种词汇滥用，明明不是这个意思却套了这个词，更何况“大气”本身就很笼统。碰到这种问题我的一般作法是把问题拉加实际，尽量在口头上把问题具体化。多问一些“为什么？；怎么小气了？；那你觉得什么样的大气？；是不是背景太暗？”。

至于风格问题之前说过，每个人喜欢的风格肯定千差万别，假如在这个问题上僵持不下时就要看谁更有话语权。而话语权则是由公司文化决定的，我们听过Apple的设计师文化；Google的工程师文化，这两家公司内部谁更有话语权就可想而知。

1.前期看需求 当需求文档提过来时先用最短的时间看一遍,主要是看看大概内容和有没有遗漏什么。之后可以预计一下开始时间和收集相关资料,当然,假如对项目很熟悉的话就不用再收集了。假如发现那些位子没看明白或遗漏要立即找...

2.引导需求人员 在修改方案过程中最容易产生争执,之前那篇写了些修改方案过程需求人员常出现的问题,这里就说说设计人员碰到这些问题时应该如何化解。 有时候需求人员提的修改意见会不知道怎么改,主要是因为意见太虚。

1. 需求沟通中，尽量避免陷入讨论设计方案细节

2. 不讲废话，记录（草图+纪要）解决

3. 不贴标签，客观对待每一个需求方

4. 事前准备，对对方领域知识有所涉猎。

5. 需求沟通完成，确认你所理解的是他要表达的。

行业竞争激烈，为了在竞争中发挥最大价值，设计跟业务线之间目标需达成一致。

但研究表明：15% 的员⼯无法说出领导者所识别出的三个关键⽬标，余下 85% 的⼈所认为的主要⽬标也和领导者所给出的目标大相径庭。

在产品设计研发过程中应该抱着“合作”的心态，且一直致力于让团队达到“合作部门”的理想状态。

- 与业务方目标一致

当设计是“合作部门”的时候，会与业务线向一致的目标去努力。设计师会关注、理解合作业务线的目标、理解公司的目标，会关注达成目标手段的多样性，会采用更有目标导向的沟通方式等等。

当然，作为”支持部门“时也能关注这些，但在真正遇到困难的时候，由于缺少”合作部门”的主人翁精神，心态是不一样的。

可以从why,how,what三个维度去分析设计的目的是什么,why是从更高的产品需求角度去思考设计的意义,how,是围绕本设计的内容进行扩展,what,是考虑如何能够将当前的设计更好的从表现层进行优化.