E6.07.3stale skeleton设计研究
长时间骨架屏比转圈更令人困惑
别名: 骨架过久 · endless skeleton · 假加载完成
概念解释
骨架的说服力来自「马上就到」。拖过那一小段预期，灰块还在微微闪，人开始怀疑这是不是已经加载完的残缺页：有结构，没有字，也许就是这个产品的样子。长时间骨架比同一时长的转圈更让人困惑，因为转圈始终在说「还没好」，骨架却看起来像一种界面。这一条管的是骨架作为加载语言的时效，不是结构准不准，也不是要不要用确定进度。
机制
骨架借用了内容的外形，所以它有一条内建的截止：外形该被真内容替换。超过截止，同一外形开始被重新分类——从「占位」变成「残缺的真界面」。闪动的高光本意是说「活着」，但在长时间里也会被读成装饰动画。转圈没有内容外形，分类不会滑向「这就是页面」；它的问题是不告诉你来的是什么，不是让你以为已经来了。人还会去点骨架里像按钮的块，因为那些块占据了真按钮的坐标。点了没反应，困惑升级成「坏了」或「被禁用」。短等待里骨架赢在定向；长等待里它输在身份模糊。
怎么研究
把等待拉到数秒以上，比较骨架、转圈、骨架超时后改转圈三种策略。
自变量：等待时长、骨架是否持续闪动、超时后是否换语言。 因变量：是否尝试点击色块、是否报告「页面已经出来了」、放弃时间、事后如何描述当时发生的事。
要分开「觉得慢」和「以为结束了」。后者才是骨架特有的失败。询问时避免提示「这是加载」，否则被试不会做出产品里那种误分类。
边界
已知很长且能量化的等待（大文件、导出）不该靠骨架撑着，那是进度条的工作；骨架超时后应让位。弱网里骨架和转圈都可以长，但骨架必须在某一时刻换成明确的「仍在加载 / 失败可重试」，不能无限闪。对已经部分到达的页面（先出壳再填字），长时间留着未填的骨架块，会让已出的真内容也被怀疑是假的。游戏化或品牌化的骨架若本身很好看，更会像成品，超时风险更高。
怎么落地
- 给骨架设时限；超过就换成转圈、进度或失败态，不要让灰块无限闪。
- 骨架期间不要让色块可点；真按钮要等对应内容到来再出现，避免占位被当成禁用控件。
- 部分到达时，已确定为空的区域尽快改成空状态，不要留着骨架装还在来。
- 验证：把加载卡住十秒。问「现在页面好了没有、你刚才点了什么」。回答「好像好了但没字」或点了灰块，骨架已经活过了它的语言寿命。