交互动效制作的坑与随想

#时间永远是个问题
时间对于交互动效的构思到实现都是需要精确拿捏的要素。ios原生动画的时间大概在300ms左右,因此非原生的自定义动画大概也最好在250ms(人眼能反应过来的时间)到400ms左右。
dribbble上有很多fancy的动画效果,他们能给用户提供愉悦的情感以及充分的状态反馈。遗憾的是,这类作品中相当一部分的目标受众是设计师而不是用户。试想要等待邮件发送成功的状态需要等两三秒动画,是对于用户耐心的挑战。

面向移动端的设计本来就需要顾及用户所处状态——更加零碎化的时间以及更缺乏耐心的状态。在这种前提下,单纯遵循传统动画制作的准则,过度强调反馈和拟物化甚至是适当的夸张并不是出路。material design把拟物要素精简为对于material本身的模拟并且创造一种新的材质为内容的展示过程赋予新的意义。material类似现实生活中的物质却是其简化以及变体。或许现代的交互动画也应该把所在媒介本身视为新的物质,而非过度从传统动画中进行学习与仿效。毕竟传统意义上的动画呈现面向的受众,情形,以及受众对信息接受的预期和方式都有所不同。

#交互状态本身
交互动效是用户交互行为中的一个环节,所以交互动效的设计必须考虑其他交互状态的出现和呈现。为什么需要动效,最终目的是传达某些信息达到更好的体验。在这个前提下,设计交互动效之初就必须非常清楚这个动画的前后状态以及场景。假如设计一个用户注册登录的动效,那么必须连带考虑到各种出错状态以及因为网速不同带来的loading时间不同等情形。个人更偏向于优先展现内容框架而不是强迫用户必须看完长达2000ms甚至更长时间的动效。尽管有更多的时间动效可以更为细腻丰富,但是这些丰富本身可能与整体交互设计的目标——提升用户效率,有所违背。从这个角度反面来看,那些被各种状态限制得较少的动效反而容易精致。例如新产品引导界面和可离线游戏内的动画效果,因为在内容的加载上并没有过多限制所以动效发挥余地也更大。

#用户一千次,一万次使用这个功能
在实际工程需求下,只有重点功能和独特的控件才会有独立针对化的动效设计。许多通用性控件有着不可预期的使用场景因而动效设计偏向于保守以及简单。无论是何种情景,真正功能和控件被使用的频次以及传递的信息量都需要仔细斟酌。让用户在无数次使用产品的过程后,动效不会喧宾夺主阻碍用户尽快完成目标,是常用控件和整体框架的动效设计而言极为重要的一种挑战。甚至有时候需要反问自己,真的需要动效吗?真的需要如此强烈的动效表达吗?动效设计在整体配合视觉设计后是否传递了太多信息?从某种角度而言,理想的交互动效设计必须由在视觉、交互、动效制作方面都有一定经验的设计师进行负责,减少在此过程中的沟通成本以及强化对最终成果的责任,保证整体方案的最终效果有着一致性而不是视觉、动效、交互之间有所配合不当甚至互相冲突。

#逐步迭代
交互动效最终呈现的是一种整体方案,这种方案本身可能偏向于精致细腻的动效,也可能偏向于有着较好视觉效果却交互和动效本身较为简单。如果偏向于后者,那么从前期构思开始就无法忽略视觉效果的因素。甚至必须一开始画草图,并且同时开始搭建动效和视觉图的框架最终慢慢配合细化调试步骤。当然一些图形绘制的细节可以在后期慢慢修正,可是那些与动效呈现极为相关的因素却最好尽早在草案中进行修正。

这种需要不断迭代的生产方式也让我倾向于使用某些更为轻巧以及容易调试的工具进行动效产出和输出(或许sketch配合principle是比较好的前期调试工具 or adobe comet?)。与此同时,针对动效而言,迭代这种做法在不同阶段也有着不同意义。前期主要是大致确认这种路线是否能走通,逻辑和时间等要素上都没有重大缺陷。(可能需要做几个较为不同的原型进行对比)后期则在于无穷无尽的调试参数(可能需要记录参数、保存多个文件、disable和命名patch)等方式对于具体的呈现进行优化。越细致的调优,就需要花越多经历逐帧看动画效果的流畅程度以及尽可能多次操作感受交互上的细腻变化。

简而言之,交互动效制作就是个巨大的坑。

#一些小心得体验
善用贝塞尔曲线调节速度而不是简单粗暴的用时间上的delay会做出更为细腻的动效
适当做一个元件库和收集一些现有动效,好好围观后适当命名,日后会很有用= =。


从整体视觉效果上思考某个物件的重量,这样能更好的设计视觉效果和动效。

评论

此博客中的热门博文

关于产品设计 #这是个巨大的坑

书单 披着用户研究的皮却有着一颗好奇心(更新20140919

设计工具吐槽 之 protopie