现在很多互联网公司都设置了交互岗，理想状态下， 交互设计师是 “用户的代言人”、“体验的捍卫者”，但事实情况如何呢？

相信在职的各位都比较了解现状，产品功能怎么做、流程怎样，基本都是产品经理在决定，而交互设计师已经沦为“线框图绘制员”，这是我们最不愿遭受的处境，该如何改变这样的现状呢？

下面我以一个百万用户级别的真实案例来详细说明，如何通过几个步骤让交互设计发挥应有的价值，使你在拿到PRD之后，对产品架构和流程获得主导权，得心应手的做出令人满意的交互稿。

1，统一战线，弥补信息断层

产品和交互之间最根本的矛盾来自于哪里？其实就是对于业务背景的把握，正因为交互对于业务了解不够深入，就只能往用户体验的角度使劲，而产品经理始终在为业务出力，所以就变成了两个战线。如果交互像产品一样懂业务，就起码能够团结一致，肯定不至于被牵住鼻子。所以第一步，统一战线，主要就是迅速了解业务背景。

一般情况下，互联网公司的常见项目有以下几种：常规型迭代（增删功能或优化），重大改版项目，新产品项目，活动类项目。第一类还好，因为如果有常规迭代的话，说明你在一个较为稳定的产品团队里，长期维护一款或几款产品，这样的情形，交互设计师对于业务一般也比较了解，很少存在认知断层。

今天主要讨论后几类，这些项目一般发生在需求响应型设计团队中（并没有主要负责的产品，来什么需求干什么活的那种设计团队）。在这种情况下， 一般都是需求方（运营、销售、客服或产品等）先找到产品经理，他们经过分析、思考、讨论，形成了初步方案，然后再找交互来落地。所以你发现了没有，当产品拿着PRD找到你的时候，其实已经和需求方基本达成了一致，而且是在较长的沟通基础上，这时候接手必然意味着信息不对等。

所以这第一步就显得尤为重要，能否做好直接决定了你在整个项目中的地位和话语权，进而直接影响交互方案的产出质量。

那这一步要怎么做呢？

要消除信息断层，首先是和产品经理充分沟通，多问为什么。“为什么要改版”，“为什么增加这个功能”，“为什么是这样的实现方式”，“我们的用户是谁”，“用户行为数据怎么样”，总之努力做到跟产品经理信息对等，了解业务、了解战略、了解用户、了解当前状况与下一步方向。然后是在有业务方的情形下，一定要直接接触业务方。比如某个需求是运营人员提上来的，那就找到他，聊明白为什么会提出这样的需求，当前的解决方案是如何得到的，是否已经是最优解等。

实例讲解：之前笔者在某电商公司任职交互设计师，有一天某产品经理找到我，直接了当：“我们要做一个新品答题的活动，这里是我画的原型，你尽快做出交互稿给UI，你看2天可以吗？”。这时候如果是初出茅庐的交互新手，肯定就直接拿着产品的原型出交互稿了，但我给他的回复是：“先不着急，坐下来给我说说为什么做这个活动吧”，然后产品便给我解释了活动的目的：因为用户对新品越来越重视，但新品的获知率并不是很高，所以需求方（负责某品类的运营小伙伴）希望通过一个传播性的活动来宣传新品，因为新品往往都有一两个卖点，所以他们认为答题的方式非常适合，即可以认识新品，又可以将新品的特点加深映像。

了解到这些之后，我提出“为了交互方案更加符合需求方的意愿，所以需要与需求方直接接触”的要求，产品经理主动引荐，我问了需求方很多问题，比如“要推哪些新品，预算多少，活动入口在哪里，每次活动推一个新品还是多个，时间规划怎样，预期目标是什么”等等，基本就是全方位了解了这个需求的出发点和落脚点。

这时可能有小伙伴质疑：这样的多方沟通会不会增加时间成本，他们已经基本确定的方案应该也是经得起推敲，直接了解结果是不是更好？其实不是的，都知道磨刀不误砍柴工，沟通再充分都不为过，只要不是反复的低效的沟通，都是有价值的，做设计时间长了都会发现，如果不了解最初的目的，往往很难真正解决原始的问题。

2，深入解读，了解产品逻辑

（这一步的前提是产品经理画了原型，如果没有的话，可以跟产品经理一起构思产品逻辑）
当了解了业务背景和目标之后，就可以详细阅读PRD了，一般情况下，PRD会呈现功能流程与基本的页面设计，有的产品也喜欢将接口等技术指标写进去。

这一步的关键是坚决避免直接开干，要做到不做评判的纯粹的输入。首先是充分了解产品经理的设计方案，并聊清楚各个功能点的细节和背后的目的（结合第一步的业务目标），做到知其然也知其所以然；然后是前端后端技术能力与限制（交互设计不用太懂技术，但是一定要明白技术能实现到什么程度）；另外是聊明白产品经理的底线，一般情况下产品经理喜欢在界面上堆各种东西，交互设计师喜欢砍掉他们的东西，所以这一步要明确哪些地方有商量余地，哪些坚决不能变。比如之前的实例中，我了解到产品经理的底线就是新品宣传方式一定为答题，这个形式不能改变，其他的像题目如何呈现，分享如何做，这些就可以由交互来决定。

实例讲解：接着上面的例子，通过第一步我明白了新品答题活动的背景、目标和达成目标的基本手段，在这一步就开始认真解读PRD了。通过PRD的设计方案，我明白了具体的玩法，主要就是让用户答题获得一定的利益，同时为新品的商品详情页引流，在这个过程中加深用户对于新品的印象。答完题后还可以分享出去，邀请好友来答题获得更多利益，这也是社交裂变的常规玩法。以下便是产品经理的部分原型：

新品答题活动原型-来自产品经理

出于版权问题，我们只解读这两页。先看整体：这是一个常规的活动主页，有活动标题，活动规则，活动成绩，核心任务（答题）和次要任务（分享）。左边的首页解读：

1，右上角的活动规则和我的战绩不必说，左边的答题秘籍我当时没看懂，问了产品经理才知道是进入商品详情页的链接（因为商品详情页肯定会介绍商品的特点，所以就包含了题目的答案）。
2，下面是活动标题和时间线，说明活动的阶段。
3，再下面是核心板块：题目卡片。此次活动一共4道题目，4个新品，可以滑动切换。题目下面是四道题的已答和未答状态展示。
4，然后是分享按钮，提示利益点，再下面是推荐商品，不必细说。
另外，产品经理要求每个问题回答之后，卡片会翻转，来进一步总结这个新品的特点。右边的战绩中可以看到分享出去的内容，有答题时间和根据答对的题目数得到的称号。

嗯这一步了解到这些就差不多了。往下走~

3，赤膊上阵，产出设计方案

在完全了解了产品经理的方案之后，我们就可以真正开干了。相信通过之前的深入了解，你对项目的功能点和实现方式都已了熟于心，所以我提倡的方法是：抛开一切，重新设计。这样可以充分表达你对于项目的独特理解，避免产品经理的方案对你造成限制。

另外，在真正产出交互稿之前，最好的工具是纸和笔，它可以帮助你快速落地想法，高效沟通，快速迭代。所以这一步依然不能闭门造车，在迅速产出草稿之后，就要第一时间和产品沟通，看你的设计方案是否可以更好地解决问题。当然如果产品经理的方案已经足够好，交互设计阶段就只需要调整和补全细节，不必为了不同而不同，这样只会招来非议。做出不同的方案一定要有充足的理由，并且可以说服产品经理。

可见，这一步多半会发生很多的碰撞和摩擦，成熟的交互设计师可以通过专业的设计方法、合理的设计依据，最终通过层层评审，确认交互方案。

实例讲解：还是上面的新品答题，我以专业眼光进行了再设计：

我产出的原型

主要的设计点已经在图中说明，总结一下的话考虑了以下几点：一是容错性管理，交互设计一定得充分考虑用户操作中出错的状况，像上面左图中如果答题后直接提交还不能修改，就会引起误操作下的负面情绪；二是屏幕空间管理，首屏的位置非常重要，非必要的或者不重要的一定要往下放或者去掉；三是用户注意力管理，在引导用户做一个任务的时候，需要注意不被其他因素打扰，最好是“一个页面一个核心任务”，特别是对于这种可做可不做的活动，用户的耐心极其有限，必须非常小心。

除了以上这些，你们有没有发现我在战绩里去掉了答题时间这一项，产品经理一开始不同意，但当我说出理由，他就马上不说啥了，我的理由是：如果有答题时间这一项，就会暗示用户加快答题速度，这样就减少了去看秘籍的行为，进而降低给商品详情页引流的数据，这就与业务目标相违背了。后来产品上线后，引流数据还不错，他还专门来感谢我了嘻嘻。

到这里，这个项目的产品逻辑和页面设计细节就都确定下来了，我们就可以输出交互文档了。

4，输出文档，完善交互细节

这一步之前，交互方案已经确定了，但为了开发人员与UI设计人员能够更好的看懂方案，减少沟通成本，还是需要输出规范、完整的交互文档。

关于交互文档的文章已经很多，大家可以自行查阅，我在这里强调两个重点：第一是交互文档一定要完整。页面跳转、不同条件下的不同状态、数据的来源与显示的规范等，必须要全部涵盖。这里评判的标准是：前端与UI不需要问你问题就可以明白所有产品逻辑与细节。不过这一点做到也很难，需要多沟通多总结，最终形成自己输出的套路。第二是交互文档避免追求华而不实，比如有的人会做很多花哨的动效，有的人会花很多时间做可点击跳转的原型，有的会在UI排布上过于精细，这些都不利于聚焦于交互本身。要始终铭记交互的本职是在满足业务目标的前提下，用最简单明了的方式实现产品功能，功夫一定要花在刀刃上。

实例讲解：以下就是新品答题活动的部分交互文档：

部分交互文档

关于交互文档，每个公司、每个团队甚至每个设计师都有自己的不同风格，这都无所谓，关键还是那句，前端与UI不需要问你问题就可以明白所有产品逻辑与细节。只要做到这一点，就是好的交互文档，至于用什么工具，呈现方式如何，都可以自行决定。

以上就是我想分享给大家的工作方法，希望给大家带来一些帮助。祝各位交互设计师在新的一年能够与产品经理、程序员们和平相处，共同进步！