モバイルフォームデザインのベストプラクティス

（この記事はアドビが後援しています。）フォームはすべてのモバイルインタラクションの要です。 それは人と彼らが探しているものの間に立っています。 私たちは毎日、重要なオンライン活動にフォームを使用しています。 前回チケットを購入したとき、ホテルの部屋を予約したとき、またはオンラインで購入したときのことを思い出してください。おそらく、これらのやり取りには、フォームに記入する手順が含まれていました。

フォームは目的を達成するための手段にすぎません。 ユーザーは、混乱することなく迅速にそれらを完了することができるはずです。 この記事では、効果的なフォームをデザインするのに役立つ実用的なテクニックを学びます。

効果的なフォームを作るもの

すべてのフォームの主な目標は完了です。 2つの要因が完了率に大きな影響を及ぼします。

• 複雑さの認識
  ユーザーが新しいフォームを表示したときに最初に行うことは、フォームに入力するのに必要な時間を見積もることです。 ユーザーはフォームをスキャンしてこれを行います。 知覚は、推定の過程で重要な役割を果たします。 フォームの外観が複雑になるほど、ユーザーはプロセスを放棄する可能性が高くなります。
• インタラクションコスト
  インタラクションコストは、ユーザーが目標を達成するためにインターフェースと対話するために費やした、認知的および物理的な努力の合計です。 インタラクションコストは、フォームのユーザビリティと直接関係しています。 ユーザーがフォームを完成させるために多くの努力をしなければならないほど、フォームの使用可能性は低くなります。 高いインタラクションコストは、入力が難しいデータ、一部の質問の意味を理解できないこと、またはエラーメッセージに関する混乱の結果である可能性があります。

フォームのコンポーネント

一般的なフォームには、次の5つのコンポーネントがあります。

• 入力フィールド
  これらには、テキストフィールド、パスワードフィールド、チェックボックス、ラジオボタン、スライダー、およびユーザー入力用に設計されたその他のフィールドが含まれます。
• フィールドラベル
  これらは、対応する入力フィールドの意味をユーザーに通知します。
• 構造
  これには、フィールドの順序、ページでのフォームの外観、および異なるフィールド間の論理接続が含まれます。
• アクションボタン
  フォームには、少なくとも1つの行動の呼びかけ（データ送信をトリガーするボタン）があります。
• フィードバック
  フィードバックは、操作の結果についてユーザーに通知します。 フィードバックは、肯定的（たとえば、フォームが正常に送信されたことを示す）または否定的（「入力した番号が正しくない」など）の場合があります。

この記事では、構造、入力フィールド、ラベル、アクションボタン、および検証に関連する多くの側面について説明します。 この記事で言及されているほとんどのポイントには、視覚的な例があります。 このような例はすべて、AdobeXDを使用して作成されています。

入力フィールド

フォームデザインに関して、デザイナーができる最も重要なことは、タイピングの必要性を最小限に抑えることです。 入力作業を減らすことが不可欠です。 設計者は、フォームフィールドの設計に焦点を当てることでこの目標を達成できます。

フィールドの総数を最小限に抑える

ユーザーに入力を求めるすべてのフィールドには、ある程度の努力が必要です。 フォームに記入するためにより多くの労力が必要になるほど、ユーザーがフォームに記入する可能性は低くなります。 そのため、フォームデザインの基本的なルールは短い方が優れています。つまり、不要なフィールドをすべて削除してください。

Baymard Instituteはチェックアウトフォームを分析し、チェックアウトプロセスが長すぎるか複雑すぎることが、チェックアウト中に放棄される最大の理由の1つであることを発見しました。 この調査では、平均的なチェックアウトには約15のフォームフィールドが含まれていることがわかりました。 ほとんどのオンラインサービスでは、デフォルトで表示されるフィールドの数を20〜60％減らすことができます。

多くの設計者は、「少ないほど多い」というルールに精通しています。 それでも、ユーザーに関するより多くのデータを収集するために、追加の質問をします。 最初のサインアップ中にユーザーに関するより多くのデータを収集したくなるかもしれませんが、その誘惑には抵抗してください。 このように考えてください。フォームにフィールドを追加するたびに、見込みユーザーを失う可能性が高くなります。 新しいユーザーを失う価値のある分野から得た情報はありますか？ ユーザーの連絡先情報を収集している限り、いつでも追加データのリクエストをフォローアップできることを忘れないでください。

すべてのオプションフィールドを明確に区別する

オプションのフィールドを最適化する前に、フォームにそれらを本当に含める必要があるかどうかを自問してください。 必要な情報ではなく、本当に必要な情報について考えてください。 理想的には、フォームのオプションフィールドの数はゼロである必要があります。

ブレーンストーミングセッションの後でも、フォームにいくつかのオプションの質問を含めたい場合は、それらのフィールドがオプションであることをユーザーに明確にします。

• 必須フィールドの代わりにオプションフィールドをマークします。
  質問をできるだけ少なくすると、フォームのフィールドの大部分が必須になります。 したがって、少数派のフィールドのみにマークを付けます。 たとえば、6つのフィールドのうち5つが必須である場合、1つのフィールドのみをオプションとしてマークすることは理にかなっています。
• 「オプション」ラベルを使用して、オプションのフィールドを示します。
  「オプション」を意味するアスタリスク（ * ）の使用は避けてください。 すべてのユーザーがアスタリスクをオプションの情報に関連付けるわけではなく、一部のユーザーはその意味に混乱します（アスタリスクは必須フィールドを示すためによく使用されます）。

したがって、フィールドのサイズ

可能であれば、フィールド長をアフォーダンスとして使用します。 入力フィールドの長さは、フィールドで期待される情報の量に比例する必要があります。 フィールドのサイズは視覚的な制約として機能します。ユーザーは、フィールドを見るだけで、入力されると予想されるテキストの量を知ることができます。 通常、市外局番や番地などのフィールドは、番地のフィールドよりも短くする必要があります。

フィールドフォーカスを提供する

フォームの最初の入力フィールドにオートフォーカスします。 フィールドのオートフォーカスは、ユーザーに指示と開始点を提供するため、ユーザーはフォームへの入力をすばやく開始できます。 そうすることで、インタラクションコストを削減し、ユーザーに不要なタップを1回節約します。

アクティブな入力フィールドを目立たせてフォーカスを合わせます。 フィールドフォーカス自体は非常に明確である必要があります—ユーザーはフォーカスがどこにあるかを一目で理解できる必要があります。 アクセントのある境界線の色またはボックスのフェードインである可能性があります。

ユーザーにメールアドレスを繰り返すように依頼しないでください

電子メールアドレスの追加フィールドが製品開発者の間で非常に人気がある理由は明らかです。すべての企業は、ハードバウンス（無効な電子メールアドレスによって引き起こされる配信不能）のリスクを最小限に抑えたいと考えています。 残念ながら、このアプローチに従うことは、有効なアドレスを取得することを保証するものではありません。 ユーザーは、住所をあるフィールドから別のフィールドにコピーして貼り付けることがよくあります。

「パスワードの表示」オプションを提供する

パスワード入力フィールドの複製は、製品設計者の間でよくあるもう1つの間違いです。 設計者は、ユーザーがパスワードを誤って入力するのを防ぐことができると信じているため、このアプローチに従います。 実際には、パスワードの2番目のフィールドは、対話コストを増加させるだけでなく、ユーザーが間違いなく続行することを保証するものでもありません。 ユーザーはフィールドに入力した内容が表示されないため、同じ間違いを2回（両方のフィールドで）行う可能性があり、パスワードを使用してログインしようとすると問題が発生します。 ヤコブ・ニールセンが要約したように：

ユーザーがパスワードを入力すると使い勝手が悪くなり、ユーザーが受け取るフィードバックは箇条書きの列だけです。 通常、パスワードをマスクしてもセキュリティは向上しませんが、ログインに失敗するため、ビジネスにコストがかかります。

パスワードフィールドを複製する代わりに、ユーザーが作成するために選択したパスワードを表示できるオプションを提供します。 クリックするとパスワードのマスクを解除するア​​イコンまたはチェックボックスがあります。 パスワードプレビューは、ユーザーが送信する前にデータを確認する機会になる可能性があります。

データフィールドをスライスしないでください

氏名、電話番号、生年月日を尋ねるときは、フィールドをスライスしないでください。 スライスされたフィールドは、次のフィールドに移動するためにユーザーに追加のタップを強制します。 何らかの書式設定（電話番号や生年月日など）が必要なフィールドの場合は、プレースホルダーとして明確な書式設定ルールと組み合わせた単一のフィールドを用意することもお勧めします。

ドロップダウンメニューを避ける

Luke Wroblewskiは、ドロップダウンは最後の手段のUIであるべきだと有名に言いました。 ドロップダウンは、要素が折りたたまれていると小さな画面でのデータ入力のプロセスが難しくなるため、モバイルには特に適していません。ドロップダウンにオプションを配置するには2回タップする必要があり、オプションを非表示にします。

オプションの選択にドロップダウンを使用している場合は、それをラジオボタンに置​​き換えることを検討してください。 すべてのオプションが一目でわかりやすくなり、インタラクションコストも削減されます。ユーザーはアイテムをタップして一度に選択できます。

プレースホルダーとマスクされた入力を使用する

フォーマットの不確実性は、フォームデザインの最も重要な問題の1つです。 この問題は、フォームの放棄と直接関係があります。ユーザーがデータを提供する形式がわからない場合は、フォームをすぐに放棄できます。 フォーマットを明確にするためにできることがいくつかあります。

プレースホルダーテキスト

入力フィールドのテキストは、どのコンテンツが期待されているかをユーザーに伝えることができます。 プレースホルダーテキストは、「フルネーム」などの単純なフィールドには必要ありませんが、特定の形式のデータを必要とするフィールドには非常に役立ちます。 たとえば、小包を追跡するための検索機能を設計する場合、追跡番号フィールドのプレースホルダーとしてサンプル追跡番号を提供するとよいでしょう。

フォームでは、プレースホルダーテキストとユーザーが入力した実際の値を視覚的に明確に区別することが重要です。 つまり、プレースホルダーテキストはプリセット値のように見えるべきではありません。 明確な視覚的区別がないと、ユーザーはプレースホルダーのあるフィールドにすでに値があると考えるかもしれません。

マスクされた入力

フィールドマスキングは、ユーザーが入力されたテキストをフォーマットするのに役立つ手法です。 多くの設計者は、フィールドマスキングとプレースホルダーテキストを混同しています。これらは同じものではありません。 基本的に静的テキストであるプレースホルダーとは異なり、マスクはユーザーが提供するデータを自動的にフォーマットします。 以下の例では、電話番号を入力すると、括弧、スペース、ダッシュが画面に自動的に表示されます。

マスクされた入力により、ユーザーは情報を簡単に検証できます。 電話番号がチャンクで表示されると、タイプミスを見つけて修正するのが簡単になります。

一致するキーボードを提供する

モバイルユーザーは、フィールドに適切なキーボードを提供するアプリやWebサイトを高く評価しています。 この機能により、追加のアクションを実行できなくなります。 たとえば、ユーザーがクレジットカード番号を入力する必要がある場合、アプリはダイヤルパッドのみを表示する必要があります。 アプリ全体で一貫してキーボードマッチングを実装することが不可欠です（アプリ内のすべてのフォームにこの機能が必要です）。

正しいキーパッドを表示するようにHTML入力タイプを設定します。 フォームデザインには、次の7つの入力タイプが関係しています。

• input type="text"は、モバイルデバイスの通常のキーボードを表示します。
• input type="email"は、通常のキーボードと「@」および「.com」を表示します。
• input type="tel"は、0から9までの数字のキーパッドを表示します。
• input type="number"は、数字と記号を含むキーボードを表示します。
• input type="date"は、モバイルデバイスの日付セレクターを表示します。
• input type="datetime"は、モバイルデバイスの日付と時刻のセレクターを表示します。
• input type="month"は、モバイルデバイスの月と年のセレクターを表示します。

特定の範囲を求めるときはスライダーを使用してください

多くのフォームでは、ユーザーに値の範囲（たとえば、価格範囲、距離範囲など）を提供するように求めています。 そのために、「from」と「to」の2つの別々のフィールドを使用する代わりに、スライダーを使用して、ユーザーが親指で操作して範囲を指定できるようにします。

機密情報を求めている理由を明確に説明する

人々はプライバシーと情報セキュリティについてますます懸念を抱いています。 ユーザーがプライベートと見なす情報の要求を見ると、「うーん、なぜこれが必要なのか」と考えるかもしれません。 フォームでユーザーに機密情報を要求する場合は、その理由を必ず説明してください。 これを行うには、関連するフィールドの下にサポートテキストを追加します。 経験則として、説明テキストは100文字を超えてはなりません。

静的なデフォルトに注意する

システムがユーザーに関して持っている情報に基づいてシステムによって計算されるスマートデフォルトとは異なり、静的デフォルトは、すべてのユーザーに対して同じ形式のプリセット値です。 ユーザーの大部分（たとえば95％）がこれらの値を選択すると思われる場合を除いて、静的なデフォルトは避けてください。特に必須フィールドの場合はそうです。 なんで？ エラーが発生する可能性が高いため、人々はフォームをすばやくスキャンし、すべての質問の解析に余分な時間を費やすことはありません。 代わりに、フィールドにすでに値があると仮定して、フィールドをスキップします。

ユーザーデータを保護する

Jef Raskinはかつて、「システムはすべてのユーザー入力を神聖なものとして扱う必要があります」と述べました。 これはフォームにも当てはまります。 Webフォームへの入力を開始してから、誤ってページを更新した場合でも、データはフィールドに残ります。 Garlic.jsなどのツールは、フォームが送信されるまでフォームの値をローカルに保持するのに役立ちます。 これにより、ユーザーが誤ってタブやブラウザを閉じても、貴重なデータが失われることはありません。

アクションの自動化

データ入力のプロセスをできるだけスムーズにしたい場合は、入力フィールドの数を最小限に抑えるだけでは不十分です。データ入力に必要なユーザーの労力にも注意を払う必要があります。 入力には高いインタラクションコストがかかります。物理的なキーボードを使用している場合でも、エラーが発生しやすく、時間がかかります。 しかし、モバイル画面に関しては、それはさらに重要になります。 入力を増やすと、ユーザーがエラーを起こす可能性が高くなります。 ユーザーの満足度が向上し、エラー率が低下するため、不要な入力の防止に努めてください。

この目標を達成するためにできることがいくつかあります。

オートコンプリート

ほとんどのユーザーは、Googleの検索ボックスに質問を入力するとオートコンプリートが発生します。 Googleは、ユーザーがフィールドに入力した内容に関連する提案のリストをユーザーに提供します。 同じメカニズムをフォームデザインに適用できます。 たとえば、フォームでメールアドレスをオートコンプリートできます。

自動資本化

自動大文字化により、最初の文字が自動的に大文字になります。 この機能は、名前や番地などのフィールドには最適ですが、パスワードフィールドには使用しないでください。

オートコレクト

オートコレクトは、スペルが間違っているように見える単語を変更します。 名前、住所などの一意のフィールドでは、この機能をオフにします。

個人情報の自動入力

住所の入力は、多くの場合、オンラインサインアップフォームの中で最も面倒な部分です。 ブラウザ機能を使用して、以前に入力した値に基づいてフィールドに入力することにより、このタスクを簡単にします。 Googleの調査によると、自動入力により、フォームへの入力が30％速くなります。

モバイルデバイスのネイティブ機能を使用してデータ入力を簡素化する

最新のモバイルデバイスは、驚くべき機能を数多く備えた洗練されたデバイスです。 設計者は、デバイスのネイティブ機能（カメラやジオロケーションなど）を使用して、データ入力のタスクを合理化できます。

以下は、センサーとデバイスハードウェアを使用する方法に関するいくつかのヒントです。

位置情報サービス

ジオロケーションデータに基づいて、ユーザーの国を事前に選択することができます。 ただし、精度の問題により、完全なアドレスを事前に入力すると問題が発生する場合があります。 GoogleのPlacesAPIは、この問題の解決に役立ちます。 ジオロケーションと住所の事前入力の両方を使用して、ユーザーの正確な場所に基づいて正確な提案を提供します。

位置情報サービスを使用して、スマートなデフォルトを提供することも可能です。 たとえば、「フライトを検索」フォームの場合、ユーザーの地理的位置に基づいて、「From」フィールドにユーザーに最も近い空港を事前に入力することができます。

生体認証

今日のテキストパスワードを使用する際の最大の問題は、ほとんどの人がパスワードを忘れてしまうことです。 82％の人が自分のパスワードを思い出せず、5〜10％のセッションでユーザーがパスワードをリセットする必要があります。 パスワードの回復は、eコマースでは大きな問題です。 ユーザーの75％は、チェックアウト中にパスワードを回復しようとすると、購入を完了しませんでした。

パスワードの未来はパスワードではありません。 今日でも、モバイル開発者は生体認証技術を利用できます。 ユーザーはパスワードを入力する必要はありません。 認証に生体認証リーダーを使用できる必要があります—指紋または顔スキャンを使用してサインインします。

カメラ

フォームでユーザーにクレジットカードの詳細や運転免許証の情報を提供するように求められた場合、カメラをスキャナーとして使用することで、データ入力のプロセスを簡素化することができます。 カードの写真を撮り、すべての詳細を自動的に入力するオプションを提供します。

ただし、アプリがフィールドにどれだけ適切に入力しても、編集できるようにしておくことが重要であることを忘れないでください。 ユーザーは、いつでもフィールドを変更できる必要があります。

ボイス

Apple HomePod、Google Home、Amazon Echoなどの音声制御デバイスは、市場に積極的に侵入しています。 一般的な操作に音声を使用することを好む人の数は大幅に増加しています。 ComScoreによると、2020年までにすべての検索の50％が音声検索になります。

ユーザーが音声コマンドを使用してより快適で自信を持てるようになると、ユーザーはモバイルインタラクションの期待される機能になります。 音声入力は、モバイルユーザーに多くの利点を提供します。たとえば、車の運転中にユーザーが画面に集中できない場合に特に役立ちます。

フォームをデザインするとき、データ入力の代替方法として音声入力を提供できます。

フィールドラベル

明確で簡潔なラベルを書く

ラベルは、特定の入力フィールドでユーザーに期待されるデータをユーザーに伝えるテキストです。 明確なラベルを書くことは、フォームをよりアクセスしやすくするための最良の方法の1つです。 ラベルは、ユーザーが必要な情報を一目で理解するのに役立つはずです。

説明に完全な文を使用することは避けてください。 ラベルはヘルプテキストではありません。 ユーザーがフォームをすばやくスキャンできるように、簡潔で鮮明なラベル（1〜2語）を作成します。

ラベルと入力を近づけて配置します

各ラベルを入力フィールドの近くに配置します。これは、目がそれらが互いに結び付けられていることを視覚的に認識できるためです。

消えるプレースホルダーテキストをラベルとして使用しないでください

インラインラベルは見栄えがよく、貴重な画面の資産を節約しますが、これらの利点は、使いやすさの重大な欠点をはるかに上回ります。その中で最も重要なのは、コンテキストの喪失です。 ユーザーがフィールドにテキストを入力し始めると、プレースホルダーテキストが消え、ユーザーにこの情報を思い出させます。 単純な2フィールドのフォームでは問題にならないかもしれませんが、多くのフィールド（たとえば、7から10）を持つフォームでは大きな問題になる可能性があります。 データを入力した後、ユーザーがすべてのフィールドラベルを思い出すのは難しいでしょう。 当然のことながら、ユーザーテストでは、フォームフィールドのプレースホルダーが、ヘルプよりもユーザビリティを損なうことが多いことが示されています。

プレースホルダーが消えるという問題には、フローティング（またはアダプティブ）ラベルという簡単な解決策があります。 ユーザーがラベルプレースホルダーでフィールドをタップした後、ラベルは消えず、フィールドの上部に移動し、ユーザーがデータを入力するためのスペースを確保します。

上揃えラベル

フォームのフィールドの上にフィールドラベルを配置すると、ユーザーがフォームをスキャンする方法が向上します。 このために視線追跡技術を使用して、Googleは、ユーザーがフォームを送信する前に必要な凝視、凝視時間、およびサッカードが少ないことを示しました。

上揃えラベルのもう1つの重要な利点は、ラベル用のスペースが増えることです。 長いラベルとローカライズされたバージョンは、レイアウトにより簡単に収まります。 後者は、小さなモバイル画面に特に適しています。 フォームフィールドを画面の全幅に拡張して、ユーザーの入力全体を表示するのに十分な大きさにすることができます。

センテンスケース対タイトルケース

単語を大文字にする一般的な方法は2つあります。

• タイトルケース：すべての単語を大文字にします。 「これはタイトルケースです。」
• 文の場合：最初の単語を大文字にします。 「これは文の場合です。」

ラベルに文の大文字小文字を使用すると、タイトルの大文字小文字に比べて1つの利点があります。それは、読みやすく（したがって、高速に）なります。 短いラベルの違いはごくわずかですが（「フルネーム」と「フルネーム」の違いはあまりありません）、長いラベルの場合は文の大文字小文字の区別が適しています。 これで、タイトルケースで長いテキストを読むことがどれほど難しいかがわかりました。

ラベルにキャップを使用しないでください

オールキャップスのテキスト（すべての文字が大文字のテキストを意味します）は、実質的な読み方を伴わないコンテキスト（頭字語やロゴなど）では問題ありませんが、それ以外の場合はすべてキャップスを避けてください。 マイルズ・ティンカーの著書「印刷の読みやすさ」で述べたように、すべて大文字の印刷は、小文字のタイプと比較して、スキャンと読み取りの速度を劇的に遅くします。

レイアウト

これで、ユーザーがWebページを読むのではなく、スキャンすることがわかりました。 フォームへの記入についても同じことが言えます。 そのため、設計者はスキャンしやすいフォームを設計する必要があります。 効率的で効果的なスキャンを可能にすることは、フォームへの入力プロセスを可能な限り迅速にするために重要です。

単一列レイアウトを使用する

CXL Instituteの調査によると、単一列のフォームは複数列のフォームよりも完成が速いことがわかりました。 その研究では、テスト参加者は、複数列のフォームよりも平均15.4秒速く単一列のフォームを完了することができました。

複数の列は、ユーザーの垂直方向の勢いを乱します。 複数の列があると、目がジグザグに動き始めます。 これにより、固視の数が劇的に増加し、その結果、完了時間が長くなります。 さらに、複数列のフォームでは、「どこから始めればよいですか」など、ユーザーに不要な質問が発生する可能性があります。 および「右側の列の質問は、左側の列の質問と同じ重要性ですか？」

1列のデザインでは、目は自然な方向に、上から下に、一度に1行ずつ移動します。 これは、ユーザーに明確なパスを設定するのに役立ちます。 画面が垂直方向に長く、垂直方向のスクロールはモバイルユーザーにとって自然な動きであるため、1列はモバイルに最適です。

この規則にはいくつかの例外があります。 短く論理的に関連するフィールドを同じ行に配置することができます（都市や市外局番など）。

質問でフローを作成する

質問の仕方も重要です。 質問は、アプリケーションやデータベースのロジックではなく、ユーザーの観点から論理的に行う必要があります。これは、ユーザーとの会話の感覚を生み出すのに役立つためです。 たとえば、チェックアウトフォームをデザインして、氏名、電話番号、クレジットカードなどの詳細を尋ねる場合、最初の質問は氏名です。 順序を変更すると（たとえば、名前ではなく電話番号で開始する）、不快感が生じます。 実際の会話では、名前を尋ねる前に誰かの電話番号を尋ねることは珍しいでしょう。

詳細な質問を最後まで延期する

質問したい質問のフローを設計する場合は、優先順位付けについて考えてください。 「難しい前に簡単」というルールに従い、最後に詳細な質問や個人的な質問をします。 これにより、ユーザーはプロセスに簡単に参加できます。 信頼関係を築くと、複雑で煩わしい質問に答える可能性が高くなります。 これには科学的な根拠があります。ロバート・チャルディーニの一貫性の原則は、誰かが小さな行動をとったり、何かに向かって一歩を踏み出したときに、彼らはより終わらせなければならないと感じることを規定しています。

関連フィールドをグループ化する

ゲシュタルト心理学の原則の1つである近接性の原理は、関連する要素は互いに近くにあるべきであると述べています。 この原則は、フォーム内の質問の順序に適用できます。 関連する質問が多いほど、互いに近づける必要があります。

設計者は、関連するフィールドをセクションにグループ化できます。 フォームに6つを超える質問がある場合は、関連する質問を論理セクションにグループ化します。 セクションを視覚的に区別するために、セクション間に十分な空白を設けることを忘れないでください。

長いフォームをよりシンプルに見せます

ユーザーに多くの質問をするフォームをどのように設計しますか？ もちろん、すべての質問を1つの画面に表示することもできます。 しかし、これはあなたの完了率を妨げます。 ユーザーがフォームに記入するための十分な動機を持っていない場合、フォームの複雑さがユーザーを怖がらせる可能性があります。 第一印象は重要な役割を果たします。 一般に、フォームが長くなったり複雑になったりするほど、ユーザーが空欄に記入し始める可能性は低くなります。

一度に表示されるフィールドの数を最小限に抑えます。 これにより、フォームが実際よりも短いという認識が生まれます。

これを行うには2つの手法があります。

プログレッシブディスクロージャー

段階的開示とは、ユーザーに適切なタイミングで適切なものを提供することです。 目標は、適切なタイミングで小さな画面に配置する適切なものを見つけることです。

• 最初に、最も重要なオプションのいくつかだけをユーザーに表示します。
• ユーザーがフォームを操作するときに、フォームの一部を表示します。

チャンキング

チャンキングは、長いフォームをステップに分割することを伴います。 フォームをいくつかのステップに分割することで、完了率を上げることができます。 チャンキングは、ユーザーが情報を処理、理解、および記憶するのにも役立ちます。 マルチステップフォームを設計するときは、常に完全性メーターを使用して進捗状況をユーザーに通知してください。

設計者は、進行状況トラッカー（上記の例に示されている）または「ステップ＃アウトオブ＃」インジケーターのいずれかを使用して、合計ステップ数を示し、ユーザーが現在どのくらい進んでいるかを示すことができます。 後者のアプローチは、ステップ表示があまりスペースをとらないため、モバイルフォームに最適です。

アクションボタン

ボタンは、ユーザーにアクションを実行するように指示するインタラクティブな要素です。

アクションボタンをわかりやすくする

ボタンのラベルは、ボタンの機能を説明する必要があります。 ユーザーは、ボタンを見るだけで、タップ後に何が起こるかを理解できるはずです。 「送信」や「送信」などの一般的なラベルは避け、代わりにアクションを説明するラベルを使用してください。

クリアボタンまたはリセットボタンは使用しないでください

クリアボタンまたはリセットボタンを使用すると、ユーザーはフォーム内のデータを消去できます。 これらのボタンは、ユーザーを助けることはほとんどなく、しばしばユーザーを傷つけます。 ユーザーが入力したすべての情報を削除するリスクは、最初からやり直す必要があるという小さなメリットを上回ります。 ユーザーがフォームに入力して誤って間違ったボタンを押した場合、最初からやり直さない可能性が高くなります。

プライマリボタンとセカンダリボタンに異なるスタイルを使用する

可能であれば、二次的な行動は避けてください。 ただし、フォームに2つの行動の呼びかけ（たとえば、「割引の適用」ボタンと「注文の送信」ボタンがあるeコマースフォーム）がある場合は、一次アクションと二次アクションを明確に視覚的に区別してください。 ボタンに視覚的な重みを追加して、主要なアクションに視覚的に優先順位を付けます。 これにより、ユーザーが間違ったボタンをタップするのを防ぐことができます。

指に優しいタッチターゲットを設計する

小さなタッチターゲットは、ユーザーがインタラクティブなオブジェクトを操作するのを難しくするため、ひどいユーザーエクスペリエンスを生み出します。 指に優しいタッチターゲットを設計することが重要です。より大きな入力フィールドとボタンです。

下の画像は、平均的な成人の指の幅が約11mmであることを示しています。

マテリアルデザインのガイドラインによると、タッチターゲットは少なくとも48×48DPである必要があります。 このサイズのタッチターゲットは、画面サイズに関係なく、約9mmの物理サイズになります。 より広い範囲のユーザーに対応するには、より大きなタッチターゲットを使用することが適切な場合があります。

ターゲットのサイズが重要であるだけでなく、タッチターゲット間の十分なスペースも重要です。 タッチターゲット間の安全な距離を維持する主な理由は、ユーザーが間違ったボタンに触れたり、間違ったアクションを呼び出したりするのを防ぐためです。 「同意する」と「同意しない」などのバイナリ選択肢が隣り合っている場合、ボタン間の距離は非常に重要になります。 マテリアルデザインのガイドラインでは、タッチターゲットを8 DP以上のスペースで分離することを推奨しています。これにより、バランスの取れた情報密度と使いやすさが実現します。

タップ後にボタンを無効にする

フォームアクションは通常、処理に時間がかかります。 たとえば、送信後にデータ計算が必要になる場合があります。 アクションの進行中にフィードバックを提供するだけでなく、送信ボタンを無効にして、ユーザーが誤ってボタンを再度タップしないようにすることも重要です。 これは、eコマースのウェブサイトやアプリにとって特に重要です。 By disabling the button, you not only prevent duplicate submissions, which can happen by accident, but you also provide a valuable acknowledgment to users (users will know that the system has received their submission).

Assistance And Support

Provide Success State

Upon successful completion of a form, it's critical to notify users about that. It's possible to provide this information in the context of an existing form (for example, showing a green checkmark above the refreshed form) or to direct users to a new page that communicates that their submission has been successful.

Errors And Validation

Users will make mistakes. It's inevitable. It's essential to design a user interface that supports users in those moments of failures.

While the topic of errors and validation deserves its own article, it's still worth mentioning a few things that should be done to improve the user experience of mobile forms.

Use Input Constraints for Each Field

Prevention is better than a cure. If you're a seasoned designer, you should be familiar with the most common cases that can lead to an error state (error-prone conditions). For example, it's usually hard to correctly fill out a form on the first attempt, or to properly sync data when the mobile device has a poor network connection. Take these cases into account to minimize the possibility of errors. In other words, it's better to prevent users from making errors in the first place by utilizing constraints and offering suggestions.

For instance, if you design a form that allows people to search for a hotel reservation, you should prevent users from selecting check-in dates that are in the past. As shown in the Booking.com example below, you can simply use a date selector that allows users only to choose today's date or a date in the future. Such a selector would force users to pick a date range that fits.

Don't Make Data Validation Rules Too Strict

While there might be cases where it's essential to use strict validation rules, in most cases, strict validation is a sign of lazy programming. Showing errors on the screen when the user provides data in a slightly different format than expected creates unnecessary friction. And this would have a negative impact on conversions.

It's very common for a few variations of an answer to a question to be possible; for example, when a form asks users to provide information about their state, and a user responds by typing their state's abbreviation instead of the full name (for example, CA instead of California). The form should accept both formats, and it's the developer job to convert the data into a consistent format.

Clear Error Message

When you write error messages, focus on minimizing the frustration users feel when they face a problem in interacting with a form. Here are a few rules on writing effective error messages:

• Never blame the user.
  The way you deliver an error message can have a tremendous impact on how users perceive it. An error message like, “You've entered a wrong number” puts all of the blame on the user; as a result, the user might get frustrated and abandon the app. Write copy that sounds neutral or positive. A neutral message sounds like, “That number is incorrect.”
• Avoid vague or general error messages.
  Messages like “Something went wrong. Please, try again later” don't say much to users. Users will wonder what exactly went wrong. Always try to explain the root cause of a problem. Make sure users know how to fix errors.
• Make error messages human-readable.
  Error messages like “User input error: 0x100999” are cryptic and scary. Write like a human, not like a robot. Use human language, and explain what exactly the user or system did wrong, and what exactly the user should do to fix the problem.

Display Errors Inline

When it comes to displaying error messages, designers opt for one of two locations: at the top of the form or inline. The first option can make for a bad experience. Javier Bargas-Avila and Glenn Oberholzer conducted research on online form validation and discovered that displaying all error messages at the top of the form puts a high cognitive load on user memory. Users need to spend extra time matching error messages with the fields that require attention.

エラーメッセージをインラインに配置することをお勧めします。 まず、この配置は、ユーザーの自然な上から下への読み取りフローに対応しています。 次に、エラーはユーザーの入力のコンテキストで表示されます。

動的検証を使用する

エラーメッセージの表示を選択する時間は非常に重要です。 送信ボタンを押した後にのみエラーメッセージが表示されると、ユーザーを苛立たせる可能性があります。 ユーザーがフォームに記入するまで待たないでください。 データが入力されているときにフィードバックを提供します。

リアルタイムのフィードバックでインライン検証を使用します。 この検証により、入力した情報がフォームの要件と互換性があるかどうかが即座にわかります。 2009年、Luke Wroblewskiは、提出後の検証に対してインライン検証をテストし、インラインバージョンで次の結果を見つけました。

• 成功率が22％向上、
• エラーが22％減少し、
• 満足度が31％向上、
• 完了時間が42％短縮され、
• 固視の数が47％減少します。

ただし、インライン検証は慎重に実装する必要があります。

• フォーカスにインライン検証を表示することは避けてください。
  この場合、ユーザーがフィールドをタップするとすぐに、エラーメッセージが表示されます。 フィールドが完全に空の場合でも、エラーが表示されます。 エラーメッセージがフォーカスで表示される場合、ユーザーが入力を開始する前に、フォームがユーザーに怒鳴っているように見える場合があります。
• 各文字を入力した後に検証しないでください。
  このアプローチは、不要な検証の試行回数を増やすだけでなく、ユーザーを苛立たせます（ユーザーは、フィールドに入力する前にエラーメッセージが表示される可能性が高いため）。 理想的には、インライン検証メッセージは、ユーザーが入力を停止した後、または次のフィールドに移動した後、約500〜1000ミリ秒で表示される必要があります。 このルールにはいくつかの例外があります。ユーザーがパスワードを作成するとき（パスワードが複雑さの要件を満たしているかどうかを確認するため）、ユーザー名を作成するとき（名前が使用可能かどうかを確認するため）、および入力するときにインラインで検証すると便利です。文字数制限のあるメッセージ。

アクセシビリティ

すべての能力のユーザーは、デジタル製品にアクセスして楽しむことができる必要があります。 設計者は、製品を構築するときに、アクセシビリティのニーズを可能な限り組み込むように努める必要があります。 フォームをよりアクセスしやすくするためにできることがいくつかあります。

フォームに適切なコントラストがあることを確認します

ユーザーは屋外でフォームを操作する可能性があります。 太陽のまぶしさや暗い環境の両方で使いやすいことを確認してください。 フォームのフィールドとラベルのコントラスト比を確認してください。 W3Cは、本文テキストに次のコントラスト比を推奨しています。

• 小さなテキストは、背景に対して少なくとも4.5：1のコントラスト比を持っている必要があります。
• 大きなテキスト（14ポイントの太字、18ポイントの通常以上）は、背景に対して少なくとも3：1のコントラスト比を持っている必要があります。

色のコントラストを測定することは、圧倒的に思えるかもしれません。 幸いなことに、いくつかのツールはプロセスを単純にします。 それらの1つは、設計者がコントラストレベルを測定するのに役立つWebAIMカラーコントラストチェッカーです。

ステータスを伝えるために色だけに頼らないでください

色覚異常（または色覚異常）は、世界の男性の約12人に1人（8％）、女性の200人に1人に影響を及ぼします。 色覚異常には多くの種類がありますが、最も一般的な2つは、1型3色覚（赤色光に対する感度の低下）と2型3色覚（緑色光に対する感度の低下）です。 検証エラーまたは成功メッセージを表示するときは、ステータスを伝えるために色だけに頼らないでください（つまり、入力フィールドを緑または赤にすることによって）。 W3Cガイドラインに記載されているように、情報を伝達したり、アクションを示したり、応答を促したり、視覚要素を区別したりするための唯一の視覚的手段として色を使用するべきではありません。 デザイナーは、色を使用して、すでに表示されているものを強調または補完する必要があります。 ユーザーインターフェイスを理解するのに役立つ追加の視覚的手がかりを提供することにより、色覚異常の人々をサポートします。

ユーザーがフォントサイズを制御できるようにする

ユーザーがフォントサイズを大きくして読みやすさを向上できるようにします。 モバイルデバイスとブラウザには、ユーザーがシステム全体でフォントサイズを調整できるようにする機能が含まれています。 また、フォームに大きなフォントサイズに十分なスペースが割り当てられていることを確認してください。

設計上の決定をテストする

上記のすべてのポイントは、業界のベストプラクティスと見なすことができます。 しかし、何かが「ベストプラクティス」と呼ばれているからといって、それが常にフォームに最適なソリューションであるとは限りません。 アプリとウェブサイトは、それらが使用されるコンテキストに大きく依存します。 したがって、設計上の決定をテストすることは常に不可欠です。 フォームへの入力プロセスがスムーズで、フローが中断されないようにし、ユーザーが途中で直面する問題を解決できるようにします。 定期的にユーザビリティテストセッションを実施し、ユーザーインタラクションに関するすべての貴重なデータを収集し、そこから学びます。

結論

ユーザーはフォームへの記入をためらうことがあります。 したがって、デザイナーとしての私たちの目標は、フォームに記入するプロセスをできるだけ簡単にすることです。 フォームを設計するときは、高速で摩擦のない相互作用を作成するように努めてください。 エラーメッセージを適切に書き込むなどの小さな変更により、フォームの使いやすさが大幅に向上する場合があります。

この記事は、アドビが後援するUXデザインシリーズの一部です。 Adobe XDは、アイデアからプロトタイプへの移行を高速化できるため、高速で流動的なUXデザインプロセス向けに作られています。 設計、プロトタイプ作成、共有—すべてを1つのアプリで。 Adobe XD on Behanceで作成されたより刺激的なプロジェクトをチェックしたり、Adobeエクスペリエンスデザインニュースレターにサインアップして、UX / UIデザインの最新のトレンドや洞察に関する最新情報を入手したりできます。