为什么你的交互方案过不了 ？大厂高手教你这 4 个方法！
本周特邀前百度资深交互设计师薏薏来讲讲自己从交互小白一路升级打怪的互方过程 ，薏薏从纯理科转行设计 ，案过从 C 端近年转行 B 端 ，厂高求职 、手教工作中踩过不少坑 ，个方今天将分享其中的互方一部分心得体会 。
你是案过否和我有过同样的经历 ：当我们费尽心思 、信心满满地做好了一个完成度很高的厂高交互方案 ，可能被别人的手教几句话就否定了 。
场景 1
和 leader 确认交互方案时 ，个方刚讲两句就被 leader 全盘否定 ，互方导致自己带着 leader 没看一眼的案过稿子默默回到工位 、从头再来 。厂高
场景 2
和 pm 确认交互方案时 ，个方pm 一遍一遍提出疑问、还说了 A 、B 、C 、D、E 各种想法 ，导致自己的方案反复修改 、无法按时交付。
场景 3
向 boss 推自己的设计自驱方案时，无法得到 boss 的认同，导致最终无法争取到开发资源 、自驱项目最终流产 。
场景 4
大厂面试官对作品集中的某个项目不断发问 ，而自己却难以给出令他满意的回答 ，导致面试最终失败 、无缘 offer 。
对新人设计师来说，方案被反复否定不仅费时费力，还让人怀疑自己的能力 、动摇自己初入交互大门的自信 。那今天我将和大家一起分析什么样的交互方案是经不起推敲的方案 ，如何呈现展示 ，才能让我们的方案（至少看起来）严丝合缝 ，经得起别人的反复垂问和推敲 ？
呈现形式重要，但推导过程更重要
日常的琐碎工作和求职准备会让很多人忘记交互设计的本质 。
从视觉设计师的视角来说 ，交互设计是对用户行为的设计，这和用户直观可感受到的视觉设计有很大的不同。
从产品的视角来说 ，交互设计更偏向对行为细节和用户心理的打磨，和宏观、粗糙地设计整体产品框架有很大的不同 。
交互设计师应该输出的是整个设计推导过程 ：用户在操作流程中的行为习惯 、预期心理 、使用场景 、使用痛点的等等 ，而不仅仅是最终看似完美的视觉呈现形式 、或者看似有条理 ，但是缺乏细节打磨的功能介绍 。
这一点，常被初入行/非交互专业出身/小厂背景的设计师忽略 。比较常见的两种类型如下 ：
第一种是视觉出身 、希望转行交互设计的设计师 。他们往往在方案中强调组件使用得当 、文案引导清晰 、甚至是使用了新颖的微动效等等 ，这些确实确实是好方案所需要的设计亮点；但如果整体方案缺少设计推导过程 ，凭空自己的主观想法做方案，那么你的方案自然不堪一击 。
第二种是因为公司人手不足，承担了偏产品工作的交互设计师，或者是校招生。他们往往在方案中有比较好的背景说明 、方案推导 ，但是方案的呈现过于简化 ，或者过于强调"设计思维" 。最终呈现的形式类似 PRD ，缺乏细节推敲 。设计中有一个原则叫"美即好用" ，当一个方案的呈现形式合理时 ，听众自然会给它更多的耐心 ，否则为什么你不直接去面试产品经理呢 ？
用闭环思维严谨地介绍你的设计
那么 ，如何做出一个经得起推敲的设计方案 、一个严谨的设计过程 ？或者说什么才是交互设计这个岗位需要去重点强调 、重点展示的？我认为一共有这几点小技巧：
1. 永远不要一上来就讲设计图
不管你是晋升答辩、日常对接 、组内过稿还是面试讲项目 ，作为一个交互设计师，永远不要把一张设计图摊开来就开始讲细节：这里是什么颜色 、那里是什么排版思路…这不重要。
交互永远都应该以「项目目标」作为开场话题 ：pm 想做的是什么？要取得什么样的结果 ？甚至集团、公司想要的是什么结果 ？甚至 pm 所想到的功能方案是不是合理的 ？这个方案为什么值得我们投入设计资源甚至技术资源 ？我们要做的是以目标为导向的设计 ，否则毫无目的设计所带来的产物大多是四不像 。
2. 用"用户觉得"代替"我觉得"
挖掘 、定位用户痛点是交互设计师两件最重要的工作之一，另外一件则是解决挖掘到的痛点。在你开始讲你的项目之前，花几分钟和你的老板 、面试官介绍你的用户群体是怎样的？用户是在什么场景下完成整个流程的 ？他们有怎样的心理预期和行为习惯？
甚至在这个环节你可以把冷冰冰的 、抽象的用户数据串联起来 ，讲一个好像亲身经历的故事 ：比如你某次发现你们的用户如何使用产品 、他遇到了什么问题 ，你又是如何解决的 ？好的用户故事能让人快速感同身受 ，你也就不需要一遍一遍地向你的老板解释你为什么要做一件事——用户在这个场景下想要，就是这么简单 。
3. 介绍你的规划和假设
每个交互设计项目上线前都是一个黑盒。用户可能喜欢它 ，也可能不喜欢它。设计师之间 、设计师和老板之间 、设计师和产品经理之间打嘴仗永远无法真正验证一个问题 ，今天可能你发挥得好吵架吵赢了 ，明天可能发挥得不好只能回去挥泪改稿。
我认为为了真正说服你的听众接受你的方案 ，最好在介绍完方案后 ，直接说明设计方案中有哪些部分是基于推导和假设形成的 ：如何评估设计目标是否达到、如何进行后续优化迭代 ，如何制定数据指标 ？当然这对于一个快速迭代 、或缺少数据基础建设 、孵化的产品线来说可能是比较难的 ，但这是所有大厂的工作方法 。
4. 靠谱的方案输出
上面讲的所有建议都是针对设计展示时演讲的建议 。当然打铁还需自身硬，一个交互稿能够经得起推敲和询问 ，本质上还要靠完整的方案输出 。
交互稿有有很多种形式 ，比较常见的就是页面交互图 ，讲页面 、操作流程、组控件状态 、边界情况描述清楚以供视觉 、产品 、技术 、测试等同学使用 。一些复杂需求 ，建议在方案初稿输出后做可用性测试 ，这样就不至于在评审 、过稿的时候针对方案的复杂程度反复拉扯 ，可用性测试的证明足以一锤定音。
最后 ，我总结了交互设计的标准时间分布 ：
结合案例，到底怎么做 ？
最后我们再回过头看下文章一开头那些场景——想必现在你也知道问题是什么 、该如何解决了 。
场景 1
和 leader 确认交互方案时，刚讲两句就被 leader 全盘否定 ，导致自己带着 leader 没看一眼的稿子默默回到工位 、从头再来 。
问题原因 ：在一开始需求分析阶段就跑偏了 ，没有搞清楚目标是什么就开始做方案 ，导致后面的方案全盘跑偏。
解决方案 ：不要过快地深入交互细节 ，而是要让你的 leader 了解清楚需求的本质 ，对齐认知后再深入 ，不要被 pm 当时的方案带偏 。对方案时 ，可以使用数据等有利说明的方式讲清楚背景和目标 ，让上级快速理解需求 。
场景 2
和 pm 确认交互方案时 ，pm 一遍一遍提出疑问 、还说了 A、B 、C 、D 、E 各种想法 ，导致自己的方案反复修改 、无法按时交付 。
问题原因 ：这类型的 pm 大多只看最终呈现、缺少对用户行为逻辑的思考 ，非常容易陷入交互稿细节、拿不定主意 。他们需要的是用户体验专业层面的建议 ，告诉他们应该采用什么是合理的 。
解决方案 ：先把设计研究阶段的结论同步给 pm ，告诉他们因为是这样这样的问题，才有了最后的方案 。沟通过程中避免一些不确定 、显得不专业的词汇 ，如"我认为 XXX 、可能 XX、应该是这样的吧 XX" ，建议使用"用户在真实场景中是 XXXX 、从用户心理层面出发是 XXX 、用户习惯于 XXX"。
场景 3
向 boss 推自己的设计自驱方案时 ，无法得到 boss 的认同 ，导致最终无法争取到开发资源 、自驱项目最终流产。
问题原因 ：老板没有看到做这件事的迫切性、投产比 。
解决方案：和老板推项目时 PPT 非常非常关键。调研过程尽可能可视化出来 ，特别是数字 、结论。方案要完整 ，最好配合视觉设计师呈现出最的页面效果 、用 DEMO 演示 。
场景 4
面试官对作品集中的某个项目不断发问 ，而自己却难以给出令他满意的回答 ，导致面试最终失败 、无缘 offer 。
问题原因 ：大概率是存在两点问题 ：1. 项目没有达到设计闭环，缺少某一环节 ，比如设计研究不充分 、缺少效果评估；2. 设计研究结论与设计目标、策略没有完美对应 ，面试官质疑方案是否是以目标为导向 、是否可以解决问题
解决方案 ：检查整个设计过程中是否缺环节 ，特别是效果评估的数据指标应如何选取 、如何分析；检查设计推导过程和最终策略 、方案是否对应，逻辑要严谨 。
作者 ：白话说交互