はじめに

こんにちは。sudaです。
去年の10月から、iOSアプリエンジニアとして、スマホアプリ開発に携わっています。
スマホアプリ開発にあたっては、アーキテクチャ設計や生体認証周りの実装、アプリを一度バックグラウンドに遷移させて再度戻ってきた時の挙動など、色々と悩み、考えることがたくさんありました。
特に、僕たちの開発チームがたくさん議論したのは「ユーザにとってより良いUXは何か」だったように思います。今回は、その中でも、考えては実装して…を繰り返した「バリデーションチェックのUX」について、試行錯誤の過程を振り返りながら、書いていこうと思います。
（動画をつけて説明したかったのに、うまいこと載せられなかった、、、
悔しい。。。）

バリデーションチェックを考える　
〜より良いUXを目指して〜

Ver1　ボタン押下時にチェック

開発当初、下のように、ボタンを押した時に入力値をチェックして、チェックに引っかかったら、エラーを表示する実装をしていました。
これは、昨今の登録フォームにおける、一般的な挙動かなあと思います。

ところが、ある日、僕たちの開発チームのUXデザイナーから、こんな意見が出ました。
「ボタンを押して初めて、入力値の間違いに気がつくのでは、タイミングがちょっと遅いんじゃない？」
上の画像のように、入力項目が一つしかない時は、ボタン押下時にチェックしても、そこまで遅くはないかもしれません。でも、入力項目がたくさんある場合は、どうでしょうか？ボタンを押すより前に、自分の入力した値の間違いに気がつける方が嬉しいですよね。
ということで、チェックタイミングを改善してみよう、ということになりました。

Ver2ボタンを押す前にチェック

ボタンを押すより前に、バリデーションチェックをする方法として、まず、
「ユーザが値を入力している最中に値をチェックして、エラーを表示する」
という方法が考えられると思います。当時、iOSアプリエンジニア見習いの僕は、「全部リアルタイムチェックにすれば良いのか！」と思っていました。でも、この方法だけだと、UX的によろしくない状況が発生するということに気が付きました。下の画像を見てください。

ユーザが携帯電話番号を入力するシーンを考えます。携帯電話番号は11桁なので、11桁の数字以外はバリデーションチェックで弾かれます。 この時、リアルタイムバリデーションチェックしかないと、正しい値を入力しようとしている途中に、エラーが表示されることになってしまいます。 これでは、エラー表示がユーザにとって相当うっとうしい状況となってしまいます。 なので、ボタンを押す前のバリデーションチェックを実現するためには、以下の2つのタイミングのチェックを使い分ける必要があります。

1. ユーザが入力しているタイミング
   ＊文字種チェック
   ＊桁数上限チェック
   ＊最大値チェック
   etc…

2. ユーザが入力を終えてキーボードを閉じたタイミング
   （テキストフィールドからフォーカスアウトした時）
   ＊桁数下限チェック
   ＊最小値チェック
   etc…

１、２のタイミングの使い分けは、チェックしようとしている条件の特性によって、考える必要があります。
例えば、間違った文字種を入力している場合は、その後の入力文字が正しくても、全体として正しい値になることはありません。なので、１のタイミング、すなわち、間違った文字が入力された直後にエラーを表示する方が、ユーザに早く間違いを知らせることができるので、親切な設計になります。
一方、上で示したように、携帯電話番号が11桁に届いているかをチェックする場合は、正しい入力中にエラーを出すのを避けるため、２のタイミング、すなわち、キーボードを閉じたタイミングでエラー表示を出した方が、より良いUXになると思います。

Ver3　エラー表示のタイミングを、より良く改善してみる

Ver2の内容は割としっくりきたので、この方針でアプリ開発を進めていたのですが、完成したアプリをチーム内で触っているうちに、こんな意見が出ました。
「初回入力時は、入力中にエラーが出るのは煩わしいので、とりあえず好きに入力させてほしい。」
僕は、個人的には、リアルタイムチェックが常に動いていることに違和感を感じなかったのですが、なるほど、まずは好きに入力させてくれ、という人もいるのだとわかりました。
この意見を契機に、エラー表示について、初回入力かどうかという、今までになかった新しい切り口が生まれました。この観点に立つと、バリデーションチェックのタイミングは、以下のように整理できました。

• 初回入力時
  とりあえずユーザの入力を信じて、途中の入力が間違っていても、エラーがあることを知らせない。ユーザがキーボードを閉じたタイミング（テキストフィールドからフォーカスアウトしたタイミング）を以って、入力が完了したとみなし、エラーがあれが表示してユーザに知らせる。

• 2回目以降の入力

  • エラーのなかったテキストフィールドについては、初回入力時と同様、ユーザがキーボードを閉じたタイミングで、エラーの有無を知らせる。

  • エラーのあったテキストフィールドについては、1文字1文字の編集で、リアルタイムにエラーの表示/非表示を更新する。

この整理によって、チェックしようとしている条件の特性に依らず、「ユーザがエラーを直そうとしている時だけリアルタイムでチェックする」という、非常にシンプルな設計にすることができました。これによって、「この条件のチェックはいつ実施するべきなんだっけ？」ということを考えなくて良くなり、実装も非常にすっきりしたものになりました。また、実際に、この方針で実装したアプリを触ったところ、個人的には、Ver2のアプリよりも触り心地が良く感じました。

最後に

今回は、アプリ開発時に設計をすごく悩んだ、バリデーションチェックに焦点を当てて、開発の経緯を振り返ってみました。
入力項目に関するUXは、考えるべきことが多く、設計するのが結構大変でしたが、個人的には、Ver3が自分の中での一つの解になりました。
これを読んでくれた人が、入力項目のチェック仕様を考える際に、何か参考にできる部分があったら嬉しいです。