エラーメッセージのUXライティング：直せる状態と不確かな結果を伝える

役に立つエラーメッセージは、何が起きたか、利用者が何を変えられるか、現在の状態で次に何をすればよいかを伝えます。「問題が発生しました」だけでは、そのどれも分かりません。具体的に書くことは、長く書くことではありません。ファイルの形式や容量が問題なら、「10 MB未満のPDFを選択してください」で必要な情報を伝えられる場合があります。

エラー文言は画面の完成後ではなく、状態を設計するときに書きます。チームでUXを設計するワークフローでは、デザイナー、ライター、開発者が、システムで何が分かっているか、利用者が次に安全にできる操作は何かをそろえます。この記事では請求書のアップロードを例に、入力エラーから送信結果が分からない状態までを扱います。

文章を書く前に、何が問題かを特定する

買掛金を処理するフォームに、請求書番号、金額、添付ファイルがあるとします。請求書番号の未入力、非対応のファイル、アップロードの一時的な失敗、送信結果の未確認を、同じ赤いバナーで正確に説明することはできません。原因を解消できる人も、安全な次の操作も異なるためです。

ここで使う10 MBという上限は、例に登場する請求書サービスの設定であり、Pixsoのアップロード上限ではありません。実際の製品では、サーバー側が適用する条件を使います。文言で伝える上限と検証処理の上限が違えば、どれほど読みやすく書いても不具合になります。

入力欄のエラーは、実行できる指示にする

請求書番号が空欄なら、「入力が不正です」より「請求書番号を入力してください」と伝えます。金額が許可する範囲から外れている場合は、入力欄と同じ通貨・数値形式で範囲を示します。サービス側で現在確認できないデータについて、利用者に落ち度があるかのように書かないでください。

GOV.UKのエラーメッセージのガイド（英語）は、問題の直し方が分かる、具体的で理解しやすい説明を勧めています。すべてのフォームへ同じ一文を当てはめるのではなく、該当する入力欄に合わせて使います。

閲覧する権限がない人に、口座番号、仕入先の非公開情報、他人の情報をメッセージで見せてはいけません。具体性は製品のアクセス制御の範囲内で役立てます。内部の診断情報を表示する代わりに、サポートが調査できる参照番号を示す方法もあります。

失敗した処理と、結果が分からない処理を区別する

送信前に添付ファイルのアップロードが失敗したなら、「添付ファイルをアップロードできませんでした。ほかの入力内容は残っています。もう一度アップロードしてください」が適切な場合があります。一方、フォームを送信した後に応答だけが届かなかった場合、「送信に失敗しました。再試行してください」では請求書を重複登録させる可能性があります。サービスが受け付けたかどうかは、まだ分かっていません。

結果が未確認なら、「この請求書が送信されたか確認できていません。再送信する前に状況を確認してください」のように伝えます。「状況を確認」の操作を置くのは、製品が実際に結果を照会できる場合です。照会できないなら、請求書一覧を確認する、参照番号を添えてサポートに問い合わせるなど、利用できる経路を示します。

この動作は開発者と合意しておきます。ボタンの無効化、リクエストの識別子、結果の照会は、文章を柔らかくすること以上に重要な場合があります。再試行が同じ処理を再利用するのか、新しい処理を始めるのかを、書き手も知る必要があります。タイムアウトしたという理由だけで、「何も保存されていません」と断定してはいけません。

表示する場所とタイミングを合わせる

請求書番号のエラーはその入力欄の近くに置き、実装でも欄と説明を関連付けます。サービス全体の中断はフォーム全体で伝える情報です。送信後に複数の欄でエラーが見つかる場合は、要約から各問題へ移れるようにします。同じ説明をバナー、トースト、入力欄の横へ同時に繰り返すことは避けましょう。

利用者が入力を終える前から、欄を不正と扱わないようにします。金額を打ち込んでいる途中の未完成な値と、送信時に受け付けられなかった値は同じではありません。選ぶファイルに関わる制限など、事前に役立つ説明はエラーが起きる前から見せます。

エラーの意味を色だけに任せず、文字やアイコンも使います。翻訳によって文章が長くなっても、操作ボタンを覆ったり、どの入力欄の説明か分からなくなったりしない配置が必要です。失敗後は製品のセキュリティ要件に沿って修正可能な入力を維持し、「入力は残っています」と伝えるのは、その動作が実装されている場合に限ります。

Pixsoでエラーが起きる一連の流れを確認する

請求書フォームの未入力、容量を超えた添付、アップロード中、アップロード失敗、送信結果の未確認、受付完了をそれぞれフレームにします。請求書番号は一連の画面でそろえます。メッセージと操作ラベルは文言一覧だけに置かず、実際に表示される画面へそのまま入れてください。

各フレームの横に、表示する条件、保存されたままの情報、主な操作を実行した結果を記入します。開発者には、サービス側で保証できない表現がないか見てもらいます。その流れを知らないデザイナーやライターには、次に何をすると思うかを説明してもらいます。未確認の状態で再送信しようとしたら、ラベル、配置、説明を一緒に見直します。

添付ファイルの設計では、選択、進捗、再試行の動作と、エラーの文言をそろえます。文言だけを仕上げるのではなく、どの状態から何ができるかを画面全体で伝えることが重要です。

原因と復旧方法でメッセージを管理する

メッセージのライブラリは、未入力、形式違反、競合、サービスの停止、結果の未確認といった原因でまとめると再利用しやすくなります。各パターンには必要な変数と条件を添えます。「最大容量」の文言には実際の上限が必要であり、「登録済みの項目を確認する」という操作には、閲覧可能な移動先が必要です。

見つけやすいという理由だけで、どの失敗にも同じ文をコピーする運用は避けます。製品の用語は統一しつつ、対象と操作は具体的にします。「添付をアップロード」「請求書の状況を確認」「登録済みの請求書を確認」は、三つとも「再試行」にするより、何が起こるかを伝えられます。

問い合わせやリサーチで混乱が見つかったら、文言と、その前提になる状態を一緒に更新します。フォームの入力を失わせたり、二重送信したりする動作は、言い回しだけでは直せません。Pixsoでエラー時の画面を設計し、チームで確認する。