ローディング体験を分ける三つの要素

二つのアプリを開く。どちらも実際の読み込みには2.5秒かかる。けれど一方は遅く、もう一方は許せる速さに感じられる。中身の処理時間は同じなのに、なぜ印象が割れるのか。ローディング体験を分けるのは、時間の長さそのものではなく、その時間が利用者にどう知覚されるかである。ここでは、体感を左右するいくつかの要素を比較してみたい。

初期表示までの時間

まず効くのは、画面に最初の何かが現れるまでの時間だ。真っ白なまま2秒待たされるのと、0.5秒で骨格が現れ、残りで中身が埋まっていくのとでは、後者の方が圧倒的に速く感じられる。Googleが提唱した性能モデル「RAIL」も、利用者の操作に対する初期の応答性を重視している。詳しくはRAILモデルで応答を設計するで扱うが、要点は、全体が完成する時間より、最初の反応が返る時間の方が体感に効くという点にある。

この観点から見ると、スケルトンスクリーンが支持されてきた理由が分かる。中身より先に構造を見せることで、初期表示までの体感時間を縮める。利用者は「もう始まっている」と感じ、残りの読み込みを許容しやすくなる。

進行が見えるかどうか

次の分かれ目は、待っているあいだ何が起きているかが見えるかである。進捗バーのように進み具合が示されると、利用者は終わりを予測でき、不確実性が下がる。逆に、何の手がかりもないまま固まった画面は、実際より長く感じられる。マイスターの待ち行列研究が示した「不確実な待ちは長い」という原則は、画面の前でも変わらない。

ただし、進行の可視化が常に有効とは限らない。読み込みが1秒未満で終わる場面で律儀に進捗を出すと、かえって待ちの存在を意識させる。短い待ちには、むしろ何も出さない方が滑らかなこともある。見せるか見せないかの判断は、待ち時間の長さに依存する。

終わりの予測可能性

三つ目は、いつ終わるかを利用者が見通せるかだ。同じ待ちでも、終点が見えていれば耐えやすい。エレベーターの階数表示が、到着までの体感を和らげるのと同じ理屈である。アプリの読み込みでも、残り件数や完了割合が示されると、利用者は心の準備ができる。もっとも、前述のとおり予測が外れれば逆効果になる。正確に見積もれない処理で安易に残り時間を出すのは、約束を破るリスクを抱える。

二つの速さを切り分ける

こうして並べると、ローディング体験の改善には二つの異なる道があると分かる。一つは実際の処理を速くする道。もう一つは、避けられない待ちを速く見せる道だ。前者は技術的な最適化の問題であり、後者は知覚の設計の問題である。両者は別物だが、どちらか一方だけでは足りない。

体感の設計は、利用者をごまかす技術ではない。むしろ、時間という抽象的なものに形を与え、利用者が状況を理解できるようにする営みだ。速く見せることと速くすること——この二つを切り分けて考えられるかどうかが、待ち時間の設計の出発点になる。実際の応答速度がもたらす経済的な影響については、ドハティのしきい値が一つの古典的な視点を与えてくれる。