做设计这一行，我们经常会经历业务线各职能岗位之间各种撕逼大战，产品经理，交互设计师，UI，开发，他们之间上演着各种“爱恨情仇，江湖恩怨”的大戏。
作为交互设计师，怎么样才能避免被大家诟病，所以这个话题是值得去探究的。这篇文章从我多年从业经历出发，跟产品，开发，ui设计师沟通对接时，如何才能将设计方案更加客观合理的方式的传递出去，避免被喷的狗血淋头，最后被别人认为很不专业，大大降低了工作中的掌控力。
为什么要撕逼呢？
1.为了同一个愿景
企业为了一个产品，则需要不同的工种之间进行配合，协作，众志成城的去完成。在这个过程中，大家都是为了一个共同目标而奋战的战友。但是呢，每个都为了产品能够完美呈现都会有一些自己的想法；另外一个原因就是每个人可能站在自己专业的立场上会思考工作的难易程度，所以会产生不同的意见分歧。
我们也明白每个人的性格是不同的，尤其是那些不愿意妥协，坚持自己意见的搭档们，就会上演一场专业上的较量，但是大家的愿景都是好的，都是为了产品的未来。
2.或许是真的没有做到位
这个就是我能想到的第二个原因了。交互设计师有时在设计考量过程中真的会存在缺陷，方案输出存在一些遗漏，就是在查漏补缺的过程中不仔细导致而成。有的时候还会错误的觉得“人无完人，孰能无过”，只要是一些很小的无足轻重的点就可以勉强掠过，但是这种抓大放小的习惯会埋下可怕的潜在暗坑，由于自己的疏忽或者考虑不周等原因，也可能会引发功能设计风险和商业目标风险。
但这些不是不可避免，只是要在设计过程中，按照严格的标准要求自己。产品目标，用户研究，场景研究，数据研究，设计细节，方案验证，是否达到设计预期等等，严格把关会避免在后期出现上述的严重失误或缺陷。
接下来我会通过设计所面临的各个路径进行详细的分析，设计如何避免一些不必要的争论。
1.前期准备工作，成败的关键
之前有个工作上的毛病，就是在拿到需求后，了解个大概，就去直接做设计画图，想做出很牛的方案，往往会疏漏对需求的分析研究过程，对用户场景的梳理，对背后数据的分析，对产品目标方向的把握，造成未开始就失败的结果，所以前期对需求的研究很重要，因为它对后期的设计有至关重要的作用。
通过一些点，我们来看看前期都要做什么？
a.从目标出发，实现产品愿景
一个产品的诞生就有他不可或缺的产品愿景，产品目标，也就是是所谓的战略层。也许大家会认为这个是公司上层决定的问题，我们这些虾兵蟹将不用操心，只要跟着方向实现即可。其实不然，上层只是决策，但是很多功能细节还是要虾兵蟹将去琢磨，上层不可能决定的这么细的，所以一个产品的成功对虾兵蟹将来说也还是比较重要的环节，因为公司养着我们就是要做出对的事情，从而我们也可以实现自身的价值。
在这块我们要明确两个问题：
- 企业要通过这个产品得到什么？
- 通过这个产品要满足用户什么样的期望？
前者即产品目标，后者即用户需求，作为交互设计师，在战略层一定要明确这两个问题，越清楚知道我们需要什么，用户需要什么，就越能开发设计我们的产品以精确地满足双方的需求。
b.从用户出发，找到用户痛点
上面在“目标”中，我们也提到了要了解用户的需求是什么，从用户的角度，使用场景出发，更好的满足用户所需，产品在未来才可能走的更好，更远。
我们首先要明确用户需求一般分为“直接需求”和“间接需求”
我们听的比较多的可能是“痛点干需”之类的描述，其实痛点干需就是直接需求。用户直接可以告知的“我要什么”，这一类就是直接需求。比如我要和朋友之间可以相互发文字、图片、语音、视频，能很清晰的描述出来，很多时候我们也称直接需求为“显性需求”。
间接需求分两种，一种是“隐性需求”，用户在头脑中有想法但没有直接提出、不能清楚描述的需求，这种需求是需要引导的。如果要激发用户的隐性需求，我们要深入了解用户才能更好地满足他们的隐性需求。另外一种是外力导致的需求，就是用户本来没有需求，因为受外力的作用，从而变成有需求了。
所以对于用户需求的准确把握，是在后期设计过程中方向性的把握起到主导作用，以免后期用户需求的方向性失误，导致撕逼情况的出现。
c.从场景出发，学会讲故事
作为交互设计师，一定要培养自己讲故事的能力。“讲故事”就是我们要按照用户需求分析用户在使用产品时的各个场景，并要声情并茂，面面俱到。场景是我们在设计日常工作中，每天都能听到的词汇，所以交互设计师一定要重视用户场景的分析，设计方案是否合理，是否满足用户习惯，使用逻辑，认识逻辑等等，都要依赖这个模块的研究与分析。
一般场景有客观和主观条件综合影响。我们要把用户心理状态描述出来，他们最终会变成产品中的行为。
外部场景：时间、地点、外部网络情况、终端设备情况等。
人物内部场景：人物内心状态、身体外部状态。
对用户场景，用户体验地图的深入思考与分析，在后期设计时可以清晰的按照使用场景，操作路径往下进行，这些都是验证设计的最好过程与指导，只有做到面面俱到，才能深入的挖掘出各个场景的细节，所以注意场景的分析，以免不必要的争论。
d.从数据出发，用数据证明
很多设计师在设计时，往往会对一些点不确定，需要一些支持才能验证设计的真伪与合理性。这时数据就常常作为设计师一直挂在嘴边的因素，只有数据才能验证与支持设计的科学性，可行性，准确性，但是这些数据到底是什么样的数据呢？
这些数据在我看来就是前期的用户访谈，用户调研结果的数据统计。它们能够最直接地反映用户的使用习惯，偏好，甚至不同用户性格和心理状态，也同时会反映出很多和我们前期逻辑推理相悖的问题，从而引起我们反思，找到原因，来改进设计。这些数据在后期对设计方案都会有指导性作用。
还有一类设计就是改版设计，我们在产品上线一段时间后，可能会有一些用户使用的数据返回来，还有打点数据统计，这些数据在改版设计时，也作为指导设计的最有效的支撑。所以设计在很多时候对于数据的把握，分析，研究，都要时刻作为有效的武器，在设计方案评审时更有说服力。
2.完美的方案输出，细节决定有无撕逼风险
一份完美的交互文档是交互设计师必备的基本技能，文档是交互设计的灵魂，细节决定未来撕逼的风险。前期工作做足，输出设计目标，设计思维，设计策略，在这个环节就按照前期的指导，一步一步完成方案的输出。
交互文档输出原则，在文档的结构，内容和形式有三个以下方面：
a.逻辑严谨，文本简明扼要
很多交互设计文档在表达设计观点时，通常会显得比较啰嗦，口语化，有的看了让人不知道表达的是什么，降低了阅读效率，增大了沟通成本。交互文档的整体内容结构与页面内容结构书写要思路清晰，逻辑严谨，简明扼要，并尽可能的做到不遗漏，将交互设计的思路和方案更好更全面的表达出来。
b.迭代方便，利于协同管理
现在行业中大家在使用的交互工具大多都是Axure，sketch，在方案设计过程中，大家都要养成一个好的习惯，就是在开始时就要记录版本迭代的日期与版本迭代中修改的地方，这样有助于在方案变动过程中记录修改信息，无论是Axure，sketch制作的文档，方便后期管理，而且如果在撕逼时，可有据可寻。
交互文档是对接上下游利于协同团队工作的重要输出，所以文档应该保证利于其他岗位人员的查看 或编辑的。比如，在文档格式方面，如果你是用Axure做设计，尽量要生成一份完整的HTML文件，而且要告诉对方什么浏览器打开，以便查看，因为我在这里吃过亏。
c.美且适用，细节决定成败
在这个看颜值的时代中，大家都会对一个外表英俊美丽的人，很容易误认为他或她的其他方面也很不错。
作为交互设计师，设计方案时不仅要考虑逻辑清晰，表现层面也要考虑视觉上的美，因为交互设计师也要考虑图文排版、字体大小、明暗层次等方面的细节处理，从而输出一份完美的交互文档。刚才也说了美的东西可以从视觉促进人们形成正面积极的态度，这些都会影响到后期交互文档评审过程的效率性与愉悦性。
在交互设计过程中，按照以上三个点去完成，输出一份完美的交互文档，注意细节是不会有什么大问题的。
3.设计方案验证，不放过每个环节
防止后期撕逼最大的关键点就在这里，前面都是为达到完美的设计做足各种工作，设计验证是后期防止出现失误与缺陷的最最重要环节。这个环节是检验成果的时刻，对于前期做了大量的设计工作，费心费力的完成整个项目的设计，当然希望是完美的结果，而且也是目标用户所希望的产品路径设计。
在很多的项目完成后，作为交互设计师会忽略这个环节，或者只是流于表面，没有更深层次的去检视产品的可用易用性。
检查时要通过以下几个点去重点验证：
a.是否满足产品目标，用户需求？
前期对产品目标与用户需求的研究，这个前面已经说过了，企业要通过这个产品得到什么？通过这个产品要满足用户什么样的期望？
前者即产品目标，后者即用户需求，作为交互设计师，在设计过程中一定要把控着这两个方向，后期验证也要紧扣这两个方向，不要偏离。
b.流程与信息架构是否合理？
这里的流程两个部分，一个是设计流程，一个是体验流程。
设计流程则包括“用户研究（问卷、竞品分析报告），用户画像（目标用户分解、用户特征、访问场景、用户目标、关键词、最关心的内容、痛点等），流程图（用户操作流程抽象、分支情况要考虑周到），框架图（关键页面的整体框架布局，体现优先级关系）”，等等。
体验流程，则要检查设计的流程从头到尾是否能顺畅走通？复杂任务流是否支持保存或自动保存以及意外退出前是否保存提示？路径是否一致？是否符合用户预期？逆向流程是否考虑周全？跳转链接是否与跳转目的一致？是否提供危险操作的二次确认？是否提供必要的撤销操作？操作失败的解释与建议？退出、撤销、重置、返回、不通过、过期失效等等。
信息架构，是否符合用户既定的使用习惯和理解？信息区域间的层级关系、元素控件间的关系是否符合亲密性、对比性和重复性等设计原则？能否正确地体现与页面信息架构相符的逻辑关系？对庞杂信息进行组织、筛选、归类时，有没有遵循用户熟悉的分类标准？对企业应用来说，分类有没有符合企业内部习惯和行业惯例？视觉流是否存在反复和绕行现象？等等。
c.页面布局与内容是否完整？
在页面内容中定义了页面中的一些细节，主要集中在表单页面的内容形式：控件呈现、数据展现、输入与选择、文案展现。
控件展现是否符合用户认知？控件样式是否具有一致性？控件交互行为是否具有一致性？控件不可用状态是否呈现？
数据空状态是否展现？数据无法完整显示的如何处理？字数有限制超限如何处理？数据过期如何提示用户？数据按什么规则排序？数值是否要按特定的格式显示？数据是否存在极值？
输入与选择表单填写是否为用户提供了默认值？表单验证输入过程是否提供提示和判断？表单反思是否存在不必要的输入？表单交互是否指定了键盘类型和键盘引起的页面滚动？
文案句式是否一致？核心词汇是否一致、准确？文案描述是否有温度感？
d.交互和反馈是否响应明确？
这里主要考虑的是用户与产品的交互过程，需要让用户在与界面的交互过程中及时的获得反馈。
交互过程中，操作按钮在当前界面是否明确？操作按钮是否易操作？是否自动刷新？刷新的条目数？取消，删除，长按等等操作过程是否清晰？等等，都是交互设计操作过程要注意的点。
反馈，则指操作成功，操作失败，操作过程中各种情况的反馈，加载状态，动效等等，给出及时的反馈状态，让用户清晰的知道每一步操作后的情况。
e.特殊情况是否被考虑到位？
特殊情况，我们就要从“硬件设备，各种场景模式，网络状态，异常情况，账号权限”等等境况下去考虑，面对这些环境时，会出现什么样的状况，对产品造成什么样的影响。所以在方案中将这些复杂的环境造成的影响也要有所体现，考虑到方方面面，以防在后期沟通中闷逼，造成不必要的麻烦。
4.方案沟通，准确传达设计目的
我认为前期的设计过程是基本技能的体现，方案评审将设计的成果讲给上游和下游的沟通会议，体现说服过程，优秀的表达，准确的传达会对方案的最终产生一些质的影响。
这个在方案那边已经说了，所以大概提下。就是方案去评审之前明确产品目的目标，在需求分析，用户研究，数据整理，方案设计的过程中就要做足充分的准备，方案一定记录修改历史，记录客观限制，给设计稿编号，养成好的习惯，对于方方面面考虑到，细节做到位，降低后期评审时出现撕逼过程
a.注重沟通的方式方法
常常在设计方案的沟通过程中，会听到“我觉得……”，举个例子“在一个产品的场景中，设计师在讨论方案时，说“我觉得用户在这个界面最关注的是数据，而不是功能，应该将数据更加突出”，反驳的声音说：“你觉得，只是你的个人感受、猜测而已，真实的场景和情况，并不是你觉得的那样…”所以最后会陷入撕逼的过程，没完没了，不可开交，最终会降低自己在别人眼中的专业性。
沟通方法因人而已吧，有的人适合沟通，有的人就是表达不畅，但是方案没有问题，产品思维清楚，一般是没有啥问题的。
b.紧扣主题，控制节奏
有个现象，不知道大家是不是深有体会，就是往往在需求评审的过程中，会议会经常陷入一种技术讨论会，而且大家深深陷入其中，在想怎么去实现，是不是能做出来，开发的小哥哥们认真的互相讨论起来，挡也挡不住。在这时候你就要及时的把他们给拉回来，防止出现思维发散。
对于大家都有争议的点，完全可以先搁置争议不在会上讨论，会下思考方案后在进行召集谈论。最好会议记录和讨论结果和争议点，最后发出根据会议讨论的修改结果，让大家进行确认，做到整个会议的闭环。
c.总结归纳，防止遗漏
一个方面是交互设计师的方案不一定就是最最完美的，肯定会存在一些不足的地方。另一个方面是，前面也说过，大家对于产品的形态都有自己的想法，可能在沟通过程中，会有一些意见与建议。作为交互设计师就要将这些意见与建议一一记录，总结归纳，以防遗漏，后面在设计优化过程中可以一一更新，免得二次撕逼。
撕逼行为的“两面性”
每个事物其实都是有两面性的，当然撕逼也是有两面性的，一个当然是为了事物更好的发展方向，另一个是方式的不正确性，导致不可预期的结果。所以往往表现出好坏相辅相成的局面，局势都是在不断的调和与变化的状态向着解决问题的方向发展。
交互设计在沟通过程中，如果出现撕逼也表现出了两面性，上面提到在交互设计中导致撕逼的可能原因，一个是大家都有同一个愿景，另外一个就是设计师本身的问题。站在这两个角度来看都会看到世态事态是按照解决问题问题的方向发展，结果是呈现出好的状态。
但是这种行为容易产生冲突，每个人都有自己的个性与脾气，情绪把控不到位，所以在撕逼过程中大家要注意方式方法，都要以产品的角度展开，切莫上升到人身攻击，为了共同的愿景，心平气和的聊，尽量避免冲突，切勿成为了项目团队中的笑料。
