Tokens
曲线、时长与效果形成统一调用语言。
系统设计 · 从0-1搭建
PICO OS 动效设计体系
从动效语言、Token到18类OS控件，建立一致且可研发调用的交互规范
系统设计 · 从0-1搭建
PICO OS 动效设计体系
从动效语言、Token到18类OS控件，建立一致且可研发调用的交互规范
我的角色Motion Design / 体系搭建
项目范围动效原则与控件规范
协作UI 李秋豪 / PM 杨英华 / 研发 黄朝阳、李鹏
覆盖18 类核心控件
先解决一致性，再谈表现力
系统内已有大量动效需求，但缺少可复用的语言和调用方式。同类反馈容易出现不同节奏，设计意图也难以被研发准确复现。
我的目标不是增加更多动画，而是定义一套团队共同理解的判断标准。
语言规则Token控件
把感觉拆成三层规则
用稳定的底层变量支撑组合方式，再通过控件规范进入实际产品。
Atomic motion
Alpha、Scale、Size、Rotate、Colour、Position 六类原子属性，组合出完整状态变化。
Components
为交互事件、状态切换与显隐建立参数规则。
Token 让节奏可以被调用
曲线定义运动性格，时长跟随范围、出入场方向与复杂度变化。
P.motion.easing.standardcubic-bezier(0.34, 0.69, 0.1, 1)
Short60 - 240 ms轻量控件反馈
Medium300 - 480 ms中等范围位移
Long540 - 720 ms较大范围过渡
Extra long780 - 960 ms复杂或大范围变化
16 档时长预设
以 60ms 为递增单位形成四组 Token。运动范围越大、元素越复杂，持续时间越长；同一元素的入场通常长于出场。
Short
- short1
- 60ms
- short2
- 120ms
- short3
- 180ms
- short4
- 240ms
Medium
- medium1
- 300ms
- medium2
- 360ms
- medium3
- 420ms
- medium4
- 480ms
Long
- long1
- 540ms
- long2
- 600ms
- long3
- 660ms
- long4
- 720ms
Extra long
- extra-long1
- 780ms
- extra-long2
- 840ms
- extra-long3
- 900ms
- extra-long4
- 960ms
区域范围运动范围与时长成正比，大屏和大范围变化需要更多时间。
入场与出场入场需要被用户感知，持续时间通常长于对应的出场。
复杂程度参与变化的元素越多、关系越复杂，持续时间越长。
用四类场景约束动效目的
每段动画都需要解释它在沟通什么，避免为动而动。
展现与消失
建立元素出现、离开与层级变化的连续性。
转场与过渡
帮助用户理解页面、面板与内容之间的空间关系。
响应与反馈
即时回应按压、选择、完成和错误等操作结果。
指引与加载
解释等待状态，并把注意力带向下一步。
6 种原子属性
完整动效由基础属性组合而成。悬停每个示例可查看属性变化。
Alphaopacity
Scaletransform: scale
Sizevisual bounds
Rotatetransform: rotate
Colourbackground-color
Positiontransform: translate
组合后的最佳实践
原子属性与 Token 组合后，形成可直接复用的过渡方式。
创建连接完成
从原则进入 18 类控件
我把统一语言继续拆到按压反馈、状态切换、显隐和手势四组控件行为中。
Pressed / UpOverlay #FFFFFF00 → #FFFFFF29
Normal / Activespringeasing-rapid + Dot delay 50ms
设置已保存
Show / HideAlpha 0 → 1, Scale 0.95 → 1
Gesture driven实时输入手势速度，释放后吸附到目标状态
选择与输入Button, Chip, Checkbox, Switch, Segmented Button, Text Field, Number Field, Slider
进度与提示Progress Circular, Progress Bar, Page Indicator, Toast, Snackbar
容器与导航Side Navigation, Share Sheet, Modal Sheet, Dropdown, Alert Dialog, Timepicker
交付的是共同语言
每个控件按 Interaction Event、State Change、Element、Parameter、Token 的结构描述，研发可以直接映射实现，设计也能沿用同一判断逻辑继续扩展。
TriggerPressed / Up
ElementOverlay
ParameterAlpha / Scale
Tokenspringeasing-rapid
PICO OS Motion System
从单次设计，变成可持续扩展的系统资产。
角色
核心负责人
时间
2022-2023
团队
PICO OS设计团队
项目背景
PICO OS从5.0向6.0迭代时，暴露出系统性的动效体验问题。作为核心负责人，我从0-1搭建了覆盖VR/Web/App多端的动效设计体系。
问题诊断：三个层面的系统性缺失
① 用户体验层：不一致、不流畅、缺反馈
- 动效缺失与切换生硬：界面直接硬切无过渡，hover状态露白底，瀑布流页面切换无层次感
- 卡顿掉帧：多数界面动效存在卡顿，图片轮播不流畅，操作反馈迟钝
- 风格割裂：同一Title Bar出现三种不同的hover效果（大通栏/竖列矩形/无效果）
- 状态缺失：按钮无hover/normal态区分，加载状态只有白底无内容
② 团队协作层：无规范、无组件、重复造轮子
- 从零开始：设计原则和研发动画框架均缺失
- 没有Token体系：无统一曲线预设和时长规范，每次需求重新调参
- 没有组件化：按钮、导航栏等基础元素各写各的，重复开发严重
- 缺乏统一语言：设计与研发缺乏对齐标准，沟通成本高，质量参差不齐
③ 业务影响层：品牌受损、转化受阻
- 品牌专业性受损：官网缺少基础交互动效，Web端体验不流畅，降低品牌信任
- 转化效果差：官网被归为"转化结果差"的问题范畴，信息层级不合理
- 多端不统一：VR/Web/App各端动效各自为政，缺乏统一设计语言
核心矛盾
"无规范、无组件、无框架"的三无状态，导致用户体验割裂、团队重复低效、业务转化受损。
设计目标
- 统一动效语言：定义PICO品牌动效风格，形成可感知的流畅性和一致性
- Token体系：系统化动效参数，让80%的需求直接复用预设
- 可复用规范：沉淀设计文档和组件库，为多端业务提供方案储备
- VR约束指南：针对晕眩、景深、空间交互问题，提供专门的设计约束
📹 动效Demo展示区
此处将展示PICO OS的实际动效案例
（需要补充：界面录屏/动效GIF/设计稿）
从0-1搭建方法
没有可参考的前例，我通过三步建立起完整的动效设计体系：
Step 1：调研与问题拆解
- 收集用户反馈和内部测试问题（官网、OS系统、多端产品）
- 按用户体验、团队协作、业务影响三个层面拆解问题
- 识别核心矛盾：不是缺动效，而是缺统一的设计语言和复用机制
Step 2：定义原则与Token体系
- 定义5个核心设计原则，作为所有动效设计的判断标准
- 建立三层Token体系：曲线Token（Spring/Bézier）+ 时长Token（4档分层）+ 效果Token
- 设计"冲突消解机制"：通过分层预设，让不同场景需求在统一框架内各得其所
Step 3：文档沉淀与推广落地
- 编写《PICO OS Motion Principle》和《动效设计指南》
- 定义组件化边界，让设计师和开发直接调用Token
- 通过团队宣讲和实际案例验证，推动规范在多端业务落地
核心设计原则
定义5个核心原则，作为整个系统动效设计的基础框架和质量判断标准：
① 统一动效语言
全系统使用统一的曲线和时长Token体系，确保跨页面、跨功能的动效体验一致，形成PICO品牌辨识度和流畅感知。
② Token化设计
将动效属性做成可高效调取的Tokens，建立曲线Token、时长Token、效果Token三层体系，让设计师和开发轻松创建和管理动画。
③ 响应与反馈
用户操作后第一时间给出反馈，反馈状态统一化。交互过程中给予及时响应和积极反馈，明确操作状态。
④ 场景适配
不同设备采用不同时长：手机200-300ms、平板延长30%、可穿戴缩短30%、Web 150-200ms。VR/大屏避免大范围移动或旋转，防止眩晕。
⑤ 渐进式加载指引
2-9秒：循环加载动效，趣味化设计缓解焦虑；10秒以上：进度条形式，给明确时间预期；10秒后无效，给空页面状态。
Token体系：冲突消解机制
Token体系不仅仅是参数的集合，更是一套"冲突消解机制"——通过分层、分类的预设，让不同场景的动效需求在统一框架内各得其所，而不是各自为政。
曲线Token体系：AI可解析的动效规则
将动效曲线结构化为条件判断规则，让AI系统能够根据场景自动匹配合适的动效参数。
| Token名称 | 数学定义 | 触发条件（AI判断规则） | 典型场景 |
|---|---|---|---|
| Spring.gradual | damping=0, mass=1, stiffness=100 |
if (interactionType === "realtime" && emphasis === "low") |
Hover态轻微缩放 |
| Spring.steady | damping=0, mass=1, stiffness=170 |
if (interactionType === "realtime" && emphasis === "medium") |
按钮点击反馈 |
| Spring.rapid | damping=0, mass=1, stiffness=240 |
if (interactionType === "realtime" && emphasis === "high") |
快速切换tab |
| Spring.bouncy | damping=0.7, mass=1, stiffness=170 |
if (needsPlayfulness === true && userAge < 25) |
弹性反馈动效 |
| Bézier.standard | cubic-bezier(0.4, 0.0, 0.2, 1) |
if (transitionType === "pageNav" && speed === "normal") |
页面转场 |
| Bézier.decelerate | cubic-bezier(0.0, 0.0, 0.2, 1) |
if (direction === "enter" || animationType === "fadeIn") |
元素入场 |
| Bézier.accelerate | cubic-bezier(0.4, 0.0, 1, 1) |
if (direction === "exit" || animationType === "fadeOut") |
元素出场 |
AI系统应用示例
// AI系统根据场景自动选择Token
function selectMotionToken(context) {
if (context.interactionType === "realtime") {
return context.emphasis === "high" ? "Spring.rapid" : "Spring.steady";
}
if (context.transitionType === "pageNav") {
return context.direction === "enter" ? "Bézier.decelerate" : "Bézier.accelerate";
}
return "Bézier.standard"; // 默认
}时长Token体系：基于运动距离的自适应算法
将动效时长参数化，让AI系统根据运动距离、设备类型、内容重要性自动计算最优时长。
| Token分档 | 基准值 | 触发条件（AI计算规则） | 设备系数 |
|---|---|---|---|
| Short 1-4 | 60-240ms | if (distance < 50px && type === "stateChange") |
Mobile: 1.0x / Tablet: 1.3x / Wearable: 0.7x / VR: 0.7x |
| Medium 1-4 | 300-480ms | if (distance >= 50px && distance < 200px) |
Mobile: 1.0x / Tablet: 1.3x / Web: 0.75x |
| Long 1-4 | 540-720ms | if (distance >= 200px || type === "pageTransition") |
Mobile: 1.0x / Tablet: 1.3x / VR: 0.7x |
| Extra-long 1-4 | 780-960ms | if (userTrigger === false && importance === "low") |
仅用于系统级非用户主动触发场景 |
AI自适应时长计算公式
// AI系统根据场景参数自动计算最优时长
function calculateDuration(distance, deviceType, isUserTriggered) {
// 基础时长映射
let baseDuration;
if (distance < 50) baseDuration = 150; // Short
else if (distance < 200) baseDuration = 390; // Medium
else baseDuration = 630; // Long
// 设备系数调整
const deviceMultiplier = {
mobile: 1.0,
tablet: 1.3,
wearable: 0.7,
vr: 0.7,
web: 0.75
};
// 用户主动触发的动效时长更短
const triggerMultiplier = isUserTriggered ? 1.0 : 1.2;
return baseDuration * deviceMultiplier[deviceType] * triggerMultiplier;
}AI化设计系统的核心价值
将Token体系转化为AI可理解的条件判断规则，不仅是技术实现的需要，更是设计系统化思维的体现：
① 规则显性化
将设计师脑中的经验判断显性化为if-else规则，让AI系统能够在无人监督的情况下做出正确的动效选择。
② 可扩展性
新增场景时无需重新设计，只需在现有Token体系中补充新的条件分支，保证系统的长期可维护性。
③ 多端一致性
通过设备系数参数，让同一套规则自动适配Mobile/Tablet/VR/Web多端，而不是为每个端单独设计。
④ AI产品基础设施
为AI驱动的界面生成、自动化设计提供底层支撑，让AI不仅能生成界面，还能生成符合品牌规范的动效。
Token体系如何消解规则冲突
通过条件优先级和参数组合，让看似矛盾的设计需求在同一框架内各得其所：
| 潜在冲突场景 | AI判断逻辑 | Token选择结果 |
|---|---|---|
| 同一按钮在不同设备上的点击反馈 | if (device === "vr") return Spring.rapid * 0.7;else return Spring.steady * 1.0; |
VR设备时长缩短30%，防止晕眩 |
| 页面入场 vs 页面出场的节奏差异 | direction === "enter" ? Bézier.decelerate : Bézier.accelerate;exitDuration = enterDuration * 0.5; |
入场减速曲线+长时长，出场加速曲线+短时长 |
| 强调性动效 vs 普通动效 | if (emphasis === "high") return Spring.rapid;else return Spring.gradual; |
根据内容重要性动态调整曲线刚度 |
| 用户触发 vs 系统触发的时长差异 | baseDuration * (isUserTriggered ? 1.0 : 1.2); |
系统触发的动效时长增加20%，降低突兀感 |
| 实时交互 vs 页面转场的曲线选择 | interactionType === "realtime" ? Spring : Bézier; |
手势跟随用Spring，页面切换用Bézier |
设计系统化思维的体现
好的Token体系不是"一个参数对应一个值"，而是"一套规则对应一类场景"。通过条件判断、参数组合、优先级定义，让AI系统能够像设计师一样思考：这个场景应该用什么动效？为什么？
AI系统应用案例：智能动效决策引擎
以PICO OS的应用启动场景为例，展示AI系统如何根据Token体系自动生成符合规范的动效方案。
场景描述
用户在VR头显中点击应用图标，系统需要完成：图标反馈 → 应用卡片展开 → 内容淡入 → 系统UI收起。
Step 1: AI系统接收场景参数
{
"action": "appLaunch",
"device": "vr",
"userTriggered": true,
"steps": [
{
"element": "appIcon",
"animationType": "stateChange",
"distance": 8,
"emphasis": "medium"
},
{
"element": "appCard",
"animationType": "expand",
"distance": 450,
"emphasis": "high"
},
{
"element": "appContent",
"animationType": "fadeIn",
"distance": 0,
"delay": true
},
{
"element": "systemUI",
"animationType": "fadeOut",
"distance": 0,
"userTriggered": false
}
]
}Step 2: AI系统应用Token规则
// AI自动决策逻辑
function generateMotionPlan(scene) {
return scene.steps.map(step => {
// 规则1: 根据交互类型选择曲线族
const curveFamily = (step.animationType === "stateChange" ||
step.animationType === "expand")
? "Spring" : "Bézier";
// 规则2: 根据距离和设备计算时长
let baseDuration;
if (step.distance < 50) baseDuration = 150; // Short
else if (step.distance < 200) baseDuration = 390; // Medium
else baseDuration = 630; // Long
const duration = baseDuration * (scene.device === "vr" ? 0.7 : 1.0);
// 规则3: 根据强调程度选择具体Token
const curve = curveFamily === "Spring"
? (step.emphasis === "high" ? "Spring.rapid" : "Spring.steady")
: (step.animationType === "fadeIn" ? "Bézier.decelerate" : "Bézier.accelerate");
// 规则4: 系统触发的动效延长时长
const finalDuration = step.userTriggered === false
? duration * 1.2
: duration;
return {
element: step.element,
curve: curve,
duration: Math.round(finalDuration),
delay: step.delay ? finalDuration * 0.5 : 0
};
});
}Step 3: 输出符合规范的动效方案
| 元素 | 动效类型 | 曲线Token | 时长 | 延迟 | 决策依据 |
|---|---|---|---|---|---|
| 应用图标 | stateChange | Spring.steady | 105ms | 0ms | 用户触发 + VR设备系数0.7 + 中强调 |
| 应用卡片 | expand | Spring.rapid | 441ms | 0ms | 大距离运动 + VR设备 + 高强调 |
| 应用内容 | fadeIn | Bézier.decelerate | 273ms | 220ms | 入场动效 + 延迟0.5倍卡片时长 |
| 系统UI | fadeOut | Bézier.accelerate | 126ms | 0ms | 出场动效 + 系统触发 + VR设备 |
AI系统决策的关键优势
一致性保证：同样的场景参数永远产生同样的动效方案，避免人工决策的随意性。
多端自适应：修改device参数后，所有时长自动按系数调整，无需重新设计。
规则可追溯：每个Token选择都有明确的决策依据，便于调试和优化。
可扩展性：新增场景只需补充条件分支，不破坏现有规则。
对AI产品设计的启示
- 从"手工作坊"到"工业化生产"：Token体系让动效设计从依赖个人经验转变为可复制的规则系统
- 设计师的角色转变：从"为每个场景设计动效"转变为"定义规则让AI自动生成动效"
- AI时代的设计系统：好的Design System不仅是给人看的文档，更是AI可以直接调用的API
- 规则显性化能力：能否将脑中的设计判断显性化为if-else规则，是AI产品设计师的核心能力
成果与影响
① 可复用的动效规范体系
- 完成《PICO OS Motion Principle》和《动效设计指南》
- 定义13种曲线Token（8种Spring + 5种Bézier）、16档时长Token（4档×4层）
- 建立VR专属设计约束指南（防晕眩、景深适配、空间交互）
② 团队协作效率提升
- 设计师：直接调用Token，无需重新定义参数，输出质量更稳定
- 开发：通过组件库使用预设动效，减少沟通成本和重复开发
- 新人：通过文档快速理解PICO动效语言，降低上手门槛
③ 多端业务方案储备
体系不仅服务于PICO OS，也被官网、App等业务线参考复用，成为PICO设计语言的重要组成部分。
关键成果
从"三无状态"到统一动效语言，Token体系让80%需求直接复用预设，20%特殊场景也有明确原则指导。
📄 设计规范文档展示区
此处将展示Motion Principle文档截图
（需要补充：文档界面/Token定义页面/应用案例）
复盘与思考
① 从0-1搭建的关键：先定义"什么是对的"
没有前例可参考时，最大的挑战不是"怎么做"，而是"做什么"。我通过三个维度的问题诊断（用户体验层、团队协作层、业务影响层），识别出核心矛盾不是缺少动效，而是缺少统一的设计语言。这让我明确了设计目标：不是做更多动效，而是建立一套能复用、能约束、能指导的规范体系。
② Token体系的设计哲学：冲突消解机制
Token体系不仅仅是参数的集合，更是一套"冲突消解机制"。通过分层、分类的预设，让不同场景的动效需求在统一框架内各得其所：
- 实时交互 vs 页面转场：Spring Token用于实时交互，Bézier Token用于页面转场
- 强调 vs 普通场景：Spring分无阻尼（gradual→instant）和有阻尼（snapy/fair/bouncy）
- 不同运动范围：4档时长Token（Short/Medium/Long/Extra-long）按运动距离匹配
- 不同设备类型：手机/平板/可穿戴/Web按设备特性调整时长比例
这种"预设大于定制"的策略，让80%的需求可以直接使用Token，只有20%的特殊场景需要定制。这不仅提高了效率，更重要的是保证了体验的一致性。
③ VR约束的处理方法：把限制变成设计原则
VR设备有独特的设计约束：大范围移动会导致晕眩、景深变化需要时间适应、空间交互与2D屏幕完全不同。我没有把这些约束当作"限制"，而是转化为明确的设计原则：
- 防晕眩：避免大范围移动或旋转动画，优先使用淡入淡出而非位移
- 时长优化：VR设备动效时长相比手机缩短30%，减少等待时的不适感
- 景深适配：界面元素在不同景深层级的动效需要考虑视觉焦点转移时间
这些原则被写入《动效设计指南》，成为所有VR动效设计的判断标准。
④ 知识沉淀的长期价值：规范是活的资产
设计规范不是一次性的产出，而是持续的知识资产。《PICO OS Motion Principle》不仅服务于OS团队，也被官网、App等其他业务线参考和复用。更重要的是，它建立了一套"可传递的设计判断标准"——新同事不需要靠经验积累，可以直接通过文档理解"PICO的动效应该是什么样的"。
⑤ 如果重新做，会怎么改进？
- 更早引入开发参与：Token体系的落地需要开发侧的动画框架支持，如果在定义Token时就让开发参与，可以减少后期对齐成本
- 建立量化评估指标：当时主要依靠团队反馈验证效果，如果能建立"动效一致性评分"等量化指标，可以更客观地衡量规范的落地效果
- 补充更多实际案例：文档中可以补充更多"这种场景用哪个Token"的实际案例，降低新同事的理解成本