在公司工作，任何职业都不可能单兵作战，协作是永恒的主题，而每一个需求和任务的实现，都是各方通力合作的成果。作为交互设计师，除了做好自己的设计工作之外，还需要花费大量的时间与产品、运营、客户端开发、前端开发、后端开发一起协作和沟通。

通常的合作方式是：产品经理撰写 PRD 文档并召开需求评审，各方一起参与评估需求，看看哪里可以实现、哪里有风险、哪里做不到，最后几经修改确定方案，投入设计，再进行交互评审、视觉评审，最后进入开发和走查。而交互设计、视觉设计因为位于开发实现之前、产品需求之后，扮演着一个承上启下的作用，是对产品经理需求的诠释和实现，也是为开发工程师绘制的工程蓝图。

但在实际工作中，我们经常遇到下面几种情况：

业务上，你做的方案有可能影响到了其他业务逻辑，如修改了下单规则会影响预售、限购等功能规则，或者你影响其他业务方的流量、曝光率等，这都称之为业务风险。

做好的设计稿在交互评审时，发现设计内容可能影响其他非本次需求范围内的页面，如风格不一致、交互方式不一致等，这称之为设计风险；

所使用的交互方案技术上无法实现，可能是代码逻辑不好实现（如接口调用方面的限制），可能是这种交互方式本身技术不能做到（如炫酷的动效），也有可能是受时间、人力所限，这称之为技术风险。

做好对这三类风险的预判，可以帮助交互设计师极大减少无用功，避免反复交互评审；能够经常对风险做出预判的设计师一定是对设计规范和业务逻辑非常熟悉的，这必然成为你的核心竞争力；当然，去做一个不仅仅会画图的设计师，相信同事们一定会对你赞不绝口，尤其在大团队，口碑可是极其重要的。

业务风险预判

很多设计师喜欢拿到需求就马上开始画图，并很快陷入到设计细节中，如字体字号、Toast 还是 Notification 等。殊不知，花点时间理解需求和业务逻辑，百利而无一害。建议设计师在平时就要对所负责产品线的业务逻辑有深入的了解，空闲的时候多去了解了解其他同事的工作内容是很有必要的。尤其是大型产品，往往业务之间存在高度交叉重叠，需求经常会互相影响。

举个简单的例子，大家可以去看一下，几乎所有的电商产品，已经生成订单号的订单都是没有办法修改收货地址的（如待付款等状态），而且经常有收到用户反馈说希望可以在付款之前修改收货地址，否则需要重新加入购物车提交订单。最初我发现这个情况，以为这是技术限制，即可能已经生成的订单在系统中会存在一个确定的编码，而改动其中的内容可能成本较高，尤其在大流量情况下会有技术风险。但事实上深入了解后，发现这是一个业务风险：电商产品中，除了普通购买商品，还有诸如抢购、区域限售、预订等消费形式，对于库存的计算规则也各不相同，如果允许修改订单地址，可能出现修改后的地址不支持相关服务或没有库存等情况。

如何进行业务风险预判？最重要的，是对业务逻辑、场景非常熟悉，才能知道你所做的设计会对别人产生什么影响，才能明确『设计界限』；其次，尤其要注意那些多个业务场景共存于一个页面的情况，非常有可能互相逻辑纠葛，牵一发而动全身；最后，还要深度理解需求的内涵，搞清楚这个设计任务最核心是解决什么问题，提升什么指标，千万不要单纯从用户体验出发，忘记设计的商业价值。

设计风险预判

大公司往往会有自己的设计规范，可能是组件形式、可能是颜色规范、也可能是视觉风格，总之常说，我们不是组件的生产者，而是组件的搬运工——没错，很多时候做的是利用已有组件搭建页面的工作。因此，当你在接到需求时，需要对可能遇到的设计风险进行预判。

组件的扩展性非常重要，当你在页面中引入一个新的组件时，首先要判断它自身能否承担已有的业务需求（文案展示、页面跳转、视觉展示空间），其次更要考虑它的扩展性，当多个不同属性的项目同时存在于其中时能否有效展示？

对于页面布局，需要考虑适配问题。你所做的设计方案可有考虑小屏幕用户的直观感受：iPhone 6 也许可以一行放4个按钮，那 iPhone 5 甚至更小尺寸的手机如何展示？色彩的选用也要考虑屏幕的色差，一直在 iOS 上查看设计稿的设计师也请一定要准备一台 Android 手机看看显示效果。

同一个客户端的同一个业务流程中，交互体验需要尽可能的一致。也许你改动的只是支付环节中的某一个页面，但是在其中使用新的弹窗就必须考虑其他页面的信息提醒是否也使用了这个弹窗，还是有其他的呈现形式。如果周边页面对于同一类信息的展示都有固定的样式，切不要搞特立独行，失去端对端的体验往往会造成巨大的用户认知障碍。

技术风险预判

由于技术是最终的实现环节，并且常常是设计师最不了解的领域，因此有意识地对技术进行风险预判就显得尤为重要。除了有些是技术本身不能实现的，还有诸多内容是受限于当前的技术方案，都要额外注意。举几个简单的例子供大家参考：

在设计中是否对常规组件提出了新的要求？

系统组件本身就会有很多的限制，比如你想在 iOS 自带选择时间的那个滚轮里，对不同的选项进行颜色区分，几乎就是不可能的，这属于系统组件不允许的范畴。而团队自己的产品可能有很久的积累，所用到的各种组件也有相应的限制，比如有些按钮可能没有 Disable 的状态无法置灰、有些 Label 组件中同一行的文字无法对单独的词语进行颜色区分（比如：本件商品18.00元，你想要单独对18.00设置红色，其他是黑色，就可能会遇到这个问题），请时刻提醒自己，能用现有组件解决的绝不要开发出新功能，尽可能不要使用新的组件，这成本远超你的想象。

同一个业务逻辑在多端的交互方式是否不一致？

交互方式不一致也可能是为了用户体验，比如移动端本来就和 Web 端场景不同，交互自然也不同。但是请注意，产品的无线端和 Web 端非常有可能共同一套后台系统甚至接口，你的多端多体验就有很大的概率导致这个接口需要开发来调整。比如同一行文案，在 Web 上是单行显示，在无线上由于空间所限可能需要分成两行，这就有可能需要额外的开发成本。

设计方案是否需要多次接口调用，影响性能？

技术真的不像你想象的那么简单。某产品在促销期间，有限时优惠活动，交互设计师可能认为只需要判断用户下单的时间是否在优惠期限内就可以了，殊不知系统有可能是进入下单页就要请求一次时间、点击下单要请求一次时间、还要和设定的时间进行一次对比，来来回回调用接口两三次，非常有可能在大流量并发的时候影响性能。

还需要注意的是，你的设计是否需要多个数据同时传输，比如商品名、SKU、优惠信息、运费等，它们很有可能来自不同的接口，不是一次性吐给你的。这种情况就还需要考虑如果其中有一个数据传输失败（信号不好）怎么办？是给用户提醒全部失败需要重新刷新，还是把别的都显示出来仅仅提示出错的内容，还是自动多次刷新，都需要经过深思熟虑。

设计方案是否可能过于炫酷，有技术实现难度？

过于复杂的动效固然逼格满满，但是开发同学最怕这种非常规交互。看似简单的弹性位移效果，就有可能要花费大量时间进行调试，更可能需要引入额外的第三方动效库来实现。在用户体验以及交互美观度的同时，也请一定要衡量一下开发成本，在能满足需求的前提下采用最有效的形式，切不要盲目追求动画的炫酷。

说了这么多，还是那句话——只会画图的设计师不会是满分的设计师。设计本身固然重要，但在工作中，学会与其他岗位的同学相互合作更能体现设计师的价值。提前对各类风险进行预判，利己利人，会帮助你快速成长。