質問: フォームエラーメッセージをデザインするためのベストプラクティスは何ですか? フォームデザインに関する多くの研究を見てきましたが、これまでのところ、エラーメッセージデザインのベストプラクティスに関する研究はありません。唯一のアドバイスは、各エラーは修正を目的とする無効なフォームフィールドに明確に関連付けられるべきだということです。これに関する調査はありましたか?私が取り組んでいるいくつかの特定の問題があり、洞察やリソースをいただければ幸いです。エラーメッセージの場所ライブフォーム検証がある場合、フォーム要素に関連してエラー(または成功)メッセージはどこに表示されますか?いくつかのオプション:入力の右側に download bmml source – balsamiq mockups で作成されたワイヤーフレームラベルの右側に bmmlソースをダウンロード ラベルの上 bmmlソースをダウンロード ラベルの下 bmmlソースをダウンロード 入力の下 bmmlソースをダウンロード 位置についても考慮する必要がある厄介な問題がいくつかあります。 ラジオまたはチェックボックスグループのエラーはどのように表示されますか? エラーメッセージの幅はどのくらいですか? エラーメッセージは複数行ですか? エラーメッセージの可視性場所に加えて、エラーメッセージの可視性がユーザビリティにどのように影響するかにも興味があります。それは重要ですか、それとも厳密に審美的な決定ですか?次の3つのオプションを検討してください。 bmmlソースをダウンロード 編集:これまでの回答のいくつか、およびいくつかの興味深い例では、アクセシビリティに関していくつかの優れた点がありました。ただし、可能であれば、実際の研究のデータを実際に確認してください。また、これまでのところ、私が上記に挙げた2つの質問に答えた答えはありません。 エラーは入力とラベルに関連してどこにあるべきですか? エラーメッセージ自体のデザインと可視性は、そのユーザビリティにどのように影響しますか? フォームのアクセシビリティに関して、ライブ検証とサーバー側検証(ページの再読み込みが必要になる)の2つの潜在的に競合する使用例があるように思えます。ページがリロードされ、ユーザーがフォームの上部から再び開始する場合、特にアクセシビリティの観点からは、エラーの概要が理にかなっています。ただし、ライブ検証の場合、フォームデザインとアクセシビリティの両方の目的で、上部のエラー概要はあまり意味がありません。ユーザーが実際の検証でフォームを実際にどのように使用するかを検討します。検証は、ぼかしイベントで行われます。通常、のフォーカスは、一番上のリストではなく、次のフォーム要素にあります。スクリーンリーダーを理解しているので、フォームの先頭に戻ってエラーリストを読む必要はありません。スクリーンリーダーを使用していないユーザーの場合、上部のエラーリストによってフォーム全体が押し下げられ、エラーがフォームフィールドの近くの縦方向のスペースも占めることになります。長い形式では、エラーの概要が表示されない可能性があるため、これはユーザビリティの問題です。ログインのようにフィールドごとのエラーがある短い形式では、エラーの要約は過剰に見えます。すべてのフォームで、インターフェースが押し下げられ、ユーザーエクスペリエンスが低下します。ライブ検証の場合、フォームエラーにアクセスできるようにしたい場合は、 ariaライブリージョン を使用することをお勧めします。
回答: 検証メッセージを配置するのに最適な場所がどこにあるかについての調査はまだ行っていません。ただし、実用的な観点からは、ユーザーインターフェイスのガイドラインは十分に近いと思います。 microsoftは、ガイドラインの情報について、ユーザビリティラボで多くの直接調査を行ったことがよく知られています。マイクロソフトがuiの貧弱な慣習を採用することを望んでいるのと同じように、一般にそれらの慣行はユーザーインターフェイス設計ガイドラインに従っていませんでした:)microsoftの windowsユーザーエクスペリエンスインタラクションガイドライン は、ラベルの左側にあるアスタリスクとメッセージ付きのツールチップ: download bmml source – balsamiq mockups で作成されたワイヤーフレームガイドラインは、以下にまとめたいくつかの洞察に満ちたポイントも作成します。 ほとんどのコントロールがオプションの場合は、何も指定しないでください(必要な入力がない場合はエラーメッセージを処理します。このアプローチにより、煩雑さが軽減されます)。 ほとんどのコントロールで入力が必要な場合は、ラベルの後に「(optional)」を付けてオプションの入力を示します。 すべてのコントロールに入力が必要な場合は、コンテンツ領域の上部に[すべての入力が必要]を配置します。 入力を早期に検証し、入力ポイントの近くにエラーを表示します。 すぐに検出できるユーザー入力エラーのポップアップバルーンを使用します。 *バルーンは、インプレースメッセージを表示するために必要な利用可能な画面スペースや動的レイアウトを必要としません。 一度に1つのバルーンのみを表示します。 遅延エラー検出にインプレースエラーを使用します(たとえば、フォームを送信した後)。 興味深いことに、このトピックの appleヒューマンインターフェイスガイドライン にはそれほど詳細はありませんが、以下は私が見つけた関連ポイントの要約です。 入力を早期に検証します キーを押すたびに入力を検証しないでください。検証を頻繁に行うのは面倒です。 繰り返しになりますが、これらは「エラーメッセージの設計のベストプラクティスに関する研究」ではないことに気づきましたが、これらのガイドラインの形成について調査が行われたことは確かであり、実用的なツールとして、このトピックの参照として最適です。