フォームの入力エラーメッセージを書く方法

メールアドレスを入力し、次の項目へ移ったところで、役立つ修正の案内が出る。一方、別の人は、まだ入力している途中でほぼ同じ文を見せられ、何を間違えたのかと戸惑う。文言は同じでも、体験は違います。

フォームの入力エラーメッセージの設計が、意外に難しいのはこのためです。急かすようなタイミングは、優しい言葉にしても救えません。正確な説明も、間違った回答を指していれば役に立ちません。考えるべきなのは、システムに何が分かっていて、いつ伝えるべきで、その人が次に何をできるかです。

参考にできるよい根拠はありますが、すべてが一つの万能なパターンを示しているわけではありません。ECの調査、行政サービスの指針、登録フォームの実験では、操作を中断することと早めに知らせることの重みが違います。その違いを理解するほうが、「完璧」とされるエラーメッセージの一覧を集めるより役立ちます。

バリデーションについて、実際の利用者から分かること

Edward Scottが2024年1月に公開したBaymardのインラインバリデーションのテスト報告では、L.L.Beanを使った参加者がメールアドレスの@を入力し忘れました。次の欄へ移るとフィードバックが出て、数秒で修正できました。Etsyでは、別の参加者が、まだ何も入力していない住所欄に入った時点でエラーに出会い、答える前から叱られていると感じました。REIには、別の修正例があります。カードのセキュリティコードに不足していた三桁目を入力すると、エラーが消えました。

これらの過去の観察から分かるのは、「インラインバリデーションを使っている」だけでは、説明として不十分だということです。メッセージが出る瞬間と消える瞬間は、文言と同じくらい重要になり得ます。

自分たちのフォームをレビューするなら、私はこう問い直します。そのメッセージは、本人が終えたと思っている行動に反応しているでしょうか。「続ける」をクリックすることは、その意思を明確に表します。入力欄を離れることがそうである場合もあります。空欄にカーソルを置くことは、通常そうではありません。必要なのは、中断する理由です。今の値がルールを満たしていないというだけでは足りません。

有用な対照例が、Luke WroblewskiとEtreによる2009年の登録フォームの調査です。22人が六つの案を試しました。報告では、最もよいインラインバリデーションの案は、対照条件に比べ成功率が22%上がり、完了時間が42%短くなりました。ある参加者は、間違いはその都度分かるほうがよいと話しています。一方で、よく知っている内容への回答の横に緑のチェックが出ると、システムが実際に何を確認したのかについて混乱も生じました。

この調査から最も役立つのは、不確かさについての教訓です。利用可能なユーザー名を選ぶ人は、システムが持つ情報を必要としています。自分の名前を入力している人には、システムからのお墨付きは必要ないかもしれません。私は、フォーム全体に均等に承認の記号を配るより、分からないことを解消する場面を優先します。

GOV.UKが別のタイミングを選ぶ理由

GOV.UKのバリデーションのパターンは、入力欄を離れる時点ではなく、続行や送信を試みた時点まで待つことを勧めています。入力した回答を残し、先頭にエラーの要約を置いてそこへフォーカスを移し、関係する欄のそばにもエラーを示すことも勧めています。もっと早い確認には、裏付けとなるユーザー調査が必要です。

ECの例との違いは、そのまま理解しておく価値があります。一つの質問だけの短いステップなら、送信時に修正を求めても、回答はまだ目の前にあります。長い購入手続きでは、送信する頃には、間違った欄がずっと前に離れていることがあります。

ワークショップの予約フローをレビューするなら、私は作業の形から考えます。日付だけを聞くページなら、「続ける」を押す時点で、その日が選べないと説明するのは妥当です。連絡先、アクセシビリティ上の要望、席数、請求情報が一ページにあるなら、最後まで待つことで、フォームを長くさかのぼる必要が出ます。だからといって、すべてをリアルタイムで確認すべきとは限りません。必要な箇所での早めのフィードバックを試す価値がある、ということです。

案内とエラーにも違いがあります。パスワードのチェックリストは、入力中に条件を説明しながら、未達の項目をすべて失敗扱いせずに済みます。日付のヒントは、値が入る前に予約できる期間を説明できます。役立つ案内は送信まで待つ必要がなく、早めの案内を赤い警告に見せる必要もありません。

どの欄にどのタイミングを使うかを書き出しましょう。そうしないと、「インラインで確認します」の裏で、三人が三通りの動作を実装することになりかねません。

システムが本当に根拠を持てる修正を伝える

「有効なメールアドレスを入力してください」は、本来ここから説明すべきところで、会話を終わらせてしまいがちです。ここでの有効とは何でしょうか。未入力、形式の誤り、利用不可、未確認は、別々の状態です。同じ意味として扱うと、自信ありげなのに次の行動を説明しないメッセージになります。

架空のワークショップのフォームなら、空の連絡先欄には「予約確認を受け取るメールアドレスを入力してください」と書けます。入力した文字に@がなければ、「@を含むメールアドレスを入力してください」なら観察できる問題を示します。どちらも、そのメールボックスが存在することや、本人のものであることを確認したわけではありません。それには別の検証手順が必要です。

考えられる入力ミスごとに、極端に具体的な文を書きたくなります。ただし、確認ロジックが確実に見分けられないなら、私は避けます。珍しいけれど正しいドメインを使う人に、ドメインが間違っていると伝えても役立ちません。システムが確信できないなら、拒否するより、任意の提案がよい場合もあります。文言を承認する前に、その違いについてチームで合意する必要があります。

ワークショップの例について、小さなメッセージ一覧を作りました。同じ欄でも複数のメッセージが必要なので、各行は条件から始めています。

最後の行は、意図的に、文章以上のことをプロダクトに求めています。状況確認を案内してよいのは、実際に使える確認方法がある場合だけです。なければ、開発とサポートで別の復帰経路を決める必要があります。「もう一度お試しください」で隠すのではなく、文言によって未決の判断を明らかにするべきです。

長いフォームでも、失敗後に必要な場所へ戻れるようにする

予約ページの下のほうで「続ける」を押す場面を想像してください。上部の二つの欄にエラーが出ましたが、画面にはまだボタンが見えています。画面外のどこかに赤い枠が出るだけでは足りません。操作が完了しなかったと気づき、修正が必要な回答へ戻れる必要があります。

ワークショップの例なら、要約に席数と日付の問題を挙げ、それぞれの欄へのリンクにできます。入力欄の横の説明は、修正中も回答のそばに残します。この繰り返しには意味があります。要約は移動を助け、その場の説明は編集を助けます。二か所で文言を変えると、同じ意味かを読み替える余計な作業が生じます。

要約に載せる内容も選びます。必要な確認を通過した連絡先メールは、エラー一覧には入りません。きれいなリセット状態を作るために、フォーム全体を空にするべきでもありません。前の回答が見えると、何が起きたかを理解し、必要な箇所だけ変えられます。機微な情報の保持は、別途プロダクトとセキュリティ上の判断が必要です。すべての欄を常に保存すると約束してはいけません。

ここで、静止画のデザインレビューを、操作のレビューに変える必要があります。キーボードで要約のリンクをたどります。フォーカスの位置、固定ヘッダーの下でもラベルが見えるか、入力欄に着いたとき説明を利用できるかを確認します。その後、修正して再送信します。スクリーンショットには赤い枠を示せますが、この道筋が機能することまでは証明できません。

モバイルでは、キーボードを開いた状態でも同じ流れを確認します。デスクトップの枠内ではきれいに収まるメッセージも、スマートフォンではキーボードの下に隠れるかもしれません。長いエラーは、読めないほど縮めずに折り返します。完了に必要な説明を拡大して読ませるくらいなら、私は修正案内にもう一行を使います。

事実が変わったら、メッセージも変える

よくあるレビューの失敗は、通常とエラーの二画面だけを承認することです。困るのは、その間にあることが多いものです。回答を編集してもとの問題がなくなったのに、赤いメッセージが残る。本人から見ると、修正がうまくいかなかったように感じられます。

ワークショップのフォームで、4席を希望し、残りが2席だったとします。数量を2に変えたら、該当するルールをもう一度確認するべきです。日付を変える場合は違います。ルールが依存する空席の対象が変わるため、前の開催回への警告を、新しい開催回にそのまま付けることはできません。赤い枠の見た目より、この関係のほうが重要です。

引き継ぎでは、私は三つの状態を追加で求めます。確認中、このステップでは問題なし、確認不能です。「空席を確認しています…」と「2席空いています」は違い、どちらも予約確定ではありません。この区別があると、応答が予想より遅い場合や、確認の間に売り切れた場合にも、画面が正確でいられます。

見えにくい例外もあります。日付を二回変え、一回目の空席確認が二回目より後に終わる場合です。古い応答が新しい応答を上書きすると、読みやすいけれど別の問いに対する答えが表示されます。デザインの注記では、結果が現在の選択に対応することを求め、どう実現するかは開発が決められるようにします。

動きや読み込み表示をレビューするときも、この状態の違いを見失わないようにします。目的は、遷移を忙しそうに見せることではありません。古い結果を新しい結果と受け取らせないことです。今は確認できないなら、回答を無効とするより、中立的な説明のほうが正確です。

サービスの失敗は、回答の間違いではない

予約フローで最も高くつく文言の間違いは、間違っていない回答を直すよう求めることかもしれません。リクエストの失敗には、入力の拒否、サーバーの利用不可、結果が不明という可能性があります。それぞれ、次に必要なことが違います。

「予約する」を押した後のタイムアウトを考えます。リクエストがサービスに届いていないかもしれませんし、処理は終わって応答だけ失われたかもしれません。どちらか分からないのに「予約に失敗しました」は断定しすぎです。すぐ再送しても問題ない場合も、重複する場合もあります。この不確かさについて、プロダクトとして明確に決める必要があります。

この例なら、メッセージを磨く前に、エンジニアと復帰経路を確認します。リクエストの参照番号から結果を取得できるか。再送しても安全にもとの結果を返せるか。サポートはその試行を見つけられるか。どの回答がページに残るか。これらが、状況確認、安全な再試行、参照番号を添えた問い合わせのどれが適切かを決めます。

だからといって、エラーテキストに技術の内部事情を載せる必要はありません。読む人に、ネットワーク障害の講義は不要です。必要なのは、何が分かっているかの正直な説明と、実際に使える次の手順です。サポートが使えるなら参照番号は役立ちますが、説明のないエラーコードは、本人が解釈する問題を一つ増やすだけです。

入力確認のベストプラクティスには、修正後の道筋も含まれる

OpenDesignの対応するHTMLプレビューでは、通常の入力欄、エラー、修正後の状態を比較できます。現実的な値と長いメッセージを使い、狭い画面を確認し、変えるべき具体的な要素にコメントします。その後、動くバックエンド、キーボードの流れ、スクリーンリーダーの読み上げでも、同じ一連の操作を試します。

形容詞をもう一度練るより、小さなレビューのほうが多くを明らかにすることがあります。ワークショップを4席予約する、といった具体的な作業を渡し、定員の問題に出会ってもらいます。何が起きたと思うか、次にどうするかを聞きます。先に意図を説明すると、発見したい曖昧さそのものを取り除いてしまいます。

メッセージへの感想と同じくらい、修正後に何をするかを見ます。警告を何度も読み返すなら、消えていないのかもしれません。サービスのタイムアウト後に正しいメールアドレスを変えるなら、画面が間違った場所に責任を向けているのかもしれません。フォーム全体をやり直すなら、もとの作業より復帰経路のほうが見つけにくいのかもしれません。

稼働中のサービスでは、繰り返しの送信や修正のループが、調べる場所を絞る助けになります。ただし、それだけで原因が分かるわけではありません。エラーが多いのは、説明が分かりにくい、ルールが厳しすぎる、空席がない、実装に不具合がある、のどれかかもしれません。イベントの順序と実際の行動を組み合わせ、フォームを診断するためだけに個人の回答の生データを集めないようにします。

この例を承認する前に、私は次の短い流れを確かめます。

1. 不完全な回答を入力し、いつフィードバックが出るかを見る。
2. 二つのエラーを残して送信し、要約から両方の欄に到達する。
3. 一つを修正し、関係のない値が残っていることを確認する。
4. ワークショップの日付など、ほかの条件に影響する回答を変え、新しい結果を見る。
5. サービスが利用できない状態に出会い、案内された手順をたどる。

最後に確認するのは、成功した結果です。確認画面に、修正後の日付と数量が出ているでしょうか。予約が存在するかどうか分かるでしょうか。赤い文字が消えただけでは、フォームが回復したとはいえません。

よい入力エラーメッセージは、本人が解釈しなければならないことを減らします。業界の例が役立つのは、その解釈がどこで崩れるかを明らかにするからです。回答が終わる前、修正した後、そして画面が知る以上のことを知っているように振る舞うとき。考え方を借り、自分たちの作業で試し、実際に届けられる振る舞いに合わせて言葉を選びましょう。