本文へ移動
← 記事一覧へ

調査・解説 · UI/UX ·

処理中の表示:待機・完了・結果不明を伝える

CSV出力の作例で、進捗の伝え方と、待った後の操作を決める。

この記事の目次

「作成する」を押したのに画面が変わらない。もう一度押すべきか、そのまま待つべきか。処理中の表示で伝えたいのは、動いていることと、次に何ができるかです。

管理画面や業務ツールを設計する人向けに、CSV出力の作例で考えます。以下の画面文言は架空の仕様に基づく提案で、待ち時間や誤操作の改善を測定した実例ではありません。

分からない進捗を、数字で埋めない

Carbonは、短い操作の処理中に使うインラインローディングで、状態に応じた説明を付けることを勧めています。例えば保存中から保存済みへ、処理と結果が分かる文言に変えます。Inline loading

割合を示すプログレスバーは、目標に対する進捗を計算できるときに使います。Carbonも、進捗が不明な表示では割合を出さない設計を区別しています。Progress bar

これをCSV出力に当てはめるなら、次のように分けられます。

分かっていること 表示の作例 避けたい表示
出力要求を受け付けたが、処理割合は不明 CSVを作成しています 根拠なく少しずつ進む「80%」
対象100件のうち40件の変換が終了 データを変換中:40 / 100件 ファイルの保存前なのに「出力完了」
ダウンロードできるファイルが完成 CSVを作成しました[ダウンロード] 回転する印が消えるだけ

40件という数字が示すのは変換の進捗です。その後にファイル保存があるなら、全工程の40%とは限りません。工程と数字の意味を揃えます。残り時間も、見積もる根拠がなければ約束しません。

作例:ボタンを押した後の三つの画面

この作例では、出力要求ごとに番号を発行し、後から同じ要求の状態を照会できる仕様とします。作成中の取り消し機能はありません。

受け付けて作成中

CSVを作成しています。
作成状況は「出力履歴」から確認できます。この画面を閉じても処理は続きます。
[出力履歴を見る]

「閉じても続く」と書くには、実際に画面から離れても処理が続き、履歴から結果を取得できる仕組みが必要です。ブラウザー内だけで作成する機能には、この案内を流用できません。

ファイルの完成を確認できた

CSVを作成しました。
[ダウンロード][出力履歴を見る]

応答が途切れ、状態を照会しても確認できない

作成結果を確認できませんでした。処理が続いている可能性があります。
新しく作成する前に、出力履歴で状態を確認してください。
[出力履歴を見る]

これは「作成に失敗しました」とは別の状態です。例えばStripeのAPIでは、通信障害で要求が受け付けられたか分からなくなる場合を明示し、同じ要求を識別して結果を得る仕組みを案内しています。具体的な再送条件はAPIごとに異なります。Advanced error handling:Network errors

このCSVの作例でも、履歴の一覧に見当たらないだけで未実行とは決めません。要求番号に対応する処理状態を確かめます。確認不能が続く場合に備え、問い合わせ先へ番号を渡せる導線も設計します。

止める操作と、使える操作を分ける

Carbonは、ボタンの処理中に再び実行できないようにすることを案内しています。Inline loading:Interactions

作例では、同じ条件で出力を繰り返す操作を一時的に使えなくし、履歴への移動は残します。無関係な作業まで画面全体で止める必要があるかは別に考えます。ボタンの無効化だけで、別タブや通信再試行による重複まで防げるわけではありません。同じ要求の識別と二重処理の扱いは開発側で決めます。

また、画面を閉じる操作と、処理の取り消しは別です。取り消せない処理に「キャンセル」とだけ書くと、何が止まるか分かりません。この作例なら「出力履歴を見る」と行き先を示します。

回転する印だけで終わらせない

W3Cの達成基準4.1.3の解説では、フォーカスを移さずに追加される待機・完了などの状態メッセージを、支援技術でも認識できるようにすることを説明しています。処理中の表示を消すだけでは、待機が終わったことが伝わらない場合もあります。Status Messages

画面内で状態が変わる作例では、開始・完了・確認不能を文章でも伝え、適切なライブリージョンなどで通知します。進捗の数字を毎回読み上げればよいわけではありません。作業を妨げない頻度か、画面を見ずに結果が分かるかを、実際のブラウザーとスクリーンリーダーで確認します。

最後に確認する五つのこと

  • 押した直後に、要求を受け付けたかが分かるか。
  • 割合や残り時間は、取得できる情報に基づいているか。
  • 完了、確認済みの失敗、結果不明を分けているか。
  • 離脱後の確認先と、確認できないままの場合の案内があるか。
  • キーボードや読み上げでも、状態と次の操作を把握できるか。

入力内容を直す必要がある失敗はフォームのエラー表示、実装前に状態ごとの期待結果を揃えるなら受け入れ条件の書き方につなげて読めます。

Loading...