支払いと住所フォームのベスト プラクティス

ユーザーが住所や支払いのフォームにできるだけすばやく簡単に入力できるようにして、コンバージョン数を最大化します。

Sam Dutton

適切に設計されたフォームはユーザーに役立ち、コンバージョン率の向上につながります。小さな修正でも大きな違いを生むことができます。

以下に、すべてのベスト プラクティスを適用したシンプルな支払いフォームの例を示します。

以下に、すべてのベスト プラクティスを適用したシンプルな住所フォームの例を示します。

チェックリスト

有意な HTML を使用する

ジョブ用に作成された要素と属性を使用します。

  • <form>、<input>、<label>、<button>
  • type、autocomplete、inputmode

これらにより、ブラウザの組み込み機能を有効にし、ユーザー補助を改善し、マークアップに意味を追加できます。

HTML 要素を意図したとおりに使用する

フォームを <form> に入れる

<input> 要素を <form> でラップせず、データ送信を JavaScript でのみ処理したくなるかもしれません。

このようなことは行わないでください。

HTML <form> を使用すると、すべての最新ブラウザで強力な一連の組み込み機能を利用できます。また、スクリーン リーダーやその他の支援デバイスでサイトにアクセスできるようにすることもできます。<form> を使用すると、JavaScript のサポートが限定的な古いブラウザ向けの基本機能を簡単に構築できます。また、コードに不具合があってもフォーム送信を有効にできます。JavaScript を実際に無効にしている少数のユーザーにも対応できます。

ユーザー入力に複数のページ コンポーネントがある場合は、それぞれを独自の <form> 要素に配置します。たとえば、検索と登録が同じページにある場合は、それぞれを独自の <form> に配置します。

<label> を使用して要素にラベルを付ける

<input>、<select>、または <textarea> にラベルを付けるには、<label> を使用します。

ラベルの for 属性に入力の id と同じ値を指定して、ラベルを入力に関連付けます。

<label for="address-line1">Address line 1</label>
<input id="address-line1" …>

1 つの入力に 1 つのラベルを使用します。複数の入力に 1 つのラベルだけでラベル付けしないでください。これはブラウザとスクリーン リーダーに最適です。ラベルをタップまたはクリックすると、ラベルが関連付けられている入力にフォーカスが移動します。スクリーン リーダーは、ラベルまたはラベルの入力にフォーカスが移動すると、ラベルのテキストを読み上げます。

ボタンを役立つものにする

ボタンには <button> を使用します。<input type="submit"> を使用することもできますが、div やボタンとして機能する他のランダムな要素は使用しないでください。ボタン要素は、ユーザー補助対応の動作、組み込みのフォーム送信機能を提供します。また、簡単にスタイル設定できます。

各フォーム送信ボタンに、その機能を表す値を設定します。購入手続きの各ステップで、進行状況を示し、次のステップを明確にするわかりやすい行動を促すフレーズを使用します。たとえば、配送先住所フォームの送信ボタンのラベルを [続行] や [保存] ではなく [お支払いへ進む] にします。

ユーザーが送信ボタンをタップまたはクリックした後に、そのボタンを無効にすることを検討してください。特に、ユーザーが支払いまたは注文を行う場合は、この方法をおすすめします。多くのユーザーは、ボタンが正常に動作していても、ボタンを繰り返しクリックします。そうするとチェックアウトが台無しになり、サーバーの負荷が増す可能性があります。

一方で、完全で有効なユーザー入力を待機して送信ボタンを無効にしないでください。たとえば、何かが不足している、または無効であるという理由で、[住所を保存] ボタンを無効にしたままにしないでください。これはユーザーにとって役に立ちません。ユーザーはボタンをタップまたはクリックし続け、ボタンが故障していると判断する可能性があります。代わりに、ユーザーが無効なデータを含むフォームを送信しようとした場合は、問題点と修正方法を説明します。これは、データ入力が難しいモバイルでは特に重要です。フォームの送信を試みるまでに、不足しているフォームデータや無効なフォームデータがユーザーの画面に表示されなくなる可能性があります。

HTML 属性を最大限に活用する

ユーザーがデータを簡単に入力できるようにする

適切な入力 type 属性を使用して、モバイルで適切なキーボードを提供し、ブラウザによる基本的な組み込み検証を有効にします。

たとえば、メールアドレスには type="email"、電話番号には type="tel" を使用します。

電子メールアドレス（type=email）の入力と電話番号（type=tel）の入力に適したキーボードが表示されている Android スマートフォンの 2 つのスクリーンショット。
メールと電話に適したキーボード。

日付を表示する場合は、select カスタム要素を使用しないようにします。正しく実装されていないと自動入力が機能せず、古いブラウザでも機能しません。生年月日などの数値の場合は、特にモバイルでは、長いプルダウン リストから選択するよりも、手動で数字を入力するほうが簡単でエラーが少ないため、select ではなく input 要素の使用を検討してください。inputmode="numeric" を使用して、モバイルで適切なキーボードが表示されるようにし、テキストまたはプレースホルダを使用して検証と形式のヒントを追加し、ユーザーが適切な形式でデータを入力できるようにします。

自動入力を使用してユーザー補助を改善し、ユーザーがデータを再入力しなくて済むようにする

適切な autocomplete 値を使用すると、ブラウザでユーザーがデータを安全に保存し、input、select、textarea の値を自動入力できます。これはモバイルでは特に重要であり、フォームの放棄率が高いことを回避するために不可欠です。自動入力には、複数のアクセシビリティ上のメリットもあります。

フォーム フィールドに適切な自動入力値が使用可能な場合は、その値を使用する必要があります。MDN のウェブ ドキュメントでは、値の一覧と正しく使い方が説明されています。

安定した値

請求先住所

デフォルトでは、請求先住所を配送先住所と同じに設定します。フォームで請求先住所を表示するのではなく、請求先住所を編集するためのリンクを表示する（または summary 要素と details 要素を使用する）ことで、見た目をわかりやすくします。

請求先住所の変更リンクが表示されている購入手続きページの例。
お支払いを確認するためのリンクを追加。

配送先住所と同様に、請求先住所にも適切なオートコンプリート値を使用して、ユーザーがデータを複数回入力しなくて済むようにします。名前が同じでセクションごとに値が異なる場合は、予測入力属性に接頭辞の単語を追加します。

<input autocomplete="shipping address-line-1" ...>
...
<input autocomplete="billing address-line-1" ...>

ユーザーが正しいデータを入力できるようサポートする

お客様が「何か間違えた」からといって、お客様を「叱責」することは避けてください。代わりに、問題が発生したときにユーザーが問題を解決できるようにサポートし、ユーザーがフォームをより迅速かつ簡単に完了できるようにします。購入手続きでは、お客様は商品やサービスに対して貴社にお支払いしようとしています。お客様を罰するのではなく、サポートすることがお客様対応担当者の役割です。

制約属性を追加して要素を形成し、許容される値（min、max、pattern など）を指定できます。要素の有効性状態は、要素の値が有効かどうかに応じて自動的に設定されます。また、有効または無効な値を持つ要素のスタイル設定に使用できる :valid および :invalid CSS 疑似クラスも同様です。

たとえば、次の HTML では、生まれた年が 1900 年から 2020 年の間で入力されています。type="number" を使用すると、入力値は min と max で指定された範囲内の数値のみに制限されます。範囲外の数字を入力しようとすると、入力は無効な状態に設定されます。

次の例では、pattern="[\d ]{10,30}" を使用して有効な支払いカード番号を指定しながら、スペースを許可しています。

最新のブラウザでは、email または url タイプの入力に対して基本的な検証も行われます。

フォームの送信時に、問題のあるフィールドや必須値が入力されていないフィールドにブラウザが自動的にフォーカスを設定します。JavaScript は必要ありません。

ブラウザのプロンプトと無効なメールアドレスへのフォーカスが表示されている、パソコン版 Chrome のログインフォームのスクリーンショット。
ブラウザによる基本的な組み込み検証。

送信ボタンをクリックしたときにエラーのリストを表示するのではなく、入力時にインラインで検証し、ユーザーにフィードバックを提供します。フォームの送信後にサーバー上のデータを検証する必要がある場合は、検出されたすべての問題をリストアップし、無効な値を持つフォーム フィールドをすべて明確にハイライト表示します。また、問題のある各フィールドの横に、修正が必要な点を説明するメッセージをインラインで表示します。サーバーログと分析データで一般的なエラーを確認します。フォームの再設計が必要になる場合があります。

また、JavaScript を使用して、ユーザーがデータを入力している間やフォームの送信時に、より堅牢な検証を行う必要があります。Constraint Validation API（広くサポートされている）を使用して、組み込みのブラウザ UI を使用してカスタム検証を追加し、フォーカスを設定してプロンプトを表示します。

詳しくは、JavaScript を使用してより複雑なリアルタイム検証を行うをご覧ください。

ユーザーが必要なデータを入力し忘れないようにする

必須値の入力には required 属性を使用します。

フォームが送信されると、最新のブラウザはデータが入力されていない required フィールドに自動的にプロンプトを表示し、フォーカスを設定します。:required 疑似クラスを使用して、必須フィールドをハイライト表示することもできます。JavaScript は必要ありません。

必須フィールドのラベルにアスタリスクを追加し、アスタリスクの意味を説明する注記をフォームの先頭に追加します。

購入手続きを簡素化

モバイル コマースのギャップに注意してください。

ユーザーが疲労予算を持っているとします。使い切ると、ユーザーは離れてしまいます。

特にモバイルでは、ユーザーの負担を軽減し、集中力を維持する必要があります。多くのサイトでは、モバイルからのトラフィックは多いものの、デスクトップからのコンバージョンが多いという現象が見られます。これは、モバイル コマース ギャップと呼ばれるものです。ユーザーがデスクトップで購入することを好む場合もありますが、モバイル コンバージョン率が低いのは、ユーザー エクスペリエンスが悪いことも原因です。モバイルでのコンバージョンの損失を最小限に抑え、パソコンでのコンバージョンを最大化することが目標です。モバイル フォームのエクスペリエンスを改善することで、大きなビジネスチャンスが得られるという調査結果があります。

何よりも、長く複雑で、方向性が不明確なフォームは、ユーザーが放棄する可能性が高くなります。これは、ユーザーが小さな画面を使用しているとき、注意散漫になっているとき、急いでいるときに特に当てはまります。できるだけ少ないデータをリクエストします。

「ログインせずに決済」をデフォルトにする

オンライン ショップでフォームの煩わしさを軽減する最も簡単な方法は、ゲスト購入をデフォルトにすることです。購入前にユーザーにアカウントの作成を強制しないでください。ショッピング カート放棄の主な理由として、ゲスト購入が許可されていないことが挙げられます。

購入手続き中にショッピング カートから離脱する理由。
baymard.com/checkout-usability から

購入手続き後にアカウントの登録を提案できます。この時点では、アカウントの設定に必要なデータのほとんどがすでにあるため、ユーザーは簡単にアカウントを作成できます。

購入手続きの進行状況を表示する

進捗状況を表示し、次に行う必要があることを明確にすることで、購入手続きの複雑さを軽減できます。以下の動画は、英国の小売業者 johnlewis.com がこれを実現する方法を示しています。

ご購入手続きの進行状況を表示します。

勢いを維持する必要があります。支払いのステップごとに、ページ見出しとわかりやすいボタンの値を使用して、何をする必要があるか、次にどの決済ステップに進むべきかを明確にします。

フォームのボタンに、次のステップを示す意味のある名前を付けます。

フォーム入力の enterkeyhint 属性を使用して、モバイル キーボードの Enter キーのラベルを設定します。たとえば、複数ページのフォーム内では enterkeyhint="previous" と enterkeyhint="next" を使用し、フォームの最終入力には enterkeyhint="done" を使用し、検索入力には enterkeyhint="search" を使用します。

Enterkeyhint 入力属性によってキー入力ボタンのアイコンがどのように変化するかを示す、Android の住所フォームの 2 枚のスクリーンショット。
Android の入力キーボタン: [次へ] と [完了]。

enterkeyhint 属性は、Android と iOS でサポートされています。詳しくは、enterkeyhint の説明をご覧ください。

ユーザーが購入手続き内で前後に移動し、最終的な支払い手順であっても注文を簡単に調整できるようにします。限定的な概要だけでなく、注文の詳細をすべて表示します。ユーザーが支払いページから商品の数量を簡単に調整できるようにします。購入手続きでは、コンバージョンに至るプロセスを中断しないようにすることが重要です。

不要なものを除去

商品プロモーションなどの視覚的な雑然と気を散らす要素を削除して、離脱ポイントの可能性を減らします。 成功している小売業者の多くは、購入手続きからナビゲーションと検索を削除しています。

johnlewis.com の購入手続きの進行状況を示すモバイルのスクリーンショット 2 枚。検索、ナビゲーションなどの不要な機能は削除されます。
購入手続きの際に、検索、ナビゲーションなどの不要な機能が削除されました。

ジャーニーに集中します。ユーザーに他のアクションを促すようなことはしないでください。

無料ステッカーのプロモーションが目立つように表示されているモバイルの購入手続きページのスクリーンショット。
購入手続きを妨げないようにしてください。

リピーターに対しては、表示する必要がないデータを非表示にして、購入手続きをさらに簡略化できます。たとえば、配送先住所を（フォームではなく）書式なしテキストで表示し、ユーザーがリンクで住所を変更できるようにします。

購入手続きページの [注文内容を確認] セクションのスクリーンショット。書式なしテキストで表示されているテキストと、配送先住所、お支払い方法、請求先住所の変更リンクが表示されていません。
お客様に表示する必要のないデータを非表示にします。

名前と住所の入力を簡単にする

必要なデータのみをリクエストする

氏名や住所のフォームをコーディングする前に、どのようなデータが必要かを把握しておいてください。必要のないデータをリクエストしないでください。フォームの複雑さを軽減する最も簡単な方法は、不要なフィールドを削除することです。これはユーザーのプライバシー保護にもつながり、バックエンド データの費用と責任を軽減できます。

単一の名前入力を使用する

名、姓、敬称、その他の名前の各部を分けて保存する正当な理由がない限り、ユーザーが 1 回の入力で名前を入力できるようにします。単一の名前入力を使用すると、フォームの複雑さが軽減され、カット＆ペーストが可能になり、自動入力が簡単になります。

特に、やむを得ない理由がない限り、接頭辞や称号（Mrs、Dr、Lord など）に個別の入力を追加しないでください。ユーザーは必要に応じて、名前とともに入力できます。また、honorific-prefix の予測入力は現在、ほとんどのブラウザで機能しないため、名前の接頭辞やタイトルのフィールドを追加すると、ほとんどのユーザーにとって住所フォームの自動入力がうまく機能しなくなります。

名前の自動入力を有効にする

フルネームには name を使用します。

<input autocomplete="name" ...>

名前の部分を分割する正当な理由がある場合は、適切な自動入力値を使用してください。

  • honorific-prefix
  • given-name
  • nickname
  • additional-name-initial
  • additional-name
  • family-name
  • honorific-suffix

国際的な名前を許可する

名前の入力を検証したり、名前データに使用できる文字を制限したりできます。ただし、アルファベットについては、できるだけ制限を緩める必要があります。名前が「無効」だと言われたら、不愉快に感じます。

検証では、ラテン文字のみに一致する正規表現は使用しないでください。ラテン文字のみの場合、ラテン文字以外の文字を含む名前または住所を持つユーザーは除外されます。代わりに Unicode 文字の照合を許可し、バックエンドが入力と出力の両方で Unicode を安全にサポートしていることを確認します。正規表現の Unicode は、最新のブラウザでは十分にサポートされています。

すべきでないこと
<!-- Names with non-Latin characters (such as Françoise or Jörg) are 'invalid'. -->
<input pattern="[\w \-]+" ...>
すべきこと
<!-- Accepts Unicode letters. -->
<input pattern="[\p{L} \-]+" ...>
ラテン文字のみのマッチングと Unicode 文字のマッチングの比較。

さまざまな住所形式に対応する

住所フォームを設計する際は、1 つの国の中でも住所の形式がさまざまであることを念頭に置いてください。「通常の」アドレスについて憶測しないように注意してください。（納得できない場合は、英国の住所の奇妙な点をご覧ください）。

住所フォームを柔軟にする

フォームに収まらないフィールドに住所を入力するようユーザーに強制しないでください。

たとえば、番地と番地を別々の入力で指定することは避けてください。多くの住所でこの形式が使用されず、データが不完全な場合、ブラウザの自動入力が機能しなくなる可能性があります。

特に、required アドレス フィールドには注意してください。たとえば、英国の大都市のアドレスには郡がありませんが、多くのサイトではユーザーに郡の入力を強制しています。

2 つの柔軟な住所行を使用すると、さまざまな住所形式に対応できます。

<input autocomplete="address-line-1" id="address-line1" ...>
<input autocomplete="address-line-2" id="address-line2" ...>

一致するラベルを追加します。

<label for="address-line-1">
Address line 1 (or company name)
</label>
<input autocomplete="address-line-1" id="address-line1" ...>

<label for="address-line-2">
Address line 2 (optional)
</label>
<input autocomplete="address-line-2" id="address-line2" ...>

下の埋め込みデモをリミックスして編集して、ぜひお試しください。

住所には単一の textarea を使用することを検討する

住所に対して最も柔軟なオプションは、単一の textarea を指定することです。

textarea アプローチは、任意の住所形式に対応し、カット＆ペーストに適しています。ただし、データ要件に合わない可能性があること、また、以前に address-line1 と address-line2 のフォームのみを使用していた場合、ユーザーが自動入力を利用できない可能性があることに注意してください。

textarea の場合は、autocomplete 値として street-address を使用します。

住所に単一の textarea を使用するフォームの例を次に示します。

住所フォームを国際化、ローカライズする

住所フォームでは、ユーザーの居住地に応じて国際化とローカライズを検討することが特に重要です。

同じ言語内でも、住所の部分の命名や住所の形式は異なります。

    ZIP code: US
 Postal code: Canada
    Postcode: UK
     Eircode: Ireland
         PIN: India

住所に合わないフォームや、想定している単語が使用されていないフォームが表示されると、イライラしたり、困惑したりすることがあります。

サイトによっては、複数の言語 / 地域向けに住所フォームをカスタマイズすることが必要になる場合がありますが、上記の方法でフォームの柔軟性を最大限に高めることで十分な場合もあります。住所フォームをローカライズしない場合は、さまざまな住所形式に対応するための主な優先事項を理解してください。 * 住所の一部（道路名や家屋番号など）を指定しないでください。* 可能な限り、フィールドを required にしないようにします。たとえば、多くの国では住所に郵便番号が含まれておらず、農村部の住所には番地や道路名が含まれていない場合があります。* 包括的な名前を使用します（「国」ではなく「国 / 地域」、「郵便番号」ではなく「郵便番号 / 郵便番号」など）。

柔軟性を保ちましょう。上記のシンプルな住所フォームの例は、多くの言語 / 地域で「十分に」機能するように調整できます。

郵便番号と住所の照合を回避することを検討する

一部のウェブサイトでは、郵便番号や ZIP コードに基づいて住所を検索するサービスを使用しています。これは一部のユースケースでは理にかなっているかもしれませんが、潜在的なデメリットに注意する必要があります。

郵便番号による住所候補の表示は、国によって異なります。また、地域によっては、郵便番号に多数の住所が含まれる場合があります。

郵便番号には多くの住所が含まれる場合があります。

長い住所リストから選択するのは、特に時間に追われている場合やストレスを感じている場合、モバイルでは難しいものです。ユーザーが自動入力を活用し、タップまたはクリック 1 回で完全な住所を入力できるようにするほうが、簡単で間違いが起こりにくくなります。

名前を 1 回入力するだけで、住所をワンタップ（ワンクリック）で入力できます。

支払い方法の簡素化

お支払いフォームは、購入手続きにおいて最も重要な要素です。支払いフォームの設計が不十分であることは、ショッピング カートの放棄の一般的な原因です。細部に注意する: 小さな不具合が原因で、特にモバイルではユーザーが購入を中止する可能性があります。ユーザーがデータを入力しやすくするために、フォームを設計する必要があります。

ユーザーが支払いデータを再入力しないようにする

支払いカードのフォームに、支払いカード番号、カード名義人、有効期限の月と年など、適切な autocomplete 値を必ず追加してください。

  • cc-number
  • cc-name
  • cc-exp-month
  • cc-exp-year

これにより、ブラウザは支払いカードの詳細を安全に保存し、フォームデータを正しく入力することで、ユーザーをサポートできます。オートコンプリートがないと、ユーザーは支払いカードの詳細を物理的に記録したり、支払いカードのデータを安全でない方法でデバイスに保存したりする傾向が高まります。

支払いカードの日付にカスタム要素を使用しないでください

カスタム要素を適切に設計しないと、自動入力を中断して支払いフローが中断される可能性があります。また、古いブラウザでは機能しません。他のすべてのお支払いカードの詳細が自動入力から取得できても、カスタム要素で自動入力が機能しないため、ユーザーが物理的なお支払いカードを見つけて有効期限を調べる必要がある場合、販売機会を失う可能性があります。代わりに標準の HTML 要素を使用し、それに応じてスタイルを設定することを検討してください。

自動入力を中断するカードの有効期限のカスタム要素を示す支払いフォームのスクリーンショット。
有効期限を除くすべてのフィールドが予測入力によって入力されました。

支払いカードと電話番号に単一の入力を使用する

支払いカードと電話番号は 1 回で入力します。番号を分割しないでください。これにより、ユーザーがデータを入力しやすくなり、検証が簡単になり、ブラウザで自動入力できるようになります。PIN や銀行コードなどの他の数値データについても同様に検討してください。

クレジット カード フィールドが 4 つの入力要素に分割されている支払いフォームのスクリーンショット。
クレジット カード番号には複数の番号を使用しないでください。

慎重に検証する

データ入力は、リアルタイムでもフォームの送信前にも検証する必要があります。これを行う方法の 1 つは、支払いカード入力に pattern 属性を追加することです。ユーザーが無効な値で支払いフォームを送信しようとすると、ブラウザに警告メッセージが表示され、入力にフォーカスが設定されます。JavaScript は必要ありません。

ただし、pattern 正規表現は、支払いカード番号の長さの範囲（14 桁（またはそれ以下）から 20 桁（またはそれ以上））に対応できる柔軟性が必要です。支払いカード番号の構造については、LDAPwiki をご覧ください。

新しい支払いカード番号を入力する際に、ユーザーがスペースを入力できるようにします。これは、物理的なカードに番号が表示される方法です。これにより、ユーザーにとって使いやすく（「何か問題があった」と説明しなくてよい）、コンバージョン フローが中断される可能性が低くなり、処理の前に数字のスペースを簡単に削除できます。

さまざまなデバイス、プラットフォーム、ブラウザ、バージョンでテストする

フォーム要素の機能と外観は異なる場合があり、ビューポートのサイズが異なると配置に問題が生じる可能性があるため、ユーザーが最もよく使用するプラットフォームで住所フォームと支払いフォームをテストすることが特に重要です。BrowserStack では、さまざまなデバイスとブラウザでオープンソース プロジェクトの無料テストが可能です。

iPhone 7 と 11 の支払いフォーム（payment-form.glitch.me）のスクリーンショット。[支払いを完了] ボタンが iPhone 11 には表示されるが、iPhone 7 には表示されない
iPhone 7 と iPhone 11 で同じページを表示。
モバイル ビューポートが小さい場合のパディングを減らして、[完了] ボタンが非表示にならないようにします。

アナリティクスと RUM を実装する

ローカルでユーザビリティとパフォーマンスをテストすることは有用ですが、ユーザーが支払いフォームと住所フォームをどのように使用しているかを適切に把握するには、実際のデータが必要です。

そのためには、分析とリアルユーザー モニタリングが必要です。リアルユーザー モニタリングとは、購入手続きページの読み込み時間や支払いの完了時間など、実際のユーザーの操作に関するデータです。

  • ページ分析: フォームがあるすべてのページのページビュー、離脱率、離脱ページ。
  • インタラクション アナリティクス: 目標到達プロセスとイベントは、ユーザーが購入手続きフローを放棄した場所と、フォームを操作したときにどのようなアクションを行ったかを示します。
  • ウェブサイトのパフォーマンス: ユーザー中心の指標を使用すると、購入手続きページの読み込みが遅いかどうか、遅い場合はその原因を把握できます。

ページ分析、インタラクション分析、実際のユーザーのパフォーマンス測定は、サーバーログ、コンバージョン データ、A/B テストと組み合わせると特に有用です。割引コードが収益を増やしたかどうか、フォームのレイアウトを変更するとコンバージョンが改善されるかどうかなど、さまざまな疑問に答えることができます。

これが、取り組みの優先順位付け、変更の実施、成功の評価のための確固たる基盤となります。

学習を続ける

写真撮影: @rupixen（Unsplash）