空の状態から内容が現れるまで
「新規作成」を押した後の 400ms に何を起こすか
想定：一覧ページが初回で空の状態です。ユーザーが「新規作成」を押して送信し、最初の 1 件が作られます。空の状態から内容が現れるまでの遷移を設計してください：1）状態の並び（空、送信中、スケルトン、部分表示、完了）；2）各段階の時間とイージング。全体は 400ms 以内に収める；3）レイアウトのずれを防ぐ方法（高さの確保、スケルトンと実コンテンツの寸法を一致させる）；4）フォーカスとスクロール位置の扱い；5）アクセシビリティ（prefers-reduced-motion のときに何に変えるか、aria-live が必要か）；6）この遷移でユーザーに確認させる 3 つのこと。最後に、各段階でユーザーに何が見えるかを時系列の表にしてください。
使い方
遅い API をスケルトンで支えないでください。1 秒を超えるなら、進捗表示に切り替えるか、先に一覧へ戻します。
向いている場面
- 初回利用で一覧が空の状態から、ユーザーが 1 件目を作ります。この瞬間に反応がないと、保存できなかったと思ってもう一度押します。
- 一覧ページには絞り込みや一括操作など、内容の存在を前提とする部品があります。遷移は「その部品がいつ現れるか」も同時に決める必要があります。
向いていない場面
- 内容が常にサーバーからページ全体で返ってくる場合です。管理画面のレポートなどがそうで、「空から有」の過程がないため、遷移を作ると遅くなるだけです。
- 作成のたびに詳細ページへ画面遷移する場合です。遷移は画面をまたいで起きるので、画面間のトランジション設計になり、同一画面の状態遷移ではありません。
例
入力
タスク管理アプリ。空の状態はイラストと「最初のタスクを作成」。タイトルを入力して送信すると 1 件目が一覧に現れる必要がある。現状は白い画面が一瞬挟まってから唐突に表示される
得られるもの
5 段階で設計します。イラストが 120ms でフェードアウトし、スケルトン行は実際の行高 56px とカードの角丸を踏襲します。120ms 後に 1 件目が 8px 上へ動きながらフェードインし、残りの行が 40ms ずつずれて出現、フォーカスは新しい項目のタイトルへ移り、スクロールは先頭を維持します。白く光るのは待ち時間に場所を確保していないためで、スケルトンで解消します。prefers-reduced-motion では移動とずれを外し、100ms の透明度切り替えだけ残します。
よくある誤用
- 遅い API をスケルトンで覆う場合です。遷移は 400ms 前提なので、通信に 2 秒かかるとスケルトンが固まったままになり、かえって不安を煽ります。
- 新しい内容を画面外から飛び込ませる場合です。24px を超える移動があると、「どこに追加されたか」という空間関係が失われます。
こう変えると効く
- 最後の 1 件を削除した後の逆方向の遷移に変えます。有から空への方が間違えやすく、イラストが急に現れるとエラーに見えます。
- 「失敗する分岐」を足します。送信に失敗したら入力内容を残し、その場にエラーを出す。遷移の設計には、うまくいかない道も含めます。