CSVインポートのUX：レコードを変更する前に列を対応付ける

CSVインポートの画面では、データを書き換える前に「各行を取り込むと、何が起きるのか」を確認できる必要があります。ファイルのアップロードは、その最初の段階にすぎません。列と項目の対応、識別子が指すレコード、既存値の扱い、取り込めない行まで説明できて初めて、利用者は安心して実行を判断できます。

進捗バーを100%にすることではなく、これらの判断を中心に画面を組み立てます。転送が成功しても、識別子が重複していたり、列を誤った項目に対応付けていたりする可能性があります。フォームの状態と入力検証を、実際にデータを確定する処理と分けましょう。「インポート可能」と「インポート完了」が同じ見た目にならないようにします。

判断の違いが表れる小さなファイルから始める

ここでは、架空のワークショップ参加者管理アプリを例に考えます。管理者は、新しい参加者の追加と既存の参加者情報の更新を行おうとしています。このアプリはレコードIDで照合します。氏名とメールアドレスは画面上で人物を確認するための情報であり、照合キーではありません。参加者ごとにメールアドレスと1つのワークショップを指定する必要があります。

ファイルには、次の5行のデータがあります。行番号にはヘッダー行を含めません。P-104とP-102は既存レコードで、P-108とP-109はまだ存在しません。P-102には現在「デザインシステム」が設定されています。

この5行だけで、新規作成、更新、安全に判断できないための保留という3種類の処理を検討できます。問題のないデータを100行並べるより、画面の設計課題が見えやすくなります。

元の列と取り込み先を隣り合わせにする

対応付けの各行には、元の列名、代表的な値、取り込み先の項目、必要な入力条件を表示します。取り込み先の名前だけを選ぶドロップダウンでは、利用者が表計算ファイルの中身を覚えておかなければなりません。値のプレビューがあれば、その場で対応を確かめられます。

「ワークショップ」の行なら、「リサーチ」「プロトタイピング」といった値を、取り込み先の「ワークショップ」の横に表示します。アプリがワークショップIDを保存する仕組みなら、表示名をどのIDに対応させるかも明らかにします。同じ表示名のワークショップが複数ある場合は、区別できる情報が必要です。名前がそれらしく見えるだけでは、安全に対応付けられません。

自動で提案した対応は、確認が終わるまで変更できるようにします。「提案済み」と「確認済み」を表示や説明で区別し、必須項目に対応する列が未設定なら知らせます。任意の列には「この列を取り込まない」という明確な選択肢を用意します。未選択のままにしたときに、黙ってスキップ、値の削除、新しい項目の作成のいずれかが実行される設計は避けましょう。

HubSpotのインポート手順（英語）では、プロパティの対応付け、レコードの識別子、既存値を保護する設定を分けて扱っています。具体的な動作は同製品の仕様ですが、判断をインポートボタンの裏側に隠さず、画面に表すという点は参考になります。

プレビューの前に処理方法と照合ルールを決める

既存のIDを含むファイルでは、「参加者をインポート」という説明だけでは足りません。新規作成のみ、既存レコードの更新のみ、その両方のどれを行うかを示します。そのうえで、識別子が空欄の場合や、まだ存在しないIDが指定された場合の動作を説明します。

この例では、「新しい参加者を作成し、一致する参加者を更新」を選択します。照合にはレコードIDを使います。有効な未登録IDなら新規作成、既存IDなら更新が可能です。氏名が一致するだけでは、どちらの処理にも進みません。これらのルールは、ヘルプページだけでなく選択肢の近くに示します。

空欄の扱いも決めておく必要があります。後から任意の「メモ」列が加わった場合、空のセルは既存のメモを保持するのでしょうか。削除するのでしょうか。それともエラーにするのでしょうか。この例では、任意項目の空欄は既存値を保持し、削除には明示的な操作を必要とします。誤消去を防ぐための方針ですが、すべての製品に共通するルールではありません。空欄を削除として扱うアプリなら、その結果を同じように明確に伝えます。

未対応の列、空欄、不正な値、明示的に削除する値は区別しましょう。表計算ファイルでは似て見えても、取り込み先で起きることは異なります。

ファイルの見本ではなく、変更内容を確認できるようにする

元データのプレビューは「CSVを正しく読み取れたか」に答えます。変更内容のプレビューは「これを実行すると何が起きるか」に答えます。後者には、各行の予定処理と、更新する場合に変わる項目を表示する必要があります。

この例のアプリでは、レコードIDが重複している行をすべて保留し、管理者が重複を解消するまで反映しません。先に現れた行や最後の行を、勝手に正しいものとして採用しない方針です。また、このファイルの取り込みは、検証上の問題をすべて解消してから確定します。

集計は新規作成1行、更新1行、要確認3行で、元の5行と一致します。これはプレビュー上の予定だと分かるように表示します。完了のチェックマークを付けたり、すでに参加者を1人作成したかのように伝えたりしてはいけません。

「要確認」だけに絞り込めるようにしつつ、ファイル全体の件数と元の行番号は保持します。一部だけをプレビューしているなら、そのことを明記し、取り込み可能と判定する前にファイル全体を検証します。最初のページに問題がないからといって、残りの行まで問題がないとは限りません。

Pixsoで対応付けと変更結果を並べて検討する

Pixsoのデザインファイルに「列の対応付け」と「変更内容の確認」の2つのフレームを作り、同じ5行の参加者データを使います。前者では「ワークショップ」の値の例と取り込み先を並べます。後者には処理予定の件数、要確認の3行、P-102の「デザインシステム → プロトタイピング」という変更を表示します。

対応付けの操作部分とレコードのプレビューは、別々のコンポーネントにします。対応を修正した場合の表示を、画面全体を作り直さずに検討できます。プレビューの横には、対象の3行の問題が解消するまで取り込みを実行できないことを注記します。レビューする人には、どの参加者が既存で、どの値が変わり、すでに確定した変更があるかを尋ねてください。口頭の補足ではなく、画面から答えが分かることが重要です。

Pixsoでインポートの確認画面をデザインする →

修正する場所と元の問題を結び付ける

「インポートに失敗しました」だけでは、管理者はどこから直せばよいか分かりません。対応につながるエラーには、ファイル、元の行または列、安全に表示できる場合は問題の値、理由、次の操作を含めます。識別子の重複と必須項目の空欄を、区別できない同じ赤い警告にまとめないようにします。

HubSpotのエラー解説（英語）は、レコードIDの重複、行内容の重複、一意であるべきプロパティ値の重複を分けています。単に「重複」と表示すると、実際の処理結果の違いが隠れるため、エラー名も動作に合わせる必要があります。

参加者の例では、管理者がP-104を「プロトタイピング」に参加させると判断したとします。元の1行目を削除し、Jo Riveraのメールアドレスを補います。修正後のファイルは4行になるため、プレビューも再計算しなければなりません。新規作成2行、更新2行、要確認0行です。入力が変わったのに、古い「全5行」を表示し続けないようにします。

画面内で値を修正できる場合は、元のファイル自体が変わるのか、今回取り込むデータだけが変わるのかを説明します。後でエラーが起きても対象レコードを特定できるよう、元データとの対応を残します。ファイルを差し替えた場合は、列の構成が一致するときに限って対応付けを引き継ぎ、再確認が必要な項目を示します。

準備完了、処理中、完了を分けて表示する

最終操作の前に、ファイル名、処理方法、識別子、最新の件数、変更する項目を示します。「参加者4人をインポート」というボタンも、その近くで新規作成2件・更新2件と説明して初めて意味が明確になります。プレビュー後に既存レコードが変わった場合は、古い見込みを黙って適用せず、再検証します。

処理中は重複操作を防ぎ、インポートを特定する参照情報を保持します。応答が途切れた場合は、すぐにファイル全体の再送を促すのではなく、元の処理状況を確認する導線が必要です。これには実装上の仕組みが必要で、ボタンを無効にするだけでは二重処理を防げません。

処理後は、確認できた結果を報告します。一部だけ完了する可能性があるなら、完了、スキップ、失敗を分け、未解決のレコードだけを再試行できるようにします。成功した新規作成まで繰り返させてはいけません。一括で成功または失敗する方式なら、その仕様を明示し、部分成功の画面を流用しないようにします。

最後の画面で、管理者が取り込んだレコードと変更内容を確認でき、残っている問題にも対応できることが大切です。参加者一覧とのつながりがない緑色の進捗バーより、実際の作業完了を確かめられる画面になります。