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

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

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 Web Docs をご覧ください。

安定した値

請求先住所

デフォルトでは、請求先住所を配送先住所と同じに設定します。請求先住所をフォームに表示するのではなく、請求先住所を編集するためのリンクを表示（または 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" を使用します。

Android の住所フォームの 2 つのスクリーンショット。enterkeyhint 入力属性によってエンターキー ボタンのアイコンがどのように変わるかを示しています。
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）