1. 各々の入力欄に、常に見えて分かりやすいラベルを付けよ

記入する前の入力欄にだけ、フォームのラベルを表示するのがWebデザインの主流になっています。これはユーザネームやパスワードなどを入力する際にはシンプルで使い勝手がいいのですが、それ以上に長い文字列になると少々勝手が悪くなります。

そのため余白があるのであれば、ラベルを表示すべきです

特に、長いフォームの場合では、ユーザは入力したものを見直すでしょう。どのラベルが入力欄と合致するのか分からなければ、間違いがないよう見直すことなどできるはずがありません。

改善前:入力欄中にラベルが記入してあります。今は見やすいかもしれません。
しかしフォームに入力するとラベルが見えなくなってしまい、間違いを見つけにくくなってしまいます。

改善後:それぞれの入力欄に、クリアでいつでも見えるラベルを付けましょう。

2. 十分な大きさのフォントを使用せよ

読みやすいサイズのフォントを使いましょう。本文には、少なくとも14ピクセルのフォントを使うことを推奨します。16ピクセルならまずどんなフォントでも問題ないでしょう。フォントのサイズは、モバイルかそれ以外のコンテキストなのかにもよりますし、他にページ上にどんなものが表示されるかにも関係してきます。迷った時は大きめに設定しておけば間違いありません。

利点としては、入力フォントのサイズを16ピクセルに設定しておけば、画面をタッチした時にiOSを使っている場合でも、ズームする必要がなくなります。単純にズームする必要がないからです。

改善前:小さい文字とラベルは読みにくくなります。
改善後:14ピクセルのフォントサイズを使いましょう。

3.タッチ可能なスペースを確保せよ

ここ最近、タッチパネル式のデバイスで入力フォームを使う人が増えてきました。Appleは最低でも44px × 44pxの大きさのボタンを推奨しています。これは指のサイズにほぼ一致するからです。この推奨値は理にかなっているでしょう。とはいえ、厳密に44ピクセルサイズで設定すると、大抵のWebアプリにおける入力フォーム上では、大きすぎる入力欄で画面がいっぱいになってしまうでしょう。私は32ピクセル から40ピクセルぐらいの高さのサイズをお勧めします。

Bootstrap 3の入力フォームのデフォルトサイズは32ピクセルの高さです。これはいい見本となるサイズでしょう。入力フォームはタップしやすい大きさを確保すべきです。

改善前:狭い入力欄はタップしづらくなります。
改善後:タップ可能なスペースを確保しましょう。

4.入力フォームのサイズは、入力される文字数によって設定せよ

入力する文字数に応じて、フォームのサイズを設定すれば、読みやすくなります。

例えば郵便番号の入力欄を画面の幅いっぱいに取る必要はありません。（ベルギーなら4桁、オランダなら（確か）6桁というふうに）郵便番号の文字数を考慮して、それに応じた入力フォームの大きさを設定すべきです。もっとも幅を取る値はMM0000でしょうから、フォールバックフォントと同じように、デザインフォントを使っても入力フォームにはまるでしょう。

また、Linuxにおけるサンセリフ体のデフォルト表示は、一般的に幅が広いということを覚えておきましょう。そのため、サイトをデザインする際に明示的に圧縮フォントを指定していたとしても、テスト時にVerdanaといった幅の広いフォントを使ってデザインを確認しておくことは、理にかなっています。Webでは、最終的にどのような画面をユーザが目にするのかなんて、デザインする側は分かりませんからね。

改善前: 全て同じ幅で分かりづらい。
改善後: 入力欄の幅を、入力で使う分の文字幅に合わせてある。

5. チェックボックスやラジオボタンをカスタマイズするなかれ

Webサイトを巡っていると、インタラクションデザインという意味で壊れてしまった、きれいなラジオボタンやチェックボックスがあるサイトによく遭遇します。ラジオボタンやチェックボックスは、以前からJavaScriptライブラリを使ってカスタマイズされてきました。最近では単にSVGやCSSを使えば、カスタマイズが可能です。

しかし、入力欄の見え方をカスタマイズすると、大抵、キーボード操作が難しくなります。私はカスタマイズされたチェックボックスやラジオボタンをテストしてきましたが、そのうち90パーセントのフォームには、focusスタイルがなく、キーボードで操作するのが困難でした。

私も他の人たちと同じくらい、見栄えのよいフォームやカッコいい SVGアニメーション が大好きです。しかし、カスタマイズをすることは、ユーザにとって何の利益にもなりません。それどころか実際はユーザに不利益を及ぼしているのです。

私が不利益だと言っているのは、つまり、単に表面的な理由でカスタマイズされたチェックボックスやラジオボタンのことです。

Select2 やDatepickerのようなウィジェットは、デフォルトのブラウザ上で、フォーム要素だけでは提供できない価値をフォームに加えることができます。

改善前: 不明確だったりカスタマイズが不十分だったりするフォーム要素は分かりづらい。
改善後: ブラウザが提供しているデフォルトのフォーム要素を利用。

6. 一般的なエラーメッセージと、個々の入力欄に特有なエラーメッセージの両方を表示せよ

一般的なエラーメッセージ、そして個々の入力欄に特有なエラーメッセージの両方をユーザ向けに表示するというのは、よい考え方です。ユーザが不備のあるフォームデータを送信した場合、ユーザは同じページにとどまることになります。しかし、エラーがウィンドウに表示されないとしたら、ユーザは何が起きたのかが分かりません。

エラーメッセージをフォームの上に表示するようにしましょう（デスクトップ版とモバイル版の両方で、ウィンドウ内に表示されるかどうかを確認してください）。それと同時に、入力したデータのどこが悪かったのかをユーザに示すため、入力欄に特有なエラー内容も表示してください。

改善前: 入力内容に不備があるが、ウィンドウ上でエラー内容が見えない。
改善後: フォームの上かつインラインでエラー内容を表示。

7. 何がオプションで何が必須かを明確にせよ

この戒律は当たり前のことに見えるかもしれませんが、どの入力欄がオプションで、どの入力欄が必須なのかが明確になっていないケースがよく見られます。

ラベルの隣にアスタリスク（*）をつけることは、両者を区別する方法として極めてよい方法でしょう。私は”必須項目”と表示するHTML要素にアスタリスクを入れ込んでいます。そうすることで、サイトを見ている人たちにとって分かりやすい表示にしているのです。

また、フォームのコンテキストが許す範囲内で、必須項目とオプション項目をグループでまとめるのも分かりやすくなるでしょう。

改善前: どの項目が必須なのか不明確。
改善後: どの項目が必須なのか示されている。

8. 必要となるまでは、不必要なものを表示するなかれ

よくあることですが、ある部分のフォームに入力した内容が、別の部分のフォームに入力する内容と同じであるケースがあります。例えば、eコマースサイトにて、請求書の住所が商品の送付先の住所と同じになるというようなケースです。

この場合、ユーザの方で請求書と商品の送付先は別だと指定しない限り、送付先住所の入力欄は全て非表示にしておくのがよいでしょう。

また、1ページに大量の入力項目を表示するのは避けましょう。入力項目を論理的なグループに分類し、必要に応じてフォームを複数ステップに分けるなどの工夫が必要です。入力完了まで、あと何項目残っているかも分かりやすく表示しましょう。

改善前:フォーム入力が好きな人はいません。項目が多いフォームは、特に嫌われます。
改善後:ユーザが入力する必要のない項目は非表示にしましょう。

9. ユーザの入力項目は最小限にせよ

不要な情報をユーザに要求すべきではありません。フォームにデータを入力することは、（大半の人にとって）面倒で退屈な作業です。

必要のない項目は載せず、免責条項のリンクページには入力データの使用目的を見やすく明記しましょう。

改善前:フォーム入力が好きな人はいません。項目が多いフォームは、特に嫌われます。
改善後:フォームの改良に努め、不要な項目は非表示にしましょう。

10. 入力形式を明確にせよ

データの入力形式はさまざまです。電話番号は”+”をつけて、国コードとエリアコードを書く形式もあれば、それらを一切書かない形式もあります。そのうち、あなたが期待する入力形式はどれでしょう？

入力形式を統一する最良の方法は、ユーザには形式を問わず自由に入力をさせて、そのデータをシステム側で共通フォーマットに変換することです。例えば国の入力欄にベルギー、電話番号の入力欄に0495 20 12 12が入力された場合、システム側で、その電話番号は携帯電話のものだと判別して、”携帯”という種別で保存するのです。

しかし、ユーザに対して入力形式を指定しないやり方が、必ずしも現実的だとは限りません。次善策は、単純に入力欄の下に説明書きとして、期待する入力形式を記載する方法です。例えば、「電話番号は+XX 000 000 000の形式で入力してください（XXは国コード）」のように書きます。

改善前:データの入力形式が不明確です。
改善後:入力形式を明確にしましょう。

おまけ ユーザの入力が完了してからデータを検証せよ

最近よく目にするのが、入力欄を離れるたびにデータの検証が行われるフォームです。この動きは、最新のJavaScript MVMフレームワークの動作に関連しています。

最終的にユーザが送信ボタンを押す前に、入力内容を検証するのは悪いことではありません。しかし、ユーザにも誤りを修正する時間を与えるべきです。というのも、まだ修正すべき項目があると認識しているにもかかわらず、エラーを表示されてしまうケースがあまりにも多いのです。さらにひどいと、入力している最中にも検証処理が行われます。確かに”johan@”はメールアドレスとして有効ではありませんが、今まさに正しいアドレスを入力しているユーザに対し、エラーメッセージを突き付ける必要があるでしょうか？

常識的に考えて、ユーザが次の項目の入力を始めてから検証をすべきです。