エラーメッセージ

エラーメッセージとは

エラーメッセージは、処理が失敗した際に出現するメッセージです。UXライティングの中で「最も目につきやすい」と指摘されています[*出典]。エラーメッセージが表示されることは、ユーザーにとってポジティブな体験ではありません。ユーザーが期待しているものとは別の、操作を阻むものが表示され、ユーザーが処理を完了できなくなるためです。エラーメッセージは、ユーザーにフラストレーションを感じさせます。何度も出現することでユーザーは疲弊し、最後には諦めてしまいます。

エラーメッセージの書き方

エラーメッセージを書く際には、ユーザー自らが解決できるようにすることを目指します。状況を説明すると同時に、どうやったら解決できるのかを書きます。書き始める前には、問題が発生する原因や背景、ユーザーの状況を詳細に把握します。

文章で書く

エラーメッセージは文章で書きます。たとえば「カタカナで入力」ではなく「カタカナで入力してください。」のような書き方をします。句点はつけてもつけなくても問題ありませんが、いずれかに統一します。

出典：Netflix

ユーザーを非難しない

エラーメッセージは、ユーザーを非難しないように書きます。たとえユーザーのミスでエラーが発生していても、ユーザーの間違いを責めるのではなく、常に支援する姿勢である必要があります。

そのためエラーメッセージのトーンは、協力・応援を促すものにします。たとえば「間違っています。」「失敗しました。」「できませんでした。」といった口調はユーザのモチベーションを低下させます。できる限り、協力して解決に結びつけるような口調で書きます。

プログラム目線ではなくユーザー目線で書く

エラーメッセージは、プログラム目線の言葉ではなく、ユーザーが読んで分かる言葉で書きます。たとえば「画像データがありません」「ユーザ情報が取得できませんでした」「認証に失敗しました」「取得に失敗しました」「空白が入力されています」といったメッセージはプログラムの観点で書かれています。そうではなくて、「新しい画像を登録してください」のように、ユーザーから見て内容が理解できるように書きます。

何が起きているかを説明する

なぜユーザーのタスクが完了できないのかを書きます。どのような現象が起きているのか、どのような操作が悪かったのかを簡潔に説明します。

どうすれば解決できるのかを伝える

具体的な解決策を書きます。ユーザーが次に何をすれば、目的としているタスクを完了させることができるのかを明らかにします。

エラーメッセージの種類

エラーメッセージには、インラインに表示するエラーメッセージや、モーダルに表示するエラーメッセージ、別ページに遷移するエラーメッセージという種類があります。

インラインに表示するエラーメッセージ

インラインに表示するエラーメッセージとは、ユーザーがアクションを行う同一画面上に表示するエラーテキストのことです。ユーザーのアクションを阻害しないためストレスが最も少ない方法です。インラインエラーは各フォームの項目の下と、ページの最上部か送信ボタン付近に表示します。

各項目の下に表示する。 入力フォームの下にエラーの内容を記載します。ユーザーにとってのストレスが最も少ないのがこのタイプです。

出典：Amazon

ページ最上部か送信ボタン付近に表示する。 複数のエラーがあることを伝える場合や、各項目の下に表示するエラーメッセージに該当するものがない場合には、ページ最上部か送信ボタン付近にエラーメッセージを表示します。場合によってはトーストで表示することもあります。

出典：airbnb

モーダルで表示するエラーメッセージ

そのページのメインのアクションが取れず、別のページでアクションが必要な場合には、モーダルでエラーメッセージを表示します。モーダルで表示することで、ページからの迂回をうながすことができます。

モーダルのタイトルには、アクションタイトルをつけ、ボタンもアクション名をつけます。ディスクリプションには、発生した問題や、問題を解決するメリット、アクションの説明を「〜をするには、〜をしてください。」の形で記載します。

別ページに遷移するエラーメッセージ

別ページに遷移するエラーメッセージとは、システムの不具合によるエラー（500エラー）やURLが見つからない（404エラー）、メンテナンス中のエラー（503エラー）など、それ以上の行動ができない場合に、別のページに着地させるエラーです。

タイトルにはアクションタイトルを記載します。「サーバーエラーが起きました」というようなエラーの説明は記載しません。ユーザーが何をすべきかを記載します。ディスクリプションには、問題の説明と、アクションの説明を「〜をするには、〜をしてください。」の形で記載します。

エラーメッセージの管理をソースコード上で分離する

システムの規模が大きくなる場合には、エラーメッセージを専用のファイルに記載して、ロジックから分離するように努めます。分離したエラーメッセージは、ロケールファイルやコンフィグファイルなどに配置します。エッジケースでは、エラーメッセージを修正するのが困難になるためです。たとえば、月末のバッチ処理に、課金のオンライントランザクションが衝突するといった極めて稀に発生するエラーの場合には、エラーメッセージを再現して修正することがほぼ不可能となります。エンジニアがロジックを組み上げる過程でエラーメッセージを設定して、ディレクターがエラーメッセージをまとめて確認するようなフローの中では、エラーメッセージの修正が難しくなるのです。

エラーメッセージを一元管理することで、そのエラーを再現させなくともエラーメッセージを修正できるようになります。コード上は、変数名から起こりうる条件を想起できるようにして、必要であれば発生方法をコメントで記載しておきます。

エラーが発生しないようにする

エラーメッセージを書く以前に、エラー自体が発生しないようにシステム自体を見直す観点も必要です。たとえば入力規則をディスクリプションに書いておく、ハイフンの自動変換を行う、大文字・小文字を自動修正する、半角・全角を自動変換する、フリガナはカタカナしか入力できないようにする、といった工夫をすることで、ユーザーに大きなストレスをかける前に、解決できるように努めます。