针对不同设计阶段,如何选择合适的动效工具?

针对不同设计阶段,如何选择合适的动效工具?

动效是互联网产品设计中绕不开的一个话题,无论PC端还是移动端,产品要想提供细腻顺滑的体验,很大程度上需要依靠动效将不同界面、同一界面中的不同状态衔接起来,让用户直观地感知操作结果的可控性。

虽然在细分了交互和视觉岗位的情况下,通常会让视觉设计师承担动效制作的工作。但个人一直认为,动效一定是交互设计需要考虑的范畴,即使有人承担了这部分的具体执行,也要保证自己在动效方面具有足够的专业性。

近些年,在“万能的”AE之外,InVision、Flinto、Principle、Marvel、Protopie、Kite等大量专门为UX行业打造的轻量级原型工具的出现,也让动效工具和原型设计工具之间的界线变得模糊。

一些优秀的原型设计工具,可以很好地同时覆盖可交互原型设计和动效设计这两个重要的应用场景。其中,我个人习惯使用的两款工具主要是Principle和Flinto,配合万能的AE,个人认为可以覆盖绝大多数的应用场景。

在交互设计(分为产品流程设计和具体界面设计)、视觉交付等项目不同阶段,面对不同场景,能针对性地选用合适的工具,是提高方案表达效果和个人设计效率的重要一环。本文将根据项目中的不同设计阶段,介绍这3款工具的特点、分别适合哪个设计阶段,以及实际应用过程中的一些个人经验。

这篇文章不是教程也不是测评,因此不会涉及技法教学,也不会探讨是否有更好的工具选择。

虽然新工具层出不穷,但个人觉得同质化越发严重,核心features重叠性非常大,孰优孰劣只是熟练度和个人偏好问题。并且,每个工具都有不低的学习成本,精通自己喜欢的几个工具就好。

毕竟,工具只是用来解决问题的,掌握工具的数量和设计能力完全是两回事。


阶段1:产品级交互设计阶段

输出物:可交互的流程原型

推荐工具:Flinto

严格来说,流程原型不属于狭义的动效,只是产品界面和功能点的简单串联,但工具层面还是有共性的,所以也放在这篇文章里一起讲讲。

这里的“产品级”并不一定是指整个应用。

根据业务规模、迭代范围的细分粒度不同,一个链路模块,甚至一个营销活动玩法,都可能作为一个相对独立的产品线,进行版本迭代或者从零到一的设计。

对流程具有一定复杂度的产品而言,在提案、评审这些需要快速碰撞思路的阶段,传统用流程箭头标注的交互稿其实并不实用。

即使经过了很好的流程分解,对设计师而言改动返工量依然巨大,对老板而言又没时间仔细阅读你精心撰写的交互说明。

这时,迅速通过轻量级的动效工具产出可交互原型,可以帮助设计师在提案、评审过程中,让团队成员和老板更好地对方案的实际效果有一个更直观的体验。

在这个阶段,对制作旨在串联流程的可交互原型而言,个人心目中最适合的工具当属Flinto。


先简单讲一下Flinto和Principle的共性和差异。

两款工具同为UX行业专属的原型/动效设计软件,比AE更轻量级、更聚焦在行业高频功能上,同时都能快速输出MOV、GIF,以及在移动端上进行实际的交互体验。

两款工具有很多共通之处,底层思路都是定义元素的属性变化。但实现逻辑上却有比较大的不同:

  • Flinto:每个Artboard是一个界面,在元素上定义可以叠加的事件,在事件内定义不同State的切换。
  • Principle:每个Artboard只是一个界面的一个具体State,直接在画板上定义不同State的切换中元素的变化。

实际使用时,抛开更本质的差异不谈,最直观的差别就是:同样1张界面的设计稿,在Flinto里对应1个Artboard,而在Principle里会对应N个Artboard(且会直接把切换逻辑用箭头的形式标在不同Artboard头顶)。

这点上的不同,决定了Flinto优势在于产品级复杂流程的表达,而Principle更擅长单个界面(或很短的流程)的交互细节表达,处理多界面流程时会让工作区域变得乱七八糟,甚至隔几个小时再看的时候连自己都看不懂了。


对流程串联而言,Flinto是我用过的工具中最快的(有更快的欢迎推荐给我)。

以基于地铁查询工具的心情分享平台“一站”的主流程串联为例(鉴于工作中的案例不便讨论,专门为设计交流做的一个概念方案,背景见链接):

https://www.zhihu.com/video/925869375356043264

流程原型对应的Flinto源文件如下:

在Sketch中设计稿准备妥当的情况下,下面这个原型只需要20多分钟就能做好——这还是在实现了层级分离和滚动效果的情况下。如果只是快速输出静态页面的串联,时间可以再缩减一半以上。

在制作流程Demo时,只需要表达基本的页面结构与跳转关系即可。转场无需表达得很准确,以不引起误解为原则即可,时间有限的情况下,最简单的处理方式就是统一用渐隐渐现。

各种与页面滚动位置有关的动效也暂时不用表达。同样,也完全没有必要让每个元素都可点击(当然核心交互还是要做的),更没必要在这个阶段考虑非常完整的用例。

明明在交互稿上可以用交互说明一两句话就可以说清楚的事情,完全没必要费尽周折做在流程原型上,万一做好后逻辑又改了呢?


提到这里,忽然想起前两年交流Axure制作高保真原型时,有的朋友执着于在原型中用中继器把各种变量逻辑表达得非常准确。个人觉得,除非改版就是针对这些细节所做的,否则必要性不是很大。

交互稿和可交互原型是一对相辅相成的存在,很难用一方完全替代另一方。就像买家电的时候,原型相当于在商场观看宣传短片,直观感受流程逻辑和大体布局;交互稿和交互说明相当于说明书,细化各种用例状态。


阶段2:界面级交互设计阶段

输出物:动效录屏/GIF

推荐工具:Principle

在产品流程和信息结构确定后,具体界面的交互设计阶段,就轮到对各个动效逐一进行细化。

应用中常见的动效可以大致分为交互动效和播放动效两个大类别:

- 交互动效:与用户交互行为相关的界面间的转场、界面内的组件反馈与层次暗示等动效都属于交互动效。

- 播放动效:纯自行播放、与操作元素无关的动效,如启动、入场、Loading、空态界面,多数是为了吸引用户注意力、情感化设计和创意需要。

关于动效的分类,这里不再展开,展开深究的话完全是另一个很大的话题了。


纯播放类的动效可以不在这个阶段细化,在视觉设计阶段再直接产出并交付。而交互动效的设计则是这个阶段必不可少的工作。

对不涉及位置联动的交互动效而言,在Flinto和Principle中的制作成本相差无几。例如下面这个纯粹由点击触发的事件:

但对于涉及位置联动的动效,Principle就比Flinto的表现优秀很多了。Principle中,时间轴和位置联动的设置比Flinto自由度更高,可以快速进行精细的设计和调整。例如下面这个站点列表界面的上滑动效:

上滑中,随着Y轴位置的变化,存在一系列的子动作:A.顶栏信息缩略;B.二级Tab吸顶;C.回顶按钮呼起;D.右侧快捷检索器的高亮切换。

同时,回顶按钮、快捷检索器又有相应的点击动作:E.点击回顶按钮,返回页面顶部;F.点击检索器字母,页面锚定至相应位置。

因此一共合计6个动作需要在动效中表达,并且同时包含了点击事件和滚动联动,这时候用Principle做起来就非常方便。不过这个例子并不是特别复杂,Flinto中大概同样也能找到办法实现,只是做起来会比Principle麻烦不少。

动效中,缓动曲线与时间的精调是一个比较考验经验的活——运动的元素是材质是刚性还是弹性、怎样的缓入缓出更自然、是否需要惯性和“助跑”、多个元素之间是否需要时间差……等等,都可以参考迪士尼动画12原则仔细寻找最优解。

但在交互设计阶段,其实没有必要太过细致地考虑。缓动曲线暂时采用EaseOut(先快后慢)通常没有太大问题,可以在视觉设计阶段再精细调整;时间设置上符合大原则即可,单个属性的变化一般在0.5s内,单个交互行为触发反馈动效的总时长尽量控制在0.8s内。

另外,在制作动效时有时我们经常会顾虑“会不会动太快了”,这是因为我们在孤立地盯着单个动效看,对时间的感知并不能代表用户实际操作时的真实情况。

在真实用户的使用过程中,触发某个交互行为时,动效只是其体验路径中一个极其短暂的中间态,动效时长稍微偏长一点都会导致体验有拖泥带水的感觉。


这里再思考一个问题,流程原型中适不适合同时呈现完整的交互动效?

我的个人想法是,流程很短或者涉及到的交互动效很简单时,可以考虑将交互动效直接体现在流程Demo上,让流程Demo的呈现效果更接近最终的设计意图。

其中,交互动效复杂而流程简单(比如只涉及两三个界面的跳转)时可以统一在Principle内完成;反之,流程复杂而交互动效简单时可以统一在Flinto内完成。

但从我的个人习惯来说,依然并不建议这么在流程Demo中过分追求准确地体现每一处交互动效,因为一旦修改,改动量实在是太大了。

不同问题分别独立解决,这是我一贯的原则,大可不必纯粹为了让流程Demo效果更好一点就多花成倍的时间成本。

所以,实际项目中,我通常都是用原型串起产品流程,然后将需要描述的交互动效拆分成一个个单独的交互动效进行录屏(或输出GIF),放在一份Keynote里逐一展示并说明,作为交互文档的附件在评审中展示或者交付开发,便于开发初步理解设计意图。

下图就是一份动效说明文档大致的格式示例,主要包括动效录屏和交互说明两部分:


阶段3:视觉设计阶段

输出物:动效标注或其他形式的交付文件

推荐工具:Principle/AE

大多数的常规动效其实在Principle中都可以实现,因此在视觉设计阶段,一般继续在交互设计阶段制作好的动效基础上进行精细化的微调就可以了。

如果一个发现一个交互动效Principle做不到,只能用AE实现,那首先要做的不是打开AE开始干,而是重新审视一下自己的构思,是不是太复杂了?用户是不是真的需要这样的动效?

当然,涉及路径的动画是Principle的软肋,确实需要AE出马,这种情况另当别论。

而播放类动效通常肩负着创意和情感化的需要,多数情况下确实需要用AE来制作。制作完成后,可以产出PNG序列,或者通过Lottie产出json文件直接交付开发。

当然,这个并非本文的讨论重点,下面主要还是介绍交互动效的标注和交付。


世上最恨动效的人恐怕就是开发老哥了。

设计师“跪”开发时,最常听到的三句话大概就是:“能不能砍”、“能不能出个降级方案”、“那优先级最低吧”。

一方面,别说直接承担工作量的开发了,有的产品有时都视动效为“无法直接创造业务价值”的东西,认为把动效写这么好,还不如这个版本多排一个新功能进来,或者至少认为应该把动效的优先级放在所有功能性研发之后。

另一方面,动效的标注确实不那么容易。对配合默契的开发来说,把Principle源文件发给他,他自己就会查找到所有需要的信息。但在这种理想情况之外,就需要手动写标注了。

有的设计师习惯只提供GIF或者录屏给开发,让开发自行揣摩各种细节,先实现出一个看起来差不多的,然后再坐在开发身边blabla地让开发“这调快点”、“那调慢点”,导致开发老哥对调动效产生了先入为主的抵触情绪。

所以,给开发提供准确的动效标注,对合作而言很重要,即使交互动效的标注不像界面标注一样有直观的表达方式。


任何标注都没有一成不变的形式,目的都是为了把核心信息表达清楚,交互动效的核心要素通常很简单——属性变化、时间轴和贝赛尔曲线,涉及位置联动的要特殊注明。

标注形式上其实没有什么条条框框,只要把上面提到的核心要素表达清晰,并附几个典型状态(通常首末态就可以,有必要的情况下也可以放中间态)的设计稿便于开发确认就可以了。

下面用一个小例子介绍一下个人习惯的标注方式。

我们再看一次这个从专题Tab点击进入专题详情页的动效:

先看一下它在Principle中的实现方式:

其时间轴如下图所示(如上文所述,合作默契的开发完全可以直接打开源文件,了解他希望知道的任何信息,这是最理想的状况):

这里为了举例清晰,不对所有属性变化逐一阐述,只单独把专题的头图(底图,而不是外面的圆角卡片)拎出来。在标注中,只要逐一列出运动对象(最好加上前缀,保证元素在项目中命名的唯一性,与开发老哥的命名一一对应对后续维护大有好处)、变化的属性(这里只涉及X/Y坐标与宽高变化)、贝塞尔曲线,并在时间轴上标出始末锚点和相应的值即可。


小结

  • Flinto:能极速串起复杂流程的神器,但精细度较高的交互动效制作难度较大(虽然也能找到一些很hack的黑招),可以输出可交互Demo。
  • Principle:可方便地实现复杂、精细的时间轴、联动设置,但不适合制作整个产品的流程,同样可以输出可交互Demo。
  • AE:“高大全”的万能工具,在路径型动效、包含复杂创意的播放型动效上具有不可替代性,与Lottie的协同让设计交付和开发实现都变得轻松愉快。但并非行业工具,处理简单动效上“杀鸡用牛刀”效率不高,无法同时作为可交互Demo使用。

讲了这么多,最后强调一点:动效不是炫技

许多花哨的动效初看惊艳,落地到实际应用中只会让用户觉得拖沓、耽误时间。

尤其对效率型产品、高频产品、高频操作而言,设计尽可能简单轻快的动效,可以让设计轻松、开发轻松,用户也轻松:)

文章被以下专栏收录