前回は「入力フォームにおけるUI設計の基本とUXを改善するためのデザインルールとは？」というタイトルで投稿させていただきましたが、その中でご紹介したルールの一つに「入力が完了した項目からバリデーションチェックを行う」というものがありました。
実はこのリアルタイムで行うバリデーションチェック（エラーチェック）を実装する際には、たった一つですが、確実に意識していただきたいポイントがあります。
このポイントを意識できているかどうかで、フォーム入力におけるUXに大きく影響を与えてしまうため、そのポイントを日々の業務でUIコンサルティングを行うことが多い筆者目線で解説したいと思います。
エラーを表示するタイミングこそが重要！
リアルタイムで行うバリデーションチェック（エラーチェック）は、本当にリアルタイムに異常なし／異常ありといった状態であることをユーザーに伝える必要があるのでしょうか。
実はこの"リアルタイム"というワードに惑わされてしまった結果の実装により、フォームにおけるUXの悪い事例が作り出されてしまうのです。
そこで、まずはリアルタイムで行うバリデーションチェックの誤った実装と正しい実装方法をケーススタディとしてご紹介しましょう。
ケーススタディ１｜誤った実装ケース
"リアルタイム"という言葉に惑わされてしまい、入力と同時にバリデーションチェックを実行してしまうケースが見受けられますが、これはユーザーに対してフォーム入力時にストレスを与えてしまいます。
そして、これこそがバリデーションチェック（エラーチェック）に潜む罠と言えます。
ケーススタディ２｜正しい実装ケース
リアルタイムでバリデーションチェックを行う上で、ユーザーにストレスを与えないためには、入力完了後にエラーメッセージを表示させるという実装が最適です。
ケーススタディ１の問題点は、入力している途中／入力フォームにカーソルが当たっている途中にエラーメッセージが表示されてしまうことによって、フォーム入力時にストレスを与えることにあります。
このユーザーストレスを解消できる入力フォームこそがフォームにおけるUXを高める一つの要因となることでしょう。
ただし、第三の選択肢もある
ここまで、入力フォームのバリデーションチェックにおける誤った／正しい実装ケースをご紹介してきましたが、実は「入力完了後にエラーメッセージを表示させるという正しい実装ケース」にも現場的な課題が存在しています。
これは私がUIコンサルティングの現場で、
- 要件定義の段階で、誤った／正しい実装ケースを伝えることができていないと感じた場合
- 機能実装までサポートすることができず、ソースコード納品となる場合
という状況になってしまった場合に使用しているのですが、実は便利（UXを損なわないもの）であると考えています。
上記のようなケースに該当する場合には、あくまでリアルタイムでバリデーションチェックを行うことがベストプラクティスであることを伝えた上で、第三の選択肢として、この処理を実装しないUIを提案しています。
その具体例は以下となります。
このUIはベストプラクティスではありませんが、間違ったリアルタイムなバリデーションチェックによるユーザーストレスを除外しながら、現場のニーズにも答えることができると考えています。
ユーザー目線は大切！ただし最適解は現場にある
UIコンサルティングをしていると、これまで説明したようなケースに遭遇することが多いのですが、ユーザー目線を徹底するだけでなく（ユーザー目線は間違いなく大切なのですが）、クライアントの現場意見やニーズを考慮した上でご提案した内容こそが最適解であると考えています。
UIコンサルティングでは、クライアントが実現したいと考えるプロダクトやサービスのパフォーマンスを最大化するための支援となりますが、ベストな提案と共に、ビジネスにおける成果を最大化させることが常に求められます。
