支払いフォームと住所フォームのベストプラクティス
ユーザーが住所フォームと支払いフォームにできるだけ早く簡単に記入できるようにすることで、コンバージョンを最大化します。
フォームを適切に設計することは、ユーザーを助け、利便性とコンバージョン率を向上させます。簡単な修正を 1 つ施すだけで、大きな違いが生まれます！
こちらは、すべてのベストプラクティスを取り入れた簡単な支払いフォームの 1 例です。
こちらは、すべてのベストプラクティスを取り入れた簡単な住所フォームの 1 例です。
チェックリスト #
- 用途がはっきりした HTML 要素を使用する:
<form>、<input>、<label>、<button>。 <label>を使って各フォームフィールドに ラベルを付ける。- HTML 要素の属性を使用して、組み込みのブラウザー機能にアクセスする。特に適切な値を持つ
typeとautocomplete。 - 支払いカード番号など、増加させることを意図していない番号には
type="number"を使用しない。代わりに、type="text"とinputmode="numeric"を使用する。 - 適切なオートコンプリート値を
input、select、またはtextareaに使用できる場合は、それを使用する。 - ブラウザがフォームを自動入力できるように、入力の
nameとid属性に、ページの読み込み中またはウェブサイトの展開中に変化しない安定した値を指定する。 - 一旦タップされたり、クリックされたりした送信ボタンを無効にする。
- データは、フォームの送信中だけでなく、入力中にも検証する。
- ゲストのチェックアウトをデフォルトにし、チェックアウトが完了した後にアカウントを簡単に作成できるようにする。
- 分かりやすい行動喚起による明確なステップでチェックアウトプロセスの進捗を示す。
- 混乱や気を散らすものを取り除くことにより、チェックアウトの潜在的な離脱ポイントを制限する。
- チェックアウト時に注文の完全な詳細を表示し、注文内容を簡単に調整できるようにする。
- 不要なデータの提供は求めない。
- 正当な理由がない限り、名前は単一の入力で求める。
- 名前とユーザー名には、ラテン文字以外の文字も入力できるようにする。
- さまざまなアドレス形式を許可する。
- アドレスに 1 つの
textareaだけを使用することを検討する。 - 請求先住所の入力にオートコンプリートを使用する。
- 必要に応じて国際化およびローカライズする。
- 郵便番号による住所検索を使わないことを検討する。
- 支払いカードのオートコンプリートの適切な値を使用します。
- 支払いカード番号には単一の入力を使用する。
- オートフィルの使用体験を損なわせるようなカスタム要素の使用は避ける。
- 現場とラボの両方でテストるす: ページ分析、インタラクション分析、および実際のユーザーのパフォーマンス測定。
- さまざまなブラウザ、デバイス、プラットフォームでテストする。
用途がはっきりした 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 つのラベルだけで複数の入力にラベルを付けようとしてはいけません。これは、ブラウザにも、スクリーンリーダーにも最適なことです。ラベルをタップまたはクリックすると、フォーカスが関連付けられている入力に移動し、スクリーンリーダーは、label またはラベルの input にフォーカスが移動したときにラベルテキストをアナウンスします。
ボタンを便利なものにする #
ボタンには <button> を使用してください！<input type="submit"> を使用することもできますが、divやその他の不適切な要素は使用しないようにしましょう。ボタン要素は、アクセス可能な動作や組み込みのフォーム送信機能を提供します。スタイルも簡単に指定できます。
各フォーム送信ボタンには、その機能が分かる値を指定します。チェックアウトに向かう各ステップで、進捗状況を示し、次のステップを明確にする説明的な行動喚起を使用します。たとえば、配送先住所フォームの送信ボタンには、[続行] や [保存] の代わりに、[支払いに進む] といったラベルを付けます。
ユーザーが送信ボタンをタップまたはクリックしたとき (特に支払いや注文をするとき) には送信ボタンを無効にするということを検討してください。正常に機能しているボタンを何度も繰り返しクリックするユーザーはたくさんいます。それが原因で、チェックアウトが正常に行われず、サーバーに負荷を与えてしまう場合があります。
一方で、完全かつ有効なユーザー入力を待っている送信ボタンを無効にしてはいけません。たとえば、何かが不足している、または無効であるからといって、[アドレスを保存] ボタンを無効のままにしてはいけません。ユーザーにとって不便な上に、ユーザーはボタンを何度もタップしたり、クリックしたりして、ボタンが壊れていると勘違いする可能性があります。代わりに、無効なデータが含まれたフォームをユーザーが送信しようとした場合は、何がおかしいのか、どうすれば修正できるのかを説明しましょう。モバイルでは特に重要なことです。モバイルでは、データを入力しにくいほか、フォームデータに未記入の箇所や無効な箇所があっても、ユーザーがフォームを送信しようとするまでは画面の枠から外れて見えない場合があります。
Enter キーを押すと、submit ボタンのクリックがシミュレートされます。フォームの[送信]ボタンの前に別のボタンを含め、かつそのタイプを指定しない場合、そのボタンはフォームのボタンのデフォルトのタイプ、つまり submit となり、フォームが送信される前にクリックイベントを受け取ります。この例については、デモ: fill in the form, then press Enter (フォームに記入して [Enter] を押す) を参照してください。
HTML 属性を最大限に活用する #
データを入力しやすくする #
type 属性を使用して、モバイルで適切なキーボードを提供し、ブラウザーによる基本的な組み込み検証を有効にします。
たとえば、メールアドレスには type="email"、電話番号には type="tel" を使用します。
日付に 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 といった許容値を指定できます。要素の有効性状態は、要素の値が有効かどうかに応じて自動的に設定されます。値が有効であるか無効であるかを問わずに要素のスタイル指定をすることに使用できる CSS の疑似クラス :valid および :invalid も同様に設定されます。
たとえば、次の HTML は、1900年から2020年の間の誕生年の入力を指定します。type="number" の制約を使用すると、入力値は min と max で指定された範囲内の数値のみに制限されます。この範囲外の数値を入力しようとすると、入力は無効な状態に設定されます。
次の例では、 pattern="[\d ]{10,30}" を使用して、スペースを許可しながら、有効な支払いカード番号を確認します。
最近のブラウザは、タイプが email</cod> または <code data-md-type="codespan">url の入力に対して基本的な検証も行います。
フォームの送信時に、ブラウザは、自動的に問題のあるフィールドや未記入の必須フィールドにフォーカスをあてます。 JavaScript は必要ありません！
ユーザーが送信ボタンをクリックしたときにエラーの一覧を表示するのではなく、インラインで検証し、ユーザーがデータを入力するときにフィードバックを提供します。フォームの送信後にサーバー上のデータを検証する必要がある場合は、見つかったすべての問題を一覧表示し、無効な値を持つすべてのフォームフィールドを明確に強調表示し、問題のある各フィールドの横に修正が必要なことを説明するメッセージをインラインで表示します。サーバーログと分析データで一般的なエラーを確認してください。フォームの再設計が必要になる場合があります。
また、ユーザーがデータを入力しているときやフォームを送信しているときは、JavaScript を使ってより堅牢な検証を行う必要があります。(幅広くサポートされている) Constraint Validation API を使用すれば、ブラウザの組み込み UI を使ってカスタム検証を追加して、フォーカスを設定し、プロンプトを表示できます。
詳しくは、Use JavaScript for more complex real-time validation (一層複雑なリアルタイム検証には JavaScript を使う) をご覧ください。
必須データの記入忘れがないようにユーザーをサポートする #
必須の値については、入力に required 属性 を使用します。
フォームが送信されると、最新のブラウザは、自動的にプロンプトを表示し、データが入力されていない required フィールドにフォーカスを移動させます。:required 疑似クラスを使用すると、必須フィールドを強調表示できます。JavaScript は必要ありません！
必須フィールドのラベルにアスタリスクを追加し、フォームの先頭にアスタリスクの意味を説明するメモを追加します。
チェックアウトを簡素化する #
モバイルコマースのギャップに注意する！ #
関心を維持するための予算などというものがあるとすれば、それを使い果たしてしまうと、ユーザーはサイトから去って行くでしょう。
特にモバイルでは、摩擦を減らし、集中力を維持する必要があります。多くのサイトでは、トラフィックはモバイルの方が多くなりますが、コンバージョンはデスクトップの方が多くなります。これは、モバイルコマースギャップとして知られる現象です。顧客はデスクトップで購入手続きを済ませることを好むかもしれませんが、モバイルのコンバージョン率が低いのは、ユーザーエクスペリエンスが乏しいことにも起因します。あなたの仕事は、モバイルで失われるコンバージョンを最小限に抑え、デスクトップでのコンバージョンを最大限に高めることです。ある調査によると、モバイルにおけるフォームの使用体験をもっと快適にできる大きなチャンスがあると分かっています。
ユーザーは、何よりも、長くて、複雑で、目的のはっきりしないフォームを放棄する傾向が強いです。これは、ユーザーが小さな画面を使っている、集中していない、または急いでいるときなどは、なおさら言えることです。ユーザーに求めるデータは、極力少なく抑えましょう。
ゲストチェックアウトをデフォルトにする #
オンラインストアの場合、フォームの摩擦を減らす最も簡単な方法は、ゲストのチェックアウトをデフォルトにすることです。購入する前にユーザーにアカウントの作成を強制しないでください。ショッピングカートを放棄する主な理由として、ゲストとしてチェックアウトすることが許可されていないことが挙げられます。
アカウントのサインアップは、チェックアウトの後に提供するとよいでしょう。その時点で、アカウントを設定するために必要なデータはほぼすべて揃っているため、ユーザーはアカウントをすばやく、簡単に作成できます。
チェックアウトの進捗状況を表示する #
進捗状況を表示し、次に何をする必要があるかを明確にすることで、チェックアウトプロセスの複雑さを軽減できます。以下の動画は、英国の小売業者 johnlewis.com がこれ成し遂げている方法を紹介しています。
ペースを最後まで維持する必要があります！支払いに向けた各ステップでは、ページの見出しと説明的なボタンの値を使用して、今何をする必要があるか、チェックアウトの次のステップは何かを明確にします。
enterkeyhint 属性を使用して、モバイル用キーボードの Enter キーのラベルを設定します。例えば、enterkeyhint="previous" とenterkeyhint="next" は複数ページのフォーム内に、enterkeyhint="done" はフォームの最終入力に、そして enterkeyhint="search" は検索入力に使用します。
enterkeyhint 属性は、Android と iOSでサポートされています。詳細については、enterkeyhint の説明をご覧ください。
ユーザーがチェックアウトプロセスの中を簡単に戻ったり、進んだりできるようにし、支払の最終段階でも注文を簡単に調整できるようにします。注文内容は、簡単な内訳ではなく、詳細をすべて表示します。ユーザーが支払いページからアイテムの数量を簡単に調整できるようにします。チェックアウト時の優先事項は、コンバージョンに向けた進捗を妨げないことです。
気が散る原因を取り除く #
製品のプロモーションなど、視野に入ってくるものや、気が散る原因となるものを取り除き、離脱ポイントが生まれる可能性を制限します。実績ある小売業者の多くは、チェックアウトからナビゲーションや検索機能まで削除しています。
チェックアウトだけに集中できるようにしましょう。ここは、ユーザーを誘惑する場面ではありません！
リピーターの場合、表示する必要のないデータを非表示にすることで、チェックアウトフローをさらに簡素化できます。例: 配送先住所を (フォームではなく) プレーンテキストで表示し、ユーザーがリンクを使って住所を変更できるようにします。
名前と住所を簡単に入力できるようにする #
必要なデータのみを要求する #
名前フォームと住所フォームのコーディングを開始する前に、必要なデータを把握をしておく必要があります。要らないデータは求めないようにしましょう！フォームの複雑さを軽減する最も簡単な方法は、不要なフィールドを削除することです。これはお客様のプライバシー保護にも役立ち、バックエンドデータのコストと責任を減らすことができます。
単一の名前入力を使用する #
名や姓、敬語、名前の他の部分を個別に保存する妥当な理由がない限り、名前は単一入力を使って入力できるようにします。名前に単一入力を使用すると、フォームの複雑さが軽減され、カットアンドペーストが可能になり、自動入力も簡単になります。
特に、そうしないことが妥当だと思われる理由がない限り、敬称や肩書 (Mrs、Dr、Lord など) に個別の入力を追加する必要はありません。必要だと思えば、名前を一緒に記入できます。また、 honorific-prefix オートコンプリートは現在ほとんどのブラウザで機能しないため、名前の敬称や肩書のフィールドを追加すると、ほとんどのユーザーに対しアドレスフォームのオートフィル機能の使用体験が損なわれてしまいます。
名前の自動入力を有効にする #
フルネームに name を使用します。
<input autocomplete="name" ...>名前を細かく分割する妥当な理由がある場合は、適切なオートコンプリート値を使用してください。
honorific-prefixgiven-namenicknameadditional-name-initialadditional-namefamily-namehonorific-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} \-]+" ...>
アドレスのさまざまな形式を許可する #
住所フォームを設計するときは、1 つの国にもビックリするぼど多彩な住所形式があることを覚えておきましょう。「普通」の住所形式は存在しませんので注意してください。信じられないという方は、UK Address Oddities (一風変わったイギリスの住所) をご覧ください。
住所形式に柔軟性を持たせる #
形式の異なるフォームフィールドへの住所入力を必須にしてはいけません。
たとえば、多くの住所には異なる形式が使用されており、不完全なデータはブラウザのオートフィル機能に支障をきたす可能性があるため、番地や通りの名前の入力を分けることにこだわってはいけません。
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" ...>これを試すには、以下に埋め込まれているデモをリミックスして編集します。
住所に 1 つの textarea を使用することを検討する #
アドレスの最も柔軟なオプションは、1 つの textarea を提供することです。
textarea を使うアプローチは、どの住所形式にも適合するほか、切り取りと貼り付けにも最適です。ただし、データ要件に合わない場合もあり、それまでに address-line1 と address-line2 だけが使われたフォームしか使用したことがないユーザーは自動入力を使いこなせない可能性があることを心に留めておきましょう。
テキストエリアの場合は、street-address をオートコンプリート値として使用します。
こちらは、住所に 1 つの textarea が使用されたフォームの例です。
住所フォームを国際化、ローカライズする #
住所フォームでは、ユーザーの所在地に応じて、国際化とローカリゼーションを検討することがとりわけ重要になります。
同じ言語内であっても、アドレス部分の名前はアドレス形式と同様に異なりますので注意が必要です。
ZIP code: US
Postal code: Canada
Postcode: UK
Eircode: Ireland
PIN: India自分の住所形式に合わないフォームや想定外の用語が使用されたフォームが表示されると、イライラしたり、困惑したりしかねません。
サイトではアドレスフォームを複数のロケールに対応できるようにカスタマイズする必要があるかもしれませんが、上述したテクニックでフォームの柔軟性を最大化するだけで十分な場合もあります。住所フォームをローカライズしない場合は、さまざまな住所形式に対処するために優先すべき事柄を把握しておきましょう。
- 通りの名前や番地を必須にするなど、住所の各部分について細かくこだわり過ぎるのは避けましょう。
- 可能であれば、フィールドを
requiredにするのは避けましょう。たとえば、多くの国の住所には郵便番号がなく、地方の住所には通りや道路の名前がない場合があります。 - 「国」ではなく「国/地域」、「ZIP」ではなく「ZIP /郵便番号」といった具合に、インクルーシブな名前を使用します。
柔軟性を保ちましょう！先ほど紹介したシンプルな住所の例は、多くのロケールに「十分」適応させることができます。
郵便番号による住所検索を使わないことを検討する #
一部のウェブサイトでは、郵便番号に基づいて住所を検索するサービスが使用されます。一部のユースケースでは実用的で良いかもしれませんが、デメリットがあることも認識しておく必要があります。
郵便番号による住所の提案は、すべての国で機能するわけではありません。一部の地域では、郵便番号に膨大な数の住所が含まれる場合があります。
アドレスの長いリストから選択することはユーザーにとって困難でしょう。特に、急いでいる場合やストレスを感じている場合に、モバイルで選択するのは大変です。ユーザーが自動入力を利用して、シングルタップまたはクリックで完全な住所を自動的に入力できるようにすれば、楽な上に、エラーも出にくくなります。
支払いフォームを簡素化する #
支払いフォームは、チェックアウトプロセスの最も重要な部分です。設計の悪い支払いフォームは、ショッピングカート放棄の一般的な原因となっています。悪魔は細部に宿るとはよく言ったものです。特にモバイルの場合は、小さな不具合があるだけで、ユーザーに購入を放棄させてしまいかねません。あなたの仕事は、ユーザーができるだけ簡単にデータを入力できるフォームを設計することです。
ユーザーが支払いデータを再入力しなくて済むようにする #
支払いカードフォームには、支払いカード番号、カードの名義人の名前、有効期限の年と月といった適切な autocomplete 値を必ず追加してください。
cc-numbercc-namecc-exp-monthcc-exp-year
これにより、ブラウザは支払いカードの詳細を安全に保存し、フォームデータを正しく入力することでユーザーを支援できます。オートコンプリートがないと、ユーザーは支払いカードの詳細に関する物理的な記録を保管したり、支払いカードのデータを安全でないかたちでデバイスに保存したりする傾向が強くなります。
支払いカードの日付にカスタム要素を使用しない #
カスタム要素は、適切に設計されていないと、自動入力に支障をきたし、支払いフローを中断させてしまう可能性があります。また、古いブラウザでは機能しません。支払いカードの他のすべての詳細はオートコンプリートで利用できても、カスタム要素の自動入力が機能しなかったために、ユーザーが物理的な支払いカードを探してまでカードの有効期限を調べることになれば、売り上げを失う可能性が高くなります。代わりに標準の HTML 要素を使用することを検討し、それに応じてスタイルを設定することを検討しましょう。
支払いカードと電話番号に単一の入力を使用する #
支払いカードと電話番号には、単一の入力を使用します。番号を分割してはいけません。単一の入力を使用することで、ユーザーはデータを入力しやすくなり、検証が簡単になり、ブラウザで自動入力も使用できます。PIN や銀行コードといった他の数値データについても同じことを検討してください。
検証は慎重に #
データ入力は、リアルタイムに、そしてフォーム送信前にも検証する必要があります。これを行う方法の 1 つに、支払いカード入力に pattern 属性を追加するという手があります。ユーザーが無効な値を入力して支払いフォームを送信しようとすると、ブラウザーは警告メッセージを表示し、入力要素にフォーカスを移動させます。JavaScript は必要ありません！
ただし、正規表現 pattern は、支払いカード番号の桁数 (14 以上 ～ 20 桁以下) を処理できるほど柔軟でなくてはいけません。支払いカード番号の構成について詳しくは、LDAPwiki でご確認いただけます。
物理的なカードの番号はスペースを挟んで表示されるため、ユーザーが新しい支払いカード番号を入力するときにはスペースを含められるようにします。その方が、ユーザーにとっては扱いやすいし (何かミスをしたと指摘しなくてすみます)、コンバージョンのフローを中断させる可能性も低いし、処理する前に簡単に数字の間のスペースを削除できます。
さまざまなデバイス、プラットフォーム、ブラウザ、バージョンでテストする #
フォーム要素の機能と外観は異なる場合があり、ビューポートのサイズの違いにより配置に問題が出る可能性もあるため、住所フォームと支払いフォームはユーザーが一番使い慣れたプラットフォームでテストすることが特に重要になります。BrowserStack を使用すると、さまざまなデバイスやブラウザでオープンソースプロジェクトを無料でテストすることができます。
モバイルの小さいビューポートのパディングを減らす。
分析と RUM を実装する #
ユーザビリティとパフォーマンスをローカルでテストすることが役立つ場合もありますが、ユーザーによる支払いフォームと住所フォームの使用体験を正しく理解するには、実際のデータが必要です。
それには、分析と Real User Monitoring (リアルユーザーモニタリング) が必要です。チェックアウトページの読み込みにかかる時間や支払いが完了するまでにかかる時間など、実際のユーザーによる使用体験に関するデータです。
- ページ分析: フォームが含まれたすべてのページの閲覧回数、バウンス率、離脱。
- インタラクション分析: goal funnels と events は、ユーザーがチェックアウトフローを放棄する場所およびユーザーがフォームに入力する際に実行するアクションを示します。
- ウェブサイトのパフォーマンス: ユーザー中心の指標は、チェックアウトページの読み込みが遅いかどうか、および遅い場合の原因を示唆します。
ページ分析、インタラクション分析、および実際のユーザーパフォーマンスの評価は、サーバーログ、コンバージョンデータ、A / B テストと組み合わせると特に価値が高くなり、割引コードによって収益が増えるかどうか、フォームレイアウトを変更すればコンバージョンが改善されるかどうかなどの疑問に答えられます。
結果、注力の優先度を決定する、変更を加える、得られた成果に対して報酬を与えることについて、しっかりとした根拠が見つかります。
学習を続けましょう #
- Sign-up form best practices (サインアップフォームのベストプラクティス)
- Sign-in form best practices (サインアップフォームのベストプラクティス)
- WebOTP APIを使用してウェブ上の電話番号を確認する
- Create Amazing Forms (すばらしいフォームを作成する)
- Best Practices For Mobile Form Design (モバイルフォームデザインのベストプラクティス)
- More capable form controls (より細かく機能するフォームコントロール)
- Creating Accessible Forms (使いやすいフォームの作成)
- Streamlining the Sign-up Flow Using Credential Management API (認証情報管理 API を使用したサインアップフローの合理化)
- 『Frank's Compulsive Guide to Postal Addresses』は、200 か国以上で使用される住所形式に関する便利なリンクと広範なガイダンスを提供します。
- 国リストには、国コードと名前を複数の言語かつ複数の形式でダウンロードするためのツールが用意されています。
写真の提供者: Unsplash の @rupixen。