提出済みファイルの差し替えUX：レビュー履歴を失わない設計

提出後のファイル差し替えは、アップロードのやり直しとは違います。修正版の内容が正しくても、元のファイルに付いたレビューコメントや承認の経緯が消えてしまえば、確認作業は振り出しに戻ります。設計時にまず決めたいのは、有効なファイルが変わったとき、提出記録には何が残るのかという点です。

Pixsoで画面とレビューの流れを共有しながら、旧ファイル、差し替えの確認画面、完了後の状態を並べて検討できます。以下では、予算表に修正依頼が入った架空の企画書PDFを例にします。ここで述べる提出・承認機能は、設計対象となるポータルの仕様例であり、Pixso自体がPDFを保管・承認するという意味ではありません。

空のアップロード欄ではなく、提出済みの記録から始める

通常のアップロード画面には、まだ受け付けたファイルがありません。しかし、このケースでは Project_Plan_v1.pdf がすでに審査中です。レビュアーは6ページの予算表を修正するよう依頼し、提出者は Project_Plan_v1_corrected.pdf を選びました。ここでボタンが単に「ファイルをアップロード」では、追加添付なのか、有効なファイルの置き換えなのか、新しい提出を始めるのか判断できません。

ファイルを選ぶ前に、現在のファイル名、審査状態、修正依頼を表示します。実際に有効な添付を置き換える場合だけ「現在のファイルを差し替える」と明示しましょう。複数のファイルを同時に有効にする仕様なら「別のファイルを追加する」です。結果が異なる操作を同じ曖昧なラベルでまとめないことが大切です。

確定前に、新旧ファイルと影響を比較できるようにする

確認画面では、現在有効なファイル、これから有効になるファイル、旧版とレビュー記録の扱いを答えられる必要があります。新旧の名前を並べ、必要ならサイズやアップロード日時も添えます。ただし、ファイル情報を並べるだけでPDFの内容差分を示したかのように見せてはいけません。信頼できる内容比較機能がなければ、そのように説明しないことです。

この例では、差し替えが成功するまで元の提出ファイルを有効に保つ設計が安全です。通信が切れたりダイアログを閉じたりしても、提出記録は残ります。プライバシーや保存期間の方針によって旧版を削除するなら、確定前にその結果を知らせます。実際の保存規則を確認せず「いつでも履歴を復元できます」と約束してはいけません。

レビューコメントを提出記録から切り離さない

「6ページを修正してほしい」というコメントは、最初のPDFのデータだけでなく、審査対象の仕事に対する依頼です。差し替え後も、同じ提出ID、レビューのやり取り、そして「この依頼に対応して差し替えた」という履歴を通じて、修正版から依頼へたどれるようにします。データ構造は製品によって異なりますが、無関係な新規提出として黙って作り直すべきではありません。

ただし、旧PDFの6ページに付いたピンを、そのまま新PDFの同じ座標に移してはいけません。ページ順やレイアウトが変わっている可能性があります。以前のファイルに対するコメントだと明示し、レビュアーに修正版の該当箇所を再確認してもらうほうが確実です。確認後に修正を承認する、再修正を求める、今回の差し替えとは別の課題として扱う、といった判断ができます。

レビュアーが旧版を開いている間の動作を決める

提出者が修正版を選んでいる間も、レビュアーは旧版を読んでいるかもしれません。開いている文書を突然切り替えないようにします。旧版の確認を続けながら新版の到着を通知する方法も、差し替え完了まで承認を止める方法もあります。通常のフィードバックか、規制を伴う承認か、正式な記録かによって適切な規則は変わります。双方が異なる「最新版」を想定しないよう、事前に決めてください。

例えば10時02分にレビュアーが旧PDFを開き、10時04分に差し替えが完了したとします。旧版の6ページに書いたコメントは、実際に見た版に残します。10時05分に「承認」を押した場合、旧版を承認するのか、修正版を再確認してから承認するのか、どちらも承認しないのかが分からなければなりません。ボタンの近くに版名と状態を表示し、実装前に二つのブラウザーセッションで試しましょう。

失敗とキャンセルの結果を曖昧にしない

送信前には形式違い、空のファイル、容量超過などを検出できます。送信中の進捗は転送の進み具合であり、サーバーで検証され有効な版に切り替わった証拠ではありません。送信後の検査で拒否されることもあります。段階を分けて表示すれば、処理が終わっていないのに「完了」と誤認させずに済みます。

78％で通信が切れたら、元のファイルは有効なままだと伝え、安全に再試行できるようにします。修正版が拒否されたら理由を具体的に示し、レビュー依頼を失わずに別のファイルを選べるようにします。確定前のキャンセルでは元の提出画面に戻し、変更済みのように見せません。ファイルアップロードUIのガイド（英語）は選択・進捗・転送エラーを扱いますが、ここで加わる課題は既存のレビュー記録を保つことです。

GOV.UKのファイルアップロードのガイドには、具体的なエラーメッセージの例と、セキュリティーやプライバシーを踏まえて既存ファイルを再利用する考え方があります。ただし、レビュー後の差し替え規則そのものは各製品で決める必要があります。

見た目だけでなく、支援技術にも状態を伝える

「審査中」から「差し替え完了」への変化は、色だけに頼らず文字でも伝えます。フォーカスを突然移動させずに進行や結果を通知できるようにします。W3Cのステータスメッセージの解説は、フォーカスが移らない変化も支援技術を使う人に伝える必要性を説明しています。アップロード進捗の例は一つの方法であり、毎パーセントを過剰に読み上げる理由ではありません。

キーボードだけでも差し替え画面を開き、両方のファイル名を確認し、キャンセルまたは確定して、提出画面へ戻れるようにします。開いていたレビューコメントに戻る道も残します。狭い画面では新旧のカードを縦に並べても構いませんが、左右の位置関係だけで区別せず、それぞれの版を明記しましょう。

Pixsoで判断の流れを試作する

Pixsoのキャンバスに、修正依頼が付いた提出済みファイル、新旧を示す確認画面、修正版と同じレビューのつながりを示す完了画面を並べます。失敗時の画面も加えれば、デザイナーと開発者が、旧版の扱い、有効な版の表示、コメントへの戻り方を同時に検討できます。キャンバス内のファイルカードは設計例であり、Pixso固有の添付操作ではありません。

レビュアーには実際の修正依頼を想定して「前のコメントはどこにあるか」、提出者には「転送が失敗したら相手にはどの版が見えるか」を確かめてもらいます。答えを推測しなければならないなら、装飾や動きを詰める前に状態表示を直しましょう。各結果について有効なファイル、残るレビュー情報、復旧方法をチームが説明できれば、実装へ渡せる設計になります。