编辑导语：如今产品中的动效设计非常重要，可以为用户提供了良好的动态沉浸式体验；动效的重要性在于将交互、视觉过渡处理的更加细腻，而且能够承载更多的信息；本文作者分享了关于动效设计怎么完美的对接开发，我们一起来看一下。

本文分享和研发对接动效的方式，让研发拿到我们的文档能够快速上手。

先来个大纲：

• 需求来源
• 低效率的沟通方式
• 动效文档如何制作

这篇文章起源于工作中一次与开发对接动效时遇到的诸多问题，一定也有许多人跟我一样遇到这些问题，所以想把自己一些经验分享给大家。

正所谓，工作中少走一点弯路就相当于进步了。

事件背景：

之前做了一个旅游网站的项目， 设计完后，前端已经开始实现了，老板说想要网站“动”起来，加一些动效让旅游网站更好看更吸引人。

嗯，boss的意见？

好的，收到，没问题！

当然，老板的出发点是没问题的，这个旅游网站主要也是让用户浏览观赏用，那么动效设计在产品策略上也算是锦上添花甚至是不可或缺的。

说干就干，早上接到这个需求后，前端和我商量说打算怎么做，我想了想，之前我并没有这么系统地和前端交接过动效，正好趁此机会梳理出一份动效文档，日后也可以复用。

当前在之前也有过类似需要动效设计的场景，但动效量没有这么大，加上手上需求比较多，一直没有系统梳理过动效文档，所以踩的坑也是一箩筐的。

所以下面的内容不仅仅会说动效文档的制作，也会把我在工作中遇到的坑给大家一一分享，帮助大家排雷。

一、需求来源

一般动效这样的需求可能来源于：

• 老板/上级
• 甲方
• 自己

「为啥会有自己呢？当你觉得界面平平无奇想搞点事情的时候，需求就产生了，当你做到一半觉得过于复杂懒的搞的时候，需求就鸽了，自己的需求自己必须做主！」

当收到老板和上级的动效需求时，第一反应当然是OK啊！

但咱也不应该全盘接收，显得自己没头没脑不是么，咱们也得衡量产品的业务逻辑和方向，评估目前手上工作量的优先级后才能做出决定是需要马上给出方案还是可以押后再议甚至需要考虑到是否有必要增加动效。

毕竟，一个产品必须得先满足可用性和易用性。

第二个动效需求的来源是甲方。

甲方很多时候总是想要多一点，再多一点……

这时候跟上面一样，同样需要评估必要性和实现难度的问题。

其实甲方的终极目标是想解决问题，而不是一股脑堆砌功能，有时候虽说甲方会坚持己见，但是不代表我们不能发表自己的看法或提出更优质的方案，至于选择哪个方案，是否选择我们的方案，那是甲方的决定。

但是我们保持沉默和提出选择方案是不一样的，后者会显得我们更专业，不是么。

第三个动效需求是自我。

作为设计师，我们的目标不就是解决问题吗？

当解决一个问题后，会让人觉得特别有满足感，因为这是一种证明自己价值的方式。

那么在一些时候，为了产品使用更加顺畅，转场更加自然舒适，我们会在某些地方添加一些动效，这时候需要说服的可能是一整个产品团队，包括了产品经理、开发还有你的老板，毕竟，这都是需要工作量的……

二、低效率的沟通方式

前面提到，在开始制作一份动效文档之前我和开发也沟通过其它琐碎的动效实现问题，遇到了很多坑。

下面就这些“坑”展开来讲，旨在帮助大家在工作中与开发更好地沟通。

没有动效文档的时候设计师是如何跟开发描述自己的动效设计的？

补充：下面说的动效指的是让开发写的动效，而不是我们提供的GIF或其它动效文件