动效评审：找出那些不会写在原型里的风险

动效评审：找出那些不会写在原型里的风险

先验证被忽略的输入方式

键盘、读屏和低性能设备常不在原型里。关键状态不能只靠位移和颜色表达，保留文字或图标反馈，才能让每种使用方式都看得懂。

原型通常只展示一次顺利完成的播放。评审时要追问：用户打断怎么办？数据没回来怎么办？页面不可见时还在跑吗？有减少动态效果偏好时是否保留必要反馈？这些问题比“曲线够不够丝滑”更影响上线质量。

用明确的问题审查实现

确认动画属性是否会触发布局，图片和滤镜是否有尺寸上限，循环是否会在后台暂停，结束回调是否会在组件销毁后继续执行。风险需要结合实际代码和设备测试判断，别凭一个名词下结论。

const controller = new AbortController();
await runMotion({ signal: controller.signal });
// 页面卸载时调用 controller.abort()

不把数字当作保证

帧时间、包体和能耗都应在明确场景下测量。评审记录写出测试路径、已知限制和下一步验证项，不编造事故或性能百分比。这样设计、研发和测试讨论的是同一组可复现条件。

把问题按影响范围排队

动效评审很容易被“顺不顺”带偏。更有价值的做法是先问：它是否改变了用户对当前状态的判断？加载动画一直循环，会不会让用户以为请求还在进行；删除后的淡出效果，会不会让用户误以为操作还没完成；错误提示弹出时，焦点有没有真的移动到可操作的位置。把问题写成这些具体问题，设计和开发才能讨论同一件事。

不同输入方式也会得到不同结果。触摸设备没有 hover，键盘用户需要看见焦点，读屏不会感知颜色和位移。评审时至少走一次键盘路径，并开启系统的减少动态效果选项。若动效被关闭，关键的状态变化要用文案、图标或布局补出来，不能只剩一块无声变化的颜色。

我会按阻断操作、造成误解、影响舒适度三类处理问题。前两类应该在上线前解决，最后一类可以记录为后续优化。这样不会因为一条阴影过渡而拖住发布，也不会让真正会误导用户的转场混在视觉偏好里。评审结论写清影响和复现步骤，比给一个模糊的“体验不佳”更能推动修改。

先处理会卡住操作、造成内容误读或持续耗电的问题，再讨论曲线和缓动的细微差别。一个背景循环在页面隐藏后仍不停，通常比按钮淡入快一点更值得修。评审记录里写清问题出现的条件、影响的组件和建议处理方向，后续负责人就不用从截图猜上下文。

原型没有覆盖的路径可以主动补出最小演示：网络图片加载失败、重复点击触发、系统开启减少动态效果。并不需要为每个动效建立复杂测试体系，但核心交互至少要能在这些状态下稳定结束。评审结论也应允许保留未知项，例如某台低端设备尚未验证；比起写一句“表现良好”，这样的记录更能帮助下一次迭代。

若页面支持撤销，也要确认动效不会掩盖撤销窗口的时机。反馈可以柔和，但可恢复操作的入口应当清楚。用流程风险来排序后，视觉讨论就不会占掉真正的验收时间。

结论应能落到修改项

一次动效评审结束时，我会把发现的问题对应到属性、资源或状态处理，而不是留下一句“再优化”。例如停止后台循环、移除会触发布局的动画，或给无动画路径补上结果提示。这样负责人拿到结论能直接改，下一轮也能核对问题是否真的消失。