時間のかかる書き出しのUX：進捗表示と再取得の設計

大きなファイルの書き出しには、回り続けるアイコンだけでは足りません。処理が始まったのか、画面を離れてよいのか、完成したファイルはどこに現れるのか、取得期限を過ぎたらどうするのかを伝える必要があります。ここでは42画面を含む架空のデザイン引き継ぎパッケージを例に、待機中から結果の取得までを一つの操作として設計します。各状態はPixsoのプロトタイピング機能でつないで確認できます。

処理内容と完成後の置き場所を先に決める

この例のパッケージには、選択した42画面、現在のデザイン仕様、関連アセットの一覧が含まれます。依頼者は形式を選んで生成を開始します。待機画面を描く前に、何を含めるか、タブを閉じてもサーバー側の処理が続くか、完成品をどこに一覧表示するか、ダウンロードリンクはいつ切れるかを決めます。これらは製品とバックエンドの仕様であり、きれいな進捗アニメーションでは代用できません。

開始画面には「Autumn launchの42画面」、選択した形式、保存先を明示します。含められない画面があるなら依頼前に知らせるか、完成後に省略された画面を名指しで説明します。欠けたパッケージを無条件に「書き出し完了」と表示してはいけません。この架空の例では完成品を７日間取得できますが、Pixso自身の保存期間や書き出し機能を示す数字ではありません。

依頼には一意に追跡できるジョブを持たせます。別の画面に移動して戻ったとき、同じ処理を見つけられなければ二重に開始するおそれがあります。２回目のクリックで既存ジョブを開くのか、新しい版を作るのか、処理を再開するのかをバックエンドの仕様と揃えます。

測れていない進捗率を表示しない

「パッケージを準備中」は次の状態につながっていれば意味があります。一方、全体の作業量が不明なのに「73%」と表示しても判断材料になりません。この例ではサーバーが「待機中」「ファイルを収集中」「パッケージ化中」「準備完了」を返せますが、残り時間は安定して見積もれません。そこで現在の段階と終了時刻を約束しないインジケーターを示します。後に総作業量を一貫して測れるようになれば、確定的な進捗バーを検討できます。

複数段階があるなら、最初の段階が終わっただけで全体を100%にしません。「ファイルを収集中」から「パッケージ化中」へ進むことを言葉で伝えます。測定対象が途中で変わる場合も、たとえば一部の画面を除外したことを説明し、無言で進捗率を戻さないようにします。

画面を離れても処理を見失わない

処理が数分続き、画面遷移後もサーバー側で実行されるなら、モーダルの前で待たせ続ける必要はありません。例では「ほかの作業を続けられます。結果は『書き出し』で確認できます」と伝えます。利用者はパネルを閉じ、別のデザインファイルを開き、後で書き出し一覧に戻れます。一覧には同じジョブの名前、開始時刻、現在の段階、実行可能な操作を表示します。

タブを閉じるとサーバーの処理も止まるなら、「バックグラウンドで続行」とは約束できません。それは文言を決める前に解決すべき機能要件です。通知は完成を知らせる補助になりますが、見逃したり無効化されたりします。完成品へ戻るための安定した経路は一覧側に残します。

同じ内容の複数ジョブも見分けられるようにします。「Autumn launch ― PDF ― 10:42開始」のほうが、すべて「書き出し」と表示するより探しやすくなります。パネルを閉じる操作とサーバーのジョブを中止する操作は分けます。画面を離れただけで処理が取り消される設計にしないためです。

「準備完了」を実際に取得できる状態にする

完成画面にはファイル名、形式、分かる場合のサイズ、「パッケージをダウンロード」を示します。この例のように７日でリンクが切れるなら、利用者の地域に合った日時で期限を表示します。「しばらく利用可能」では、翌日チームに渡せるか判断できません。保持期間中は一覧から同じジョブに戻れるようにします。

サーバーでパッケージが完成することと、ブラウザーへの保存が成功することは別です。ダウンロードのブロック、通信切断、端末の空き容量不足があっても、サーバー上の完成品まで「失敗」にしてはいけません。保持期間が終わるまでは取得可能な状態を保ちます。HTTPのContent-Dispositionの解説には、添付ファイルとして扱い推奨ファイル名を指定する方法が記されています。ただし技術的な設定だけでは、画面上の分かりやすいファイル名と操作を代替できません。

リンクが切れた後は汎用の404ページに置き去りにしません。「このパッケージは利用できなくなりました」と名前を示し、可能なら以前の対象を選択した状態から新しい書き出しを始められるようにします。元のデザインが変わっている場合、新しいパッケージは現在の版を反映することを伝え、完全に同一のファイルが戻ると約束しません。

失敗と結果不明を分けて回復する

失敗の種類を混同しません。開始前の検証エラーなら、不足している権限、利用できない画面、非対応形式を明示します。開始後に処理が失敗したらジョブの記録を残し、利用できるパッケージがないことと、安全に再試行できる条件を示します。期限切れは処理失敗とは別の状態です。

依頼送信中の通信断は特に曖昧です。ブラウザーに返事がなくてもジョブだけ作られた可能性があります。「もう一度試す」を出す前に依頼IDで照会するか、書き出し一覧を確認します。そうしなければ同じ大きな処理を二重に起動しかねません。再試行が既存ジョブの再開、新版の作成、部分結果の利用のどれに当たるかも仕様と一致させます。

中止ボタンを置くなら、サーバーの処理を止められるか、途中のファイルが残るか、いつ「中止」と表示するかを定めます。進捗パネルを閉じるだけなのに「書き出しを中止」と書くのは誤解を招きます。中止できないなら「パネルを閉じる」のほうが正確です。

状態を誰にも伝え、全体の導線を試す

ジョブに読める名前を付け、変化する状態を色だけでなく文章でも伝えます。数値の進捗バーなら現在値と範囲を支援技術へ公開し、総量が不明なら値を作らないようにします。W3Cのmeterに関する指針は、単なる数値の計器とタスクの進捗を区別し、進捗にはprogressbarを使うと説明しています。また状態を通知するライブ領域の手法も参考になります。見えるバーだけでは画面読み上げ利用者に更新が伝わるとは限りません。

依頼画面、待機、処理中、一覧の行、取得可能、期限切れ、失敗、送信結果不明をPixsoで描きます。「画面にとどまる」と「離れてから戻る」の二つの経路をつなぎます。レビュー担当者に「処理は続いているか」「完成品はどこか」「リンクが切れたらどうするか」を説明してもらい、答えが見つからない状態を直します。

開発者には、実際のジョブ状態、保持期間、再試行、権限の規則と一緒にプロトタイプを渡します。Pixsoは操作の設計とレビューに役立ちますが、実運用のジョブ処理やファイル配信はサービス側で実装する必要があります。Pixsoで書き出しフローを組み立てる。