简单
使用统一的 Margin 2a 与 Gutter a 组织宫格，减少走焦路径的不确定性；首屏和导航选项遵循 7+2 信息密度，避免在远距离观看中制造认知负担。
系统设计 / 跨团队推动
GiantTV OS 系统设计
面向智慧屏 To B 场景，把交互、运营与动效规则沉淀为可复用的系统能力
把单点动效问题变成系统能力
项目背景与我真正需要解决的设计问题
GiantTV OS 是字节跳动面向智慧屏厂商的 To B 预装系统。设计不仅要服务最终用户，也要支持厂商接入和多方应用调用。
TV OS 1.0 缺少统一的交互原则和生产边界。运营素材、不同页面与应用各自定义视觉和反馈，造成体验割裂，也让设计、内容和开发持续重复沟通。
我的任务不是补一组样式或动效，而是从 0-1 建立交互基线，分别约束内容输入与状态变化，再把规则转成可复用的参数和组件。
- 两条生产链路 运营素材和研发组件由不同角色生产，需要在同一体验目标下使用各自可执行的规则。
- 大屏交互约束 遥控器、空鼠、触控和手势并存，需要统一焦点移动、响应时机与状态反馈。
- 跨团队落地 规范必须同时被 UI、开发和产品理解，才能从文档进入真实生产链路。
先建立对“好体验”的共同判断
竞品分析不是收集样式，而是为团队建立决策依据
我先拆解主流 TV 产品的焦点、层级和反馈机制，用可观察的行业实践说明动效为什么必要。
产品
观察
对 GiantTV OS 的启发
Apple TV
视差与深度感知，焦点移动连贯
用层级变化帮助用户确认当前位置
华为鸿蒙 OS
多设备协同中的状态连续性
跨应用切换需要一致的反馈语法
索尼 Android TV
内容层级清晰，展开与收起自然
大屏浏览需要稳定的空间关系
YouTube TV
预览启动时机与加载反馈明确
内容状态需要给出可预期的节奏
焦点可感知
用户随时知道当前选择和下一步去向。
转场有层级
动效表达页面、控件和系统状态的关系。
反馈可预期
相同操作在不同应用中保持一致节奏。
四条原则建立大屏交互基线
来自实际 Smart TV 交互规范与设计证据
我把抽象的“大屏体验”拆成四个可执行原则，并为每条原则补充布局、获焦和适配规则，让团队能够用同一套标准做设计判断。
简单
控制布局规律与首屏信息密度
清晰
确保走焦过程始终可感知
氛围
用背景与容器烘托内容
灵活
兼容品牌、屏幕与芯片差异
清晰
大屏主要依靠遥控器走焦，用户必须始终知道焦点在哪里。我从背景、描边、投影、内容、对比度和位置六个维度建立获焦反馈。
氛围
电视内容的观看距离更远，界面不能只靠局部卡片传达情绪。背景和容器需要承接内容色彩，形成统一的观看氛围，同时保持焦点清晰。
灵活
To B 系统不能只为一台设备服务。规范要提供品牌定制触点，并根据屏幕素质、明暗环境和芯片性能调整显示形态与动效复杂度。
交互设计原则
把简单、清晰、氛围、灵活转化为可检查的界面规则。
运营与动效指南
分别约束内容上屏质量，以及页面、控件与系统状态的变化方式。
组件、适配与宣讲
把规则连接到品牌、屏幕、芯片和研发实现，降低团队采用成本。
把原则拆成两份生产指南
运营指南约束输入质量，动效指南统一状态变化
四条原则解决“如何判断”，两份指南继续回答“具体怎么做”。我按内容生产和研发实现两条链路拆分规则，避免一份大而全的文档让不同角色各自寻找答案。
- 交互原则 建立简单、清晰、氛围、灵活的共同判断。
- 运营设计 约束海报、壁纸、文字和品牌素材如何上屏。
- 动效设计 统一时长、曲线、过渡和页面层级关系。
- 组件落地 把规则转成研发可调用、设计可复用的能力。
运营指南：先控制上屏输入
智慧屏首页承载大量外部内容。只统一系统组件不够，运营素材本身也会改变焦点识别、文字可读性和页面氛围。我把模糊的“素材好不好”拆成设计阶段就能检查的规则。
画面区域
明确 Logo、主体和勿干扰区域，避免关键信息与系统控件竞争，也为景深和层次留出空间。
Logo 与字体
保持片单 Logo 的原始比例和识别性，区分基础字体、特殊字体与不适合上屏的字形样式。
色彩与壁纸
限制大面积高饱和配色、复杂渐变和水波纹，背景不过度抢占注意力，也不降低 UI 识别。
输出校验
把文件格式、尺寸和画面检查放到交付出口，减少素材进入系统后才发现问题的返工。
动效指南：再统一变化语言
动效规范不能只提供效果示例。我先定义原则，再把时长、曲线、过渡方式和页面层级对应起来，并给出 Android、iOS、CSS 与 Flutter 的参数映射，让设计判断可以直接进入实现。
清晰
动效准确反馈信息与页面层级。
一致
同一场景使用同一类转场反馈。
自然
使用非线性曲线保持运动可预测。
沉浸
控制速度与旋转，降低眩晕和分心。
Switch 等简单图形状态变化。
播控 Hover、轻量缩放或位移。
屏幕内中等范围的对话框与操作栏。
需要用户感知上下文切换的长转场。
标准曲线
适用于元素始终位于视线内的 Tab 切换、开关和图片缩放，强调快速响应与自然收束。
cubic-bezier(0.34, 0.69, 0.10, 1.00)
层级决定过渡方式
同层级优先同轴位移，上下级通过空间关系表达进入与返回，跨应用使用错峰交叉淡入淡出。需要展示详情时，再用共享容器维持对象连续性。
让不同角色愿意采用同一套规范
推动重点不在反复强调规范，而在降低每个角色的实际成本
我用问题走查建立紧迫性，用竞品建立目标共识，再把两份指南接入素材评审和组件试点，证明规范能够直接进入生产流程。
- 问题走查 暴露 1.0 的体验割裂与重复沟通
- 竞品共识 把抽象标准转化为可观察的目标
- 组件试点 验证动效参数和交互规则可以进入研发流程
- 宣讲推广 按角色说明价值和具体使用方式
UI 设计师
关心一致性与重复劳动
通过运营检查项、Token 和组件减少逐页定义与返工
开发
关心实现成本与沟通效率
用统一命名和可调用组件减少反复确认
产品与厂商
关心竞争力与定制空间
在统一框架内支持不同场景的灵活组合
规范进入真实业务，而不是停在文档里
结果只陈述当前材料能够支撑的交付与落地事实
40+
动效需求独立推动
覆盖系统级、页面级与控件级场景，从概念设计推进到组件化落地。
- 规范完成并全面宣讲 运营设计规范与 TV OS 2.0 动效指南形成完整交付，并面向 UI 与产研团队宣讲。
- 组件被多方应用调用 规范从设计文档转化为业务可以直接使用的生产能力。
- 统一了跨团队协作语言 设计与开发围绕同一套参数、边界和组件进行沟通。
当前项目材料未提供业务端量化数据，因此不补写转化率、效率百分比等无法核验的结果。
系统设计最终解决的是协作问题
这次项目留下的三个可迁移判断
采用成本决定规范能否落地
只讲体验价值不够。组件化让设计师少做重复定义，让开发少做重复实现，规范才有稳定的采用动力。
组件边界必须能解释冲突
按交互层级、时长与触发方式划分边界，让页面级、控件级和系统级动效可以组合，而不会互相覆盖。
To B 设计要同时服务两类用户
直接客户是厂商，最终用户是消费者。系统需要在定制灵活性与体验一致性之间建立可操作的平衡，而不是偏向其中一端。
好的设计系统不是规则越多，而是让不同角色在同一个框架内更快做出一致判断。