从空状态到有内容的过渡
用户点下「新建」之后那 400 毫秒，界面该发生什么
场景：列表页首次为空，用户点了「新建」并提交。请设计从空状态到有内容的过渡：1）状态序列有哪些，空、提交中、骨架、局部出现、完整；2）每段的时长与缓动，总时长控制在 400ms 内；3）怎么避免布局跳动，包括预留高度、骨架尺寸与真实内容一致；4）焦点和滚动位置怎么处理；5）无障碍，prefers-reduced-motion 下改成什么、要不要 aria-live；6）这条过渡要让用户确认哪三件事。最后给一张时序表，标出每一步用户看到什么。
使用建议
接口慢的时候别用骨架硬撑；超过 1 秒，就该换成进度提示或先返回列表。
适合什么场景
- 首次使用时列表是空的，用户建了第一条——这一下如果没有反馈，他会以为没保存成功，再点一次。
- 列表页还有筛选、批量操作这类依赖内容存在的控件——过渡要顺带解决「控件什么时候出现」。
不适合的场景
- 内容几乎总是整页从服务端返回，比如后台报表——没有「空到有」的过程，做过渡反而拖慢。
- 每次创建都整页跳转到详情页——过渡发生在页面之间，属于转场设计，不是同页状态过渡。
示例
输入
任务管理 App：空状态是插画加「新建第一个任务」，用户填标题提交后列表要出现第一条；目前是白屏闪一下再直接出现
你会得到
设计五段：插画淡出 120ms，骨架行沿用真实行高 56px 和卡片圆角，120ms 后第一条以 8px 上移淡入，其余行错开 40ms 依次出现，焦点落到新条目标题、滚动保持顶部。白屏闪烁是因为等待期间没有占位，加骨架即可消除。reduced-motion 下取消位移和错开，只保留 100ms 的透明度切换。
常见误用
- 用骨架屏掩盖慢接口——过渡只有 400ms，接口要 2 秒的话骨架会僵在那儿，用户更焦虑。
- 让新内容从屏幕外飞入——位移超过 24px，用户就丢失了「它加在哪」的空间关系。
可以这样改
- 换成「删除最后一条后的反向过渡」——从有到空更容易做错，插画突然弹出会像报错。
- 补「失败分支」：提交失败时保留已填内容、在原位显示错误——过渡设计必须包含不成功的那条路。