【加更】百度资深交互：交互新人的你，方案为什么不堪一击？

本周特邀前百度资深交互设计师薏薏来讲讲自己从交互小白一路升级打怪的过程，薏薏从纯理科转行设计，从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.靠谱的方案输出

上面讲的所有建议都是针对设计展示时演讲的建议。当然打铁还需自身硬，一个交互稿能够经得起推敲和询问，本质上还要靠完整的方案输出。

交互稿有有很多种形式，比较常见的就是页面交互图，讲页面、操作流程、组控件状态、边界情况描述清楚以供视觉、产品、技术、测试等同学使用。一些复杂需求，建议在方案初稿输出后做可用性测试，这样就不至于在评审、过稿的时候针对方案的复杂程度反复拉扯，可用性测试的证明足以一锤定音。

最后，我总结了交互设计的标准时间分布：