スケルトンスクリーンと体感速度
要点
- スケルトンスクリーンは、読み込み中に最終的なレイアウトの輪郭を灰色の枠で先に見せる手法である。
- くるくる回るスピナーより、コンテンツが今まさに組み上がりつつあるという印象を与え、体感の待ちを短くしうる。
- ただし、実際の読み込みが遅ければ、骨組みだけが長く居座り、かえって焦らしになる。
- 体感速度の工夫は実速度の代わりにはならず、両者は補い合うべき関係にある。
アプリを開いた瞬間、まだ中身は来ていないのに、画面にはぼんやりした灰色の四角がいくつも並んでいる。やがてそこへ画像や文字が流し込まれ、本来の画面が立ち上がる。この灰色の骨組みは「スケルトンスクリーン」と呼ばれる。スピナーが回るだけの白い画面に代わって、ここ十年ほどで広く使われるようになった表示だ。
スピナーから骨組みへ
「スケルトンスクリーン」という呼び方を広めたのは、デザイナーのルーク・ロブレウスキーが二〇一三年に書いた文章だとされる。彼の主張はこうだ。読み込み中にスピナーを見せると、利用者の注意はその「待っている」という事実そのものに向く。代わりに、これから現れるコンテンツの構造――見出しがここ、画像がここ、本文がここ――を骨組みとして先に示せば、注意は「もうすぐ現れる中身」へ向かう。待っているという意識が薄れる。
これは、待ち時間を埋める古典的な発想の画面版だ。何もない待ちは長く感じ、何かに注意が向いている待ちは短く感じる。スケルトンスクリーンは、その「何か」を、来るべきコンテンツの予告として用意する。スピナーが「待て」と命じるのに対し、骨組みは「もう始まっている」と告げる。
骨組みが裏目に出るとき
一方で、スケルトンスクリーンは万能ではない。前提は、読み込みが十分に速いことだ。輪郭を見せてから一秒前後で中身が埋まれば、組み上がっていく印象は心地よい。だが、回線が遅く、骨組みだけが数秒、十数秒と居座れば話は逆になる。中身を約束しておきながら一向に届けない画面は、空白のスピナー以上に焦らしになる。期待させた分だけ、裏切りも大きい。
もっとも、ここで責められるべきはスケルトンスクリーンという手法ではなく、それを実速度の遅さの隠れ蓑に使う発想のほうだ。体感を整える工夫は、根本の遅さを覆い隠すためではなく、避けられない待ちを少しでも楽にするためにある。読み込みが構造的に遅いなら、まず取り組むべきは速度そのものだ。
体感と実速度の分業
裏を返せば、スケルトンスクリーンが教えるのは、待ちには二つの戦線があるという事実だ。一つは実際の処理を速くする戦線、もう一つは避けられない待ちの体感を整える戦線。前者はサーバーや回線や処理の最適化が担い、後者は表示の工夫が担う。どちらか一方では足りない。速いだけで素っ気ない画面も、遅いのに見栄えだけ整えた画面も、結局は利用者を取りこぼす。
灰色の骨組みが心地よく感じられるのは、その裏で実際の読み込みもそれなりに速いときに限られる。次にアプリの起動時に骨組みを見かけたら、それがすっと中身に変わるか、それとも長く居座るかを観察してみてほしい。そこに、体感と実速度の分業がうまくいっているかどうかが表れている。応答時間そのものの目安は応答時間の三つの閾値に、進捗の見せ方の選択は進捗バーの歴史に詳しい。
参考・出典
- Luke Wroblewski, “Mobile Design Details: Avoid The Spinner,” 2013.
- Jakob Nielsen, “Response Times: The 3 Important Limits,” Nielsen Norman Group.
