交互文档中的动效设计表达

前提

本文讨论的动效设计表达基于类似origami类，基于逻辑与参数组合为基础的工具。与此同时，本文讨论范围也基于小团队特别是至少一位设计师能熟练使用origami类工具的团队。最好该团队使用Mac工作，并且拥有对于交互设计，视觉设计，基本代码能力的设计师。本文也不打算讨论偏向于展示以及较为复杂的交互动效如何与文档耦合。

#why

本文并不希望讨论为什么需要动效设计而是讨论为什么需要写这篇文章。关于动效设计，有许多传达方式。有些是基于AE，叙述层次关系以及时间线变化以及动效曲线参数，有些完全基于代码与其逻辑，如framer和许多js库。更有基于逻辑与参数组合的origami like工具。这类工具都能提供调试具体参数与变化的方式，但是对于整理具体功能以及交付相关文档给研发进行开发，完善的文档依然有必要。同时对于一个较大的项目而言，必然有不少与动效相关的输出物（因为许多origami file或是AE文件不可能做一个完整的产品，资源不足）。这些输出物需要有对应工具进行整理与反思以保证整套方案的完整性与一致性。

#具体业务之外，核心表达之中

对小团队而言，动效设计以及其文档表达始终有些尴尬。其一团队成员少因而时间有限，而部分动效高度依赖于高保真图与最终页面内的细节呈现。这也就意味着，本来小团队就更容易发生的高保真迟迟不能定夺现象，导致留给动效设计的空间极为有限。或许许多页面的呈现，比如从列表进入详情页面这个过程的动效并不过于依赖于具体业务。但是这类动效的展示却依赖于整个产品核心信息架构与理念上的清晰，比如基于卡片为单位传达信息与基于群组为单位展示信息，也应该有针对性的动效设计辅助使用者理解产品内不同的信息与层次。如果一个产品的核心方向始终摇摆不定，那么设计师容易不分场景较为粗暴的随便仿效或使用系统原生效果目标。

#文档内的粒度

个人建议文档内的描述基于单个的场景甚至是单独的控件且其中panel的变化较为单一。这种设计原则有两个考虑：其一是减少因为单场景内内容过多带来的复杂性，其次越大的场景内动效的设计越可能与多变的具体页面的相关业务耦合。即便针对简单场景的细致描述也考验交互设计师对逻辑和交互过程中各个状态变化的理解以及对细节到整体的把握。把粒度变小有利于通过更深入的把握细微的变化，从而更好的从宏观层面统合整个产品的动效甚至是信息展现逻辑。简而言之，减小文档内每个场景的粒度，是为了降低风险，也是为了细致的设计并且更好的统合。

#一些基本要点

正如origami的体系，一个layer最基本的属性是其anchor point 以及其与其他层的相对层次。在一个动效之中，每个layer变化的前提条件以及出发判断机制，是动效的基础属性。动效中一个layer的状态可能有多种变化，这些变化的方式和方向又是动效文档表达的另一基本要点。最后，作为最显而易见也是最需要多次调试数值的动画效果和具体参数，如duration和speed，则是动效构成中的不可或缺的组成环节。要对动效在文档内进行描述，必须给出layer在以上要素内的初始与完结状态内的值以及变化幅度和方式。总之，每个layer都必须给出基本初始属性，变化逻辑和触发条件，具体数值变化和参数，以及动画效果的参数。建议这些参数本身都尽可能独立并且寻找一定的方式合理表达。（比如某个层的pop动画应该与类似场景和层次中的pop动画数值相同，再如最好基于比例进行表达 如device-width/em）

#思考路径的逻辑化

关于动效设计，已经有许多文章讨论其设计原理与方式，但是本文希望指出一点。拥有好的想法与最终逻辑之间相差甚远。通过详细的文档以及制作原型，才能帮助设计师逐渐把效果落地转化为可供开发环境用之产物。单纯的视频、可交互原型甚至是口头描述与给出竞品，都无法真正传达这些内容。更无助于设计师仔细思考问题，并且逐渐培养把脑中的想象和最终效果表达的能力。研发对着一个原型和视频，恰恰会遗漏那些细节和参数。恰恰是因为需要调试这些参数，才要大费周折制作原型。

#小结

总结并统合origami内一些参数以及表达方式并且将其含括入文档内是为了更为清晰的传达给研发同事也希望能让设计团队更好的传承知识和经验。文档内记录的不仅仅是思考的结果而且也应该包括对一些方案的排除和分析，以及给出的解决方案所适用的场景。正是这些思索本身体现了设计师的价值，提供一套较为周全的解决方案。