ローディング状態こそがプロダクトだ

1年間にプロダクトが表示するローディング状態をすべて足し合わせてみてください。全ユーザー、全セッション、全リフレッシュ。その合計をユーザー時間で数えたら、それはあなたが出荷する画面の中で最も長く見られている画面です。なのに多くのチームは、誰も見ていないかのように扱います。

ダッシュボードはデザインレビューを受けます。空の状態も、空の状態こそがプロダクトだを読んだ人ならデザインレビューを受けます。ローディング状態はどうか。2012年のスタイルシートから拾ってきた16ピクセルのスピナーと、祈りだけです。ユーザーが必ず目にする画面なのに、誰もデザインしない画面です。

ローディング状態はブランドの第一印象である

すべてのローディング状態は信頼の契約です。 プロダクトはユーザーにこう伝えています。「動いています、クラッシュしていません、この待ち時間は意図したものです」。次に画面が何を語るかで、ブランドがプレッシャー下でどう振る舞うかが決まります。

Linearのローディング状態はLinearらしい。課題リストの形をしたスケルトン行、サーバー確認の前に確定するインライン作成、意図的なリズムを持つブランド遷移。Stripeのそれはまさwithout Stripeらしい。支払いボタンのシマー、ダッシュボードのカード型スケルトン、最終状態へと解決していくレシート。どちらも待ち時間をプロダクトとして扱っています。

悪い例は、白い背景で回り続けるレガシーなgifスピナーです。コンテンツの形もなく、進捗のシグナルもなく、ブランドもない。ユーザーは「忙しくてあなたがいることを忘れていました」と言われているのと同じです。それもまたブランドの印象です。ただ、チームが出荷したかった印象ではないだけで。

ローディング状態の5つのアーキタイプ

多くのチームは「ローディング状態」をひとつのデザイン課題として扱います。実際には5つあります。それぞれ異なる種類の待ち時間に合い、異なる理由で失敗します。

1. スケルトンスクリーン

最終コンテンツの形を映したプレースホルダーのレイアウトです。行が来る場所には行、カードが来る場所にはカード。コンテンツが届く前に目が構造を捉え、待ち時間は「始まる」ではなく「解決していく」ものとして読まれます。

Linearの課題リストは、最終リストとピクセル単位で一致する行型スケルトンを出します。Stripe Dashboardは指標セクションにカード型スケルトンを出し、それが実データのカードへと解決します。Notionはブロック型のプレースホルダーを出し、ドキュメントの読み込み完了で本物のブロックに変わります。約束は同じです。ローディングの形が最終的な形を予告する。

使うべき場面は構造がわかっているとき。避けるべき場面はレイアウトが動的すぎて、スケルトンが次に来るものについて嘘をついてしまうときです。

2. オプティミスティックUI

サーバーの確認を待たず、ユーザーの操作を即座に描画します。調整はバックグラウンドで行う。サーバーが同意すればUIはちらつかない。同意しなければ、目に見えるundoの道筋つきでロールバックします。

Linearのインライン課題作成は理想形です。Cを押し、タイトルを打ち、Enterを押すと、往復通信が終わる前に課題がリストに入っています。Figmaのカーソルと選択の移動は、マルチプレイヤーセッション全体を通してオプティミスティックです。ユーザーはネットワークを一切感じません。

使うべき場面は失敗がまれで元に戻せるとき。避けるべき場面は操作が破壊的なとき、または先に進む前にサーバーの答えが必要なときです。

3. ストリーミングによる部分表示

残りがまだ通信中のうちに、最初の塊を描画します。ユーザーはすでに結果を消費しているので、待ち時間は出力の中に溶けて消えます。

Claudeのトークンストリームは、出荷されている中で最もきれいな例で、人間の読む速度に合わせてなめらかに整えられたリズムを持っています。Cursorはdiffをトークン単位でストリームするので、モデルが書き終える前にユーザーはコードを読んでいます。Vercelはデプロイログをライブでストリームするので、ユーザーはビルドを待つのではなく眺めています。より広いレイテンシ戦略はAIのレイテンシのためのデザインで扱っています。

使うべき場面は結果に自然なリズムがあるとき。避けるべき場面は塊が単体では役に立たないときです。

4. コンテンツとしてのプログレス

待ち時間そのものが価値です。デプロイログ、ビルドパイプライン、エージェントの推論トレース。ユーザーは結果を待っているのではありません。過程を読んでいるのです。

Vercelのデプロイビューが代表例です。デプロイログがローディング状態であり、同時にプラットフォームで最も多く表示される画面でもあります。GitHub Actionsもステップごとの実行出力で同じことをしています。Cursorのエージェントパネルは作業中の推論トレースを見せるので、数分かかるタスクも停滞ではなく目的のあるものに感じられます。v0とLovableはプロンプトからアプリを作る画面でこれを採用しており、ビルドのストリーミングがローディング状態、プレビューがご褒美です。

使うべき場面は待ち時間そのものが価値のとき。避けるべき場面は最終状態にしか興味がないユーザーにとって、各ステップが役に立たないときです。

5. ブランドスピナー

マイクロパルス、グラデーション、シマー。プロダクトが個性のトークンを獲得する瞬間です。Stripeの支払いボタンのシマー、Vercelのグラデーションのプログレスバー、Linearの遷移待ちのマイクロパルス。どれも単独で仕事をしているわけではありません。最初の4つのパターンのどれかの上に乗り、すでに構造のある待ち時間にブランドの仕上げを加えています。

使うべき場面は待ち時間が短く、その画面が重要度の高いとき。避けるべき場面は背後にスケルトンもストリームもないときです。最初の4つのパターンのどれも下に敷かないブランドスピナーは、2026年のヘックスコードをまとった1996年のスピナーです。

スケルトンはほぼ毎回スピナーに勝つ

スケルトンはこれから来るものの形を予告します。スピナーはどこかで何かが起きていることを示すだけです。同じ待ち時間でも、体験はまったく別物になります。

Stripeのダッシュボードのスケルトンは、時計の上ではスピナー版とほとんど変わらない速さですが、体感速度の差ははるかに大きい。ユーザーはカード型のレイアウトを見て、データが届く前から状況を把握し始めます。指標が解決する頃には、目はすでに定位置にいる。スピナーだと、ユーザーは画面の中央を見つめたまま、他のどこかを見る許可を待つことになります。レイアウトが予測できるならスケルトンを出す。できないならステータスラインを出す。

オプティミスティックUIは裏技だ

待ち時間が始まる前に操作が確定するので、待ち時間は見えなくなります。

Linearはあらゆる場所をオプティミスティックにしました。課題作成、ステータス変更、担当者の入れ替え、ラベル追加、サイクル移動。どれも意図の時点でローカルストアに書き込み、サーバーの応答後に調整します。Figmaのマルチプレイヤーは、カーソル移動、選択、ほとんどの編集でオプティミスティックです。Notionもドキュメント編集でオプティミスティックです。どのプロダクトもローカルのソフトウェアのように感じられるのは、ネットワークがオプティミスティックな層の下に隠されているからです。

これを成立させる条件は2つ。失敗がまれで元に戻せること。さもないとUIがちらつき、ユーザーは信頼しなくなります。そしてエラーが見えること。サーバーエラーを黙って飲み込むオプティミスティックな操作は、オプティミズムがないより悪い。成功していないのに成功したとユーザーに教えてしまうからです。オプティミスティックな書き込みにはすべて、undo、トースト、あるいはユーザーに見えるロールバックが必要です。

優れたローディング状態のための5つのルール

5つのうち4つを満たせば、待ち時間はデザインされたものとして読まれます。3つだと、ローディング状態は後付けのように感じられ始めます。

1. ローディングの形が最終的な形を予告する。 行にはスケルトン行、カードにはスケルトンカード。コンテンツが解決してもレイアウトが飛ばない。
2. 可能な限り、待ち時間にコンテンツを与える。 トークンをストリームし、ログを出し、部分を描画する。読んでいるユーザーは待っていません。
3. 800msを超える待ち時間にはフィードバックを出す。 800ms未満ならきれいな遷移で十分。それを超えたら、まず構造、次にコンテンツというプログレッシブディスクロージャーであっても、システムが生きているというシグナルが必要です。
4. オプティミスティックな操作には、見えるundoの道筋が必要。 トースト、ロールバック、明確なエラー状態。回復手段のないオプティミズムはガスライティングです。
5. ブランド上の理由なきスピナーは出さない。 ブランドスピナーは最初の4つのパターンの上に乗るもので、置き換えるものではありません。画面上にスピナーしかないなら、デザインは終わっていません。

より深い文脈は、より広いウェブデザインの原則の解説と、core web vitalsがレイアウトシフトを体感パフォーマンスの失敗として扱う方法の中にあります。

ローディング状態を殺すアンチパターン

出荷されるべきでないのに、よく出荷される失敗パターンが6つあります。どれも直せますし、どれも今この瞬間どこかの本番環境で動いています。

進捗のない無期限スピナー。 15秒間回り続けているのに何のシグナルもないスピナー。ユーザーはリクエストが生きているのか、死んでいるのか、詰まっているのかわかりません。ステータスライン、プログレスバー、ストリーミング画面に置き換えましょう。

閉じられないページ全体ブロックのモーダル。 画面全体を乗っ取り、スクロールもコピーもプロダクトの他の部分を読むことも許さないローディングモーダル。待ち時間が人質事件になります。

スケルトンが解決するとレイアウトが飛ぶ。 実際のレイアウトと一致しないスケルトン。行がずれ、カードがリフローし、ヘッダーが動く。スケルトンは別のデザインではありません。コンテンツのない同じデザインです。

永遠に続く「Loading...」のテキストループ。 回る3つのドット、進捗なし、ステータスなし。ユーザーは2セッションもすれば無視することを学び、その画面が次に出す本物のステータスの伝達経路まで死んでしまいます。

エラーを黙って飲み込むオプティミスティックUI。 UI上では操作が確定し、サーバーは失敗し、プロダクトはユーザーに何も伝えない。解決策は、見えるトースト、undoボタン、またはロールバックです。

100msの待ち時間にブランドスピナー。 ユーザーが気づく前に終わる待ち時間へのシマー。純粋なオーバーヘッドです。速い画面にはフェードを。遅い画面には構造を。

意図的に摩擦をデザインするでは、待ち時間をあえて見せるべきまれなケースを扱っています。ローディング状態はそれには当たりません。見えなくするか、デザインするか、コンテンツにするべき待ち時間です。

ローディング状態の監査

6つの質問です。次のリリースの前に、すべてのローディング画面をこれに通してください。

1. ローディングの形は最終的な形を予告しているか? 予測可能なレイアウトにはスケルトン、予測不能なものにはステータスライン。解決時にレイアウトが飛ばないこと。
2. 待ち時間は情報を運んでいるか? スケルトン、ストリーム、プログレスログ、ステータスライン。800msを超えて何も載っていない待ち時間はすべて漏れです。
3. 待ち時間ごとに主メッセージは1つか? 「ダッシュボードを読み込み中」は、重なり合う4つのシグナルに勝ちます。シグナルは1つ、仕事をするのは視覚的階層。
4. ローディング状態はブランドボイスと一致しているか? ローディング中の文言を、データが入った画面の隣で読み比べてください。トーンが変わるなら、ローディング状態は別のブランドをまとっています。
5. オプティミスティックな操作は、失敗時に元に戻せて、見えるか? すべてのオプティミスティックな書き込みにundo、トースト、ロールバックがある。サイレントフェイラーはなし。
6. そのローディング画面は、見知らぬ人にプロダクトを売れるか? 彼らが目にした画面がローディング状態だけだったとして、登録したプロダクトらしさを感じられるか。答えがNoなら、アプリで最も長く見られる画面は、最もデザインが悪い画面でもあります。

この6つをすべて通過するローディング状態を持つプロダクトは、遅いネットワークでも速く感じられます。

パターンを選び、それから待ち時間を出荷する

ローディング状態は仕上げのレイヤーではありません。ブランドのレイヤーであり、信頼のレイヤーであり、体感パフォーマンスのレイヤーであり、それらがユーザーの最も多く見る画面に凝縮されているのです。すべての待ち時間はデザインの選択です。チームが意図してそうしたかどうかに関係なく。

構造がわかっているところにはスケルトン。失敗が元に戻せるところにはオプティミスティック。結果にリズムがあるところにはストリーミング。待ち時間が価値のところにはコンテンツとしてのプログレス。ブランドスピナーは、最初の4つがすでに仕事をしているときだけ。ランディングページデザインの原則の解説は、この規律のマーケティングページ版です。

ローディング状態を、遅いことへの謝罪のように扱うのはやめましょう。積み重ねれば、それはプロダクトそのものです。待ち時間を、相手の時間に値するものにしてください。

FAQ

スケルトンスクリーンとローディングスピナーの違いは何ですか?

スケルトンはプレースホルダーのレイアウトで最終コンテンツの形を予告するので、ユーザーはデータが届く前から状況を把握し始めます。スピナーは何かが起きていることを示すだけで、形も構造もプレビューもありません。スケルトンは体感の待ち時間を縮めます。スピナーは縮めません。

オプティミスティックUIとストリーミングレスポンスは、どう使い分けますか?

ユーザーの操作そのものが作業であるとき、たとえば課題の追加、ステータスの切り替え、カードの移動にはオプティミスティックUI。サーバーが作業をしていて結果に自然なリズムがあるとき、たとえばテキスト生成、ログ出力、デプロイパイプラインにはストリーミング。この2つは組み合わせられます。

素のスピナーを出していい場面はありますか?

1秒未満のフォールバックとして、レイアウトが本当に予測不能なときに、しかもブランド上の理由があるときだけです。スケルトン、ステータスライン、ストリーミング画面は、体感パフォーマンスのあらゆる指標でスピナーに勝ちます。スピナーは最後の手段にしましょう。

待ち時間をデザインし、プロダクトを出荷する

待ち時間は、ユーザーが最も多く見る画面です。最も頻繁に受けるブランドの印象であり、最も頻繁に読む信頼のシグナルであり、ページを読み込むたびに行う体感パフォーマンスのテストです。ダッシュボードに6週間かけて、ローディング状態には午後だけを使うチームは、ユーザーが実際に暮らしている場所に対して、間違った配分で仕事を出荷しています。

ローディング状態を、ローンチ前の最後のスプリントではなくプロダクトの一部としてデザインするチームがほしいなら、Brainyに依頼してください。私たちは、待ち時間がブランドの一部であり、体感パフォーマンスが実測パフォーマンスを上回るプロダクトを出荷します。