効果的なフォームをデザインするヒント – 要素の配置、ラベル、入力フィールド、アクションボタンの使い方 | アドビUX道場 #UXDojo

連載

エクスペリエンスデザインの基礎知識

Webサイトやアプリのユーザーは何かを達成しようとしています。その目的達成の最後の壁がフォームなのはよくあることです。フォーム入力はユーザーにとって常に最も重要な操作のひとつでした。もしもフォームが目的への最後のステップであるなら、ユーザーは迷わず素早く入力を完了できるべきです。

フォームを構成する部品

一般的なフォームは以下の5つの要素から構成されます。

フォームによっては以下のような要素が存在する場合もあります。

この記事では、構造、ラベル、フィールド、ボタン、検証について、様々な考慮事項を扱います。

1. フォームの構造

フォームはある種の会話です。そしてすべての会話がそうであるように、ユーザーとアプリとの間には論理的な関係が必要です。

必要なことだけを尋ねる

一つ一つの項目が本当に必要であることを確認しましょう。フォームに余分なフィールドを追加するたびに、コンバージョン率に影響が出ます。ユーザーに情報を求めるときは、何故それが必要で、どのようにそれを使おうとしているのかをよく考えましょう。

論理的にフォームを構成する

ユーザー視点から意味のある順番で尋ねるべきです。アプリケーションやデータベースの都合であってはなりません。例えば、名前を聞く前に住所を尋ねるのは一般的には不自然です。

関連する情報をまとめる

関連する情報はグループにします。あるトピックについていくつかの質問をして、次に進むという流れは、会話とも似ています。関連する項目をグループ分けして見出しを付けると、入力するユーザーに分かりやすくなります。下の連絡先入力フォームを比べてみてください。右側はグループごとに並べられています。

カラム数

複数カラムに入力フィールドを配置することの問題点のひとつはユーザ視点からの一貫性の欠如です。もしフォーム内でフィールドが2カラムに配置されていたら、ユーザーは縦と横を眺めなければなりません。理解に時間がかかり、完了までの労力を増やすことになるでしょう。一カラムのフォームなら、ユーザーはまっすぐ下に向かって記入していくだけです。

2. ラベル

明確に記述されたラベルはUIを使いやすくする有効な手段です。良いラベルは、ユーザーにフィールドの目的を伝え、フィールドがフォーカスされているときも役割を果たし、さらに記入後もはっきりと視認できるものです。

ラベルの配置

Matteo Penzoの2006年のラベルの配置についての記事は、ラベルがフォームの上に配置されていると完了が早くなることを示唆しています。ユーザーにできるだけ素早くフォームを見渡して欲しいなら、ラベルを上部に配置するのは良い方法です。

上部に配置する大きな利点には、大きさの異なるフォントの使用や、多言語対応の容易さもあります。一方、縦にスペースが必要になるため、長いフォームには向いていません。

左揃えのラベルの最大の欠点は、入力に時間がかかることです。理由のひとつは、ラベルとフィールドの距離が離れがちな点にあります。ラベルが短いほど入力フィールドから距離が離れます。しかし、入力の遅さは必ずしも悪いことではありません。注意が必要なデータを扱う場合、例えば運転免許番号の入力を求めるときなどは、正しく入力してもらうために、意図的にユーザーにゆっくりと入力させたくなるかもしれません。入力エラーが大きな問題になるデータに関しては、ラベルを読む時間がかかることはさほど重要ではないでしょう。左揃えのラベルにはもうひとつの欠点があります。横方向にスペースが必要なことです。これはモバイルユーザーには問題になるかもしれません。

右揃えのラベルの利点は、ラベルと入力フィールドの関係の分かりやすさです。お互いが近くにあるために関係がはっきりします。項目数が少ないフォームなら、右揃えのラベルは短時間で入力を完了させるのに適しています。欠点は読み辛さです。左側が揃っていないため読み始めの位置がずれ、読むための労力が余分に必要になります。流し読みも困難です。

プレースホルダー

ラベルを入力フィールドの外に配置する代わりに、フィールド内にプレースホルダーとして配置するとスペースを節約できます。しかし、プレースホルダーはフィールドがフォーカスされると消えて、ユーザーからは確認できなくなります。ユーザー名とパスワードを尋ねるだけの単純なフォームならプレースホルダーは機能するかもしれませんが、ラベルを置き換えるには不十分です。

フィールドをクリックするとラベルが消えるなら、ユーザーは入力した内容が求められたものだったかを、入力した後に確認することができません。これはエラーの増加につながります。もうひとつの問題は、ユーザーがプレースホルダーを事前に入力されたデータと勘違いする可能性があることです。（ニールセン・ノーマングループの視線の追跡による研究でも確認されています）

良い解決案のひとつはフローティングラベルです。デフォルトではプレースホルダーを表示しておき、フィールドがタップされてテキストが入力されたら、プレースホルダーを消して代わりにフィールド上部にラベルを表示するのです。

3. 入力フィールド

入力フィールドはユーザーがフォームに記入できるようにする部品です。必要に応じて様々なフィールドが存在します。テキスト、パスワード、ドロップダウン、チェックボックス、ラジオボタン、カレンダーなど様々です。

フィールドの数

基本ルールは「少ないほど良い」です。これは直感的に理解できるでしょう。ユーザーに求められる労力が少ないほどコンバージョン率は高くなります。ですから、可能な限りフィールドの数を減らしましょう。特に多くの情報を必要としているとき、この点は重要です。しかし、やりすぎには注意しましょう。30フィールド分の質問を5フィールドに詰め込むのは無理があります。同時に表示する入力フィールドの数は5つから7つにするのが一般的です。

オプションのフィールド

オプションの入力フィールドは避けるべきです。もし使うなら、少なくとも必須のフィールドから明確に区別できるようにしましょう。慣例としては、必須のフィールドにアスタリスク（*）を使うか、必須ではないフィールドに「オプション」のような言葉を表示します（長いフォームではこちらの方が望ましいとされています）。必須のフィールドにアスタリスクを使う場合は、フォームの最後にそれが何を意味しているのかヒントを表示しましょう。すべての人がその意味を理解するとは限らないからです。

デフォルト値の設定

大半のユーザー（例えば90%）がその値を選ぶという状況で無い限り、デフォルト値を設定するのは避けましょう。特に必須のフィールドには避けるべきです。エラーの原因になるからです。人々はオンラインのフォームに実に素早く目を通します。すべての選択肢を吟味するという仮定は捨てましょう。既に値が入力されているフィールドはスキップされるかもしれません。

しかし、少し賢いやり方をするなら話は別です。つまり、既知のユーザー情報に応じて値を設定するのです。これにより、より早くより正確な入力が可能になります。例えば、位置情報から国名を事前に選ぶことができるでしょう。しかし、注意は必要です。ユーザーは事前に選ばれているフィールドはそのままにする傾向があるのです。

マスク

マスクは、入力テキストの書式設定を支援するテクニックです。ユーザーがフィールドにフォーカスするとマスクが現れ、入力に従って自動的にテキストの書式を設定します。これにより、ユーザーはデータの入力に集中でき、同時に間違いに気づきやすくなります。下の例では、電話番号とカード番号の入力時に、自動的に括弧やハイフンが適用されています。このようにしてユーザーの時間と労力を削減できます。

キーボードのみでの操作への配慮（デスクトップのみ）

ユーザーはキーボードだけですべてのフィールドへのフォーカス移動と編集ができるべきです。キーボード操作に関する要件は、W3Cのデザインパターンのガイドラインに詳細に記述されています。

入力フィールドへの自動フォーカス（デスクトップのみ）

自動的にフィールドにフォーカスさせると、ユーザーへの通知となり、そのまま直ぐに入力を開始できます。フォーカスされたフィールドを示すため、明確な視覚的な合図をユーザーに送りましょう。色を変えたらり、矢印を点滅させたり、なんでも構いません。アマゾンの登録フォームはその良い例です。

入力にあわせてキーボードを変える（モバイルのみ）

モバイルユーザーは入力するテキストに応じて適切なキーボードが表示されることを期待しています。一部のタスクだけでなく、アプリ全体を通してこの振る舞いを提供しましょう。

入力を削減する（オートコンプリート）

特にモバイル環境においては、不要な入力を防ぐことが、ユーザー体験の向上とエラーの削減につながります。自動補完を使えば、入力を大幅に減らせます。例えば住所を入力するとき、位置情報を使った自動補完機能を使えば、通常の入力フィールドよりも少ないキー操作で入力が完了します。

4. アクションボタン

アクションボタンは、クリックされると何らかの動作を呼び出します。例えばフォームの送信に使われます。

一次的なアクションと二次的なアクション

一次的なアクションと二次的なアクションの視覚的な差別化がされていないと、ユーザーが間違いを起こしやすくなります。二次的なアクションボタンの視覚的な存在感を下げることでエラーの可能性を減らし、人々を正しい方向へ導くことができます。

ボタンの位置

複雑なフォームには「戻る」ボタンが必要なものです。もしそんなボタンが入力フィールドの真下に配置されていたら、ユーザーは誤ってクリックしてしまうかもしれません。「戻る」ボタンは二次的なアクションですから、少し使いにくい場所におきましょう。（下の画像の右側は入力フィールドから少し離れた位置に「戻る」ボタンがあります）

名前の付け方

「送信」のような一般的な言葉を使うことは避けたほうが賢明です。さもないと、フォームの目的が一般的なものに映るでしょう。より具体的に、「アカウント作成」や「注文を確定」のような、ボタンがクリックされると行われるアクションを示す言葉を使いましょう。

見た目

アクションボタンはボタンらしく見えるようにします。クリックやタップ操作ができることを示しましょう。

視覚的なフィードバック

ユーザーがクリックした後には処理が実行中であることを明確に示すボタンのデザインを考えましょう。フィードバックを提供することで、ユーザーの二度押しを避けることもできます。

5. 検証

入力間違いの検証は、データ入力とは不可分の存在です（ユーザーはそれほど間違えやすいものです）。もちろん間違えの起きやすい状況は最小化されるべきですが、検証が不要になることはありません。従って、重要な課題は、エラー状態からの回復手段をユーザーに伝える方法です。

フィールドごとの検証

ユーザーにとってフォームを埋めていくのは快適な作業ではありません。特に、その結果がエラーの通知に終わったならばなおさらです。長いフォームを記入して、「送信」ボタンを押したら、いくつもエラーメッセージを受け取った状況を想像してみてください。エラーの内容が不明確で、どの入力が間違っているのかも分からない場合は、更にひどい気分になるでしょう。

検証は、ユーザーがデータを入力したらできるだけ早くテキストの正しさを伝えるべきです。これは、第一に守るべきフォーム検証のルールです。リアルタイムでフィールドの入力を検証すれば、即座にデータの正しさをユーザーに伝えられます。この方法なら、「送信」ボタンを押してからエラーを見るまで待つこともなく、エラーをその場で修正できます。

しかし、キー入力ごとに検証するのは避けるべきです。大抵の場合、答えを入力し終わるまでは、入力データを検証する意味はありません。入力途中で検証すれば、ユーザーを急かすことにもなります。

一方、入力が終わってから検証する場合、ユーザーがエラーを修正しても、それを直ぐにユーザーに伝えられません。

Mihael Konjevićは彼の記事“Inline Validation in Forms: Designing the Experience”で、異なる検証方針の組み合わせにより、それぞれの欠点を補おうとしています。「報酬は先に、罰は後に」です。

データの保護

かつてJef Raskinは「システムはユーザーの入力を神聖なものとして扱うべきである」と言いました。これはまさにフォームに当てはまります。フォームを記入し始めてからうっかりページを再読み込みしてしまったとき、フィールド内のデータが残っていたら素晴らしいでしょう。Garlic.jsのようなツールは、フォームを送信するまで入力をローカルに保持するのに使えます。こうした対策をとれば、ユーザーが誤ってタブを閉じてしまって重要なデータを失うこともなくなるでしょう。

終わりに

ユーザーはフォーム記入に気乗りがしないかもしれません。フォーム入力はできるだけ簡単なプロセスになるよう心がけましょう。簡単な変更が大きくユーザビリティを改善することがあります。ユーザビリティテストはデザインには欠かせません。できるだけ頻繁に、ごく少数のユーザーでも、同僚にお願いするのでも構いませんから、プロトタイプを試すよう頼んでみれば、フォームの使いやすさに見当をつけることができるでしょう。

この記事はDesigning More Efficient Forms: Structure, Inputs, Labels And Actions（著者:Nick Babich）の抄訳です