このページは Cloud Translation API によって翻訳されました。

ログインフォームのベストプラクティス

クロスプラットフォームのブラウザ機能を使用して、安全でアクセスしやすく、使いやすいログインフォームを作成します。

Sam Dutton

ユーザーがサイトにログインする必要がある場合は、ログインフォームの適切な設計が重要です。これは、接続が不安定な場合、モバイルを使用している場合、急いでいる場合、ストレスを感じている場合に特に当てはまります。ログインフォームの設計が不適切だと、直帰率が高くなります。1 回の離脱は、ログイン機会を逃しただけでなく、ユーザーの離脱と不満を招く可能性があります。

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

チェックリスト

意味のある HTML 要素（<form>、<input>、<label>、<button>）を使用する。
各入力に <label> というラベルを付けます。
要素属性を使用して、組み込みのブラウザ機能にアクセスします。type、name、autocomplete、required。
入力 name 属性と id 属性に、ページの読み込みやウェブサイトのデプロイ間で変化しない安定した値を指定します。
ログインを独自の <form> 要素に配置します。
フォームが正常に送信されるようにする。
登録フォームのパスワード入力と、パスワードリセットフォームの新しいパスワードには、autocomplete="new-password" と id="new-password" を使用します。
ログインパスワードの入力には autocomplete="current-password" と id="current-password" を使用します。
[パスワードを表示] 機能を提供します。
パスワード入力には aria-label と aria-describedby を使用します。
入力を重複させないでください。
モバイルキーボードが入力やボタンを隠さないようにフォームを設計します。
フォームがモバイルで使用可能であることを確認する: 判読しやすいテキストを使用し、入力とボタンがタップターゲットとして機能するのに十分な大きさであることを確認します。
登録ページとログインページのブランディングとスタイルを維持する。
ラボだけでなく現場でもテストする: ページ分析、インタラクション分析、ユーザー中心のパフォーマンス測定を、登録フローとログインフローに組み込みます。
ブラウザとデバイス間でテストする: フォームの動作はプラットフォームによって大きく異なります。

注: この記事では、フロントエンドのベストプラクティスについて説明します。ユーザーの認証、認証情報の保存、アカウントの管理を行うバックエンドサービスを構築する方法については説明しません。ユーザーアカウント、認証、パスワード管理に関する 12 のベストプラクティスでは、独自のバックエンドを運用するための基本原則について説明しています。世界中のさまざまな地域にユーザーがいる場合は、サイトのサードパーティの ID サービスとコンテンツのローカライズを検討する必要があります。この記事では取り上げていない、より新しい API が 2 つあります。これらは、より優れたログインエクスペリエンスの構築に役立ちます。* WebOTP: ワンタイムパスコードまたは PIN 番号を SMS でモバイルフォンに配信します。これにより、ユーザーは識別子として電話番号を選択できます（メールアドレスを入力する必要はありません）。また、ログイン用の 2 段階認証プロセスと、支払い確認用の 1 回限りのコードも有効になります。* 認証情報の管理: 開発者がパスワード認証情報と連携認証情報をプログラムで保存、取得できるようにします。

有意な HTML を使用する

ジョブ用に作成された要素（<form>、<label>、<button>）を使用します。これらにより、ブラウザの組み込み機能を有効にし、ユーザー補助を改善し、マークアップに意味を追加できます。

`<form>`

入力を <div> でラップし、入力データの送信を JavaScript でのみ処理したくなるかもしれません。通常は、従来の <form> 要素を使用することをおすすめします。これにより、サイトをスクリーンリーダーやその他の支援デバイスで利用可能にし、さまざまな組み込みブラウザ機能を有効にします。また、古いブラウザ向けの基本的な機能のログインを簡単に構築でき、JavaScript が失敗しても機能します。

`<label>`

入力にラベルを付けるには、<label> を使用します。

<label for="email">Email</label>
<input id="email" …>

理由は次の 2 つです。

ラベルをタップまたはクリックすると、フォーカスが入力に移動します。ラベルの for 属性と入力の name または id を使用して、ラベルを入力に関連付けます。
スクリーンリーダーは、ラベルまたはラベルの入力にフォーカスが当たると、ラベルのテキストを読み上げます。

入力ラベルとしてプレースホルダを使用しないでください。入力を開始した後、特に気を散らされた場合（「メールアドレス、電話番号、アカウント ID のどれを入力していた？」）は、入力の目的を忘れてしまう可能性があります。プレースホルダには他にも多くの潜在的な問題があります。まだ納得できない場合は、プレースホルダ属性を使用しないでくださいとフォームフィールドのプレースホルダは有害ですをご覧ください。

ラベルは入力の上に配置することをおすすめします。これにより、モバイルとパソコンでデザインを統一できます。また、Google AI の調査によると、ユーザーによるスキャンが速くなります。ラベルと入力項目は幅いっぱいに表示され、ラベルテキストに合わせてラベルと入力項目の幅を調整する必要はありません。

モバイルでのフォーム入力ラベルの位置（入力の横と入力の上）を示すスクリーンショット。 — ラベルと入力の両方が同じ行にある場合、ラベルと入力の幅は制限されます。

モバイルデバイスで label-position グリッチを開いて確認してください。

`<button>`

ボタンには <button> を使用します。ボタン要素は、ユーザー補助に対応した動作とフォーム送信機能を備えており、簡単にスタイル設定できます。<div> やボタンに見せかけた他の要素を使用する意味はありません。

送信ボタンにその機能が明記されていることを確認します。たとえば、[アカウントを作成] や [ログイン] は使用できますが、[送信] や [開始] は使用できません。

フォームが正常に送信されたことを確認する

フォームが送信されたことをパスワードマネージャーに伝えます。これを行うには 2 つの方法があります。

別のページに移動します。
History.pushState() または History.replaceState() でナビゲーションをエミュレートし、パスワードフォームを削除します。

XMLHttpRequest リクエストまたは fetch リクエストでは、ログイン成功がレスポンスで報告され、DOM からフォームを削除して、ユーザーに成功を通知するように処理します。

ユーザーが [ログイン] ボタンをタップまたはクリックしたら、そのボタンを無効にすることを検討してください。多くのユーザーは、高速でレスポンシブなサイトでもボタンを複数回クリックします。これにより、インタラクションの速度が低下し、サーバーの負荷が増加します。

逆に、ユーザー入力を待機してフォームの送信を無効にしないでください。たとえば、お客様がお客様 PIN を入力していない場合でも、[ログイン] ボタンを無効にしないでください。ユーザーがフォームの入力を間違えて、無効になっている [ログイン] ボタンを何度もタップして、機能していないと判断する場合があります。フォームの送信を無効にする必要がある場合は、少なくとも、無効なボタンをクリックしたときに不足している内容をユーザーに説明してください。

注意: フォーム内のボタンのデフォルトのタイプは submit です。フォームに別のボタン（パスワードを表示など）を追加する場合は、type="button" を追加します。それ以外の場合は、ボタンをクリックまたはタップするとフォームが送信されます。任意のフォームフィールドにフォーカスがあるときに Enter キーを押すと、フォーム内の最初の submit ボタンがクリックされたことになります。フォームに [送信] ボタンの前にボタンを追加し、タイプを指定しない場合、そのボタンはフォーム内のボタンのデフォルトタイプ（submit）になり、フォームが送信される前にクリックイベントを受け取ります。例については、デモをご覧ください。フォームに入力して Enter を押します。

入力を重複させない

一部のサイトでは、メールアドレスやパスワードを 2 回入力する必要があります。これにより、一部のユーザーのエラーは減るかもしれませんが、すべてのユーザーに余分な作業が発生し、放棄率が増加します。ブラウザでメールアドレスが自動入力されたり、強力なパスワードが提案されたりする場合は、2 回尋ねる必要もありません。ユーザーがメールアドレスを確認できるようにし（いずれにしても確認する必要があります）、必要に応じてパスワードを簡単にリセットできるようにすることをおすすめします。

要素属性を最大限に活用する

これが魔法の瞬間です。ブラウザには、入力要素の属性を使用する便利な組み込み機能が複数あります。

パスワードを非公開にしながら、ユーザーが希望する場合はパスワードを表示できるようにする

パスワード入力には type="password" を指定する必要があります。これにより、パスワードテキストが非表示になり、入力がパスワードであることをブラウザが認識できるようになります。（ブラウザはさまざまな手法を使用して入力ロールを理解し、パスワードの保存を提案するかどうかを決定します）。

ユーザーが入力したテキストを確認できるように、[パスワードを表示] 切り替えボタンを追加します。また、[パスワードをお忘れの場合] リンクも忘れずに追加してください。パスワードの表示を有効にするをご覧ください。

パスワードを表示アイコンが表示された Google ログインフォーム。 — Google ログインフォームからのパスワード入力: [**パスワードを表示**] アイコンと [**パスワードをお忘れの場合**] リンクがあります。

モバイルユーザーに適切なキーボードを提供する

<input type="email"> を使用すると、モバイルユーザーに適切なキーボードを提供し、ブラウザによる基本的な組み込みのメールアドレス検証を有効にできます。JavaScript は必要ありません。

メールアドレスではなく電話番号を使用する必要がある場合は、<input type="tel"> を使用してモバイルで電話キーパッドを有効にします。必要に応じて inputmode 属性を使用することもできます。inputmode="numeric" は PIN 番号に最適です。詳しくは、inputmode について知りたかったことのすべてをご覧ください。

注意: type="number" は、数字を増やすために上下矢印を追加します。ID やアカウント番号など、増やすことを意図していない数字には使用しないでください。

モバイルキーボードが [ログイン] ボタンを妨げないようにする

注意しないと、モバイルキーボードがフォームを覆ってしまうことがあります。最悪の場合、[ログイン] ボタンが部分的に隠れてしまうこともあります。ユーザーは、何が起きたのかを理解する前にあきらめてしまう可能性があります。

Android スマートフォンのログインフォームのスクリーンショット 2 枚: 1 枚は、送信ボタンがスマートフォンのキーボードで隠れている様子を示しています。 — [**ログイン**] ボタン: 表示されたと思ったら、消えてしまう。

可能であれば、ログインページの上部にメールアドレス/電話番号とパスワードの入力欄と [ログイン] ボタンのみを表示して、この問題を回避してください。その他のコンテンツは下に配置します。

Android スマートフォンのログインフォームのスクリーンショット: ログインボタンがスマートフォンのキーボードで隠れていません。 — キーボードが [**ログイン**] ボタンを隠さない。

さまざまなデバイスでテスト

ターゲットオーディエンスのさまざまなデバイスでテストし、必要に応じて調整する必要があります。BrowserStack では、さまざまな実際のデバイスとブラウザでオープンソースプロジェクトの無料テストが可能です。

iPhone 7、8、11 のログインフォームのスクリーンショット。iPhone 7 と iPhone 8 では、ログインボタンがスマートフォンのキーボードで隠れていますが、iPhone 11 では隠れません — [**ログイン**] ボタン: iPhone 7 と iPhone 8 では隠れていますが、iPhone 11 では表示されません。

2 つのページを使用することを検討する

一部のサイト（Amazon や eBay など）では、メールアドレス/電話番号とパスワードを 2 つのページで尋ねることで、この問題を回避しています。このアプローチは、ユーザーが一度に 1 つのタスクのみを実行するため、エクスペリエンスも簡素化されます。

Amazon ウェブサイトのログインフォームのスクリーンショット: メールアドレス/電話番号とパスワードが 2 つの異なる「ページ」に表示されています。 — 2 段階認証: メールアドレスまたは電話番号、パスワード

理想的には、単一の <form> で実装する必要があります。JavaScript を使用して、最初はメール入力のみを表示し、非表示にしてパスワード入力を表示します。メールアドレスとパスワードの入力の間にユーザーに新しいページに移動していただく必要がある場合は、パスワードマネージャーが正しい値を保存できるように、2 番目のページのフォームにメールアドレス値を含む非表示の入力要素を配置する必要があります。Chromium が認識するパスワードフォームスタイルにコード例を示します。

ユーザーがデータを再入力しなくて済むようにする

ブラウザがデータを正しく保存し、入力を自動入力できるようにすることで、ユーザーはメールアドレスとパスワードの値を覚えておく必要がなくなります。これはモバイルでは特に重要であり、離脱率が高いメール入力では不可欠です。

このプロセスは 2 つの部分で構成されています。

autocomplete、name、id、type 属性は、入力の役割をブラウザに理解させ、後で自動入力に使用できるデータを保存するのに役立ちます。自動入力用にデータを保存できるようにするには、最新のブラウザでは、入力に安定した name または id 値（ページの読み込みやサイトのデプロイごとにランダムに生成されない値）が設定されていること、および submit ボタンのある <form> 内に入力されていることも必要です。
autocomplete 属性は、保存されたデータを使用してブラウザが入力を正しく自動入力できるようにします。

メール入力には autocomplete="username" を使用します。username は最新のブラウザのパスワードマネージャーで認識されるためです。ただし、type="email" を使用する必要があり、id="email" と name="email" を使用することをおすすめします。

パスワード入力では、適切な autocomplete 値と id 値を使用して、ブラウザが新しいパスワードと現在のパスワードを区別できるようにします。

`autocomplete="new-password"` と `id="new-password"` を使用して新しいパスワードを作成

autocomplete="new-password" と id="new-password" は、登録フォームのパスワード入力や、パスワード変更フォームの新しいパスワードに使用します。

既存のパスワードに `autocomplete="current-password"` と `id="current-password"` を使用する

ログインフォームのパスワード入力や、パスワード変更フォームのユーザーの古いパスワードの入力には、autocomplete="current-password" と id="current-password" を使用します。これにより、サイトに保存されている現在のパスワードを使用するようにブラウザに指示します。

登録フォームの場合:

<input type="password" autocomplete="new-password" id="new-password" …>

ログインの場合:

<input type="password" autocomplete="current-password" id="current-password" …>

パスワードマネージャーをサポートする

ブラウザによってメールの自動入力とパスワードの候補の処理方法は若干異なりますが、効果はほぼ同じです。たとえば、パソコンの Safari 11 以降では、パスワードマネージャーが表示され、利用可能な場合は生体認証（指紋認証または顔認識）が使用されます。

パソコン版 Safari でのログインプロセスの 3 つのステージ（パスワードマネージャー、生体認証、自動入力）のスクリーンショット。 — 予測入力によるログイン - テキスト入力は不要です。

パソコン版 Chrome では、メールの候補が表示され、パスワードマネージャーが表示され、パスワードが自動入力されます。

パソコン版 Chrome のログインプロセスの 4 つのステージ（メールの入力、メールの候補、パスワードマネージャー、選択時の自動入力）のスクリーンショット。 — Chrome 84 の自動入力ログインフロー。

ブラウザのパスワードと自動入力システムは単純ではありません。値の推測、保存、表示のアルゴリズムは標準化されておらず、プラットフォームによって異なります。たとえば、Hidde de Vries は次のように指摘しています。「Firefox のパスワードマネージャーは、ヒューリスティクスをレシピシステムで補完しています。」

name と autocomplete の使用については、自動入力: ウェブデベロッパーが知っておくべきことで詳しく説明しています。HTML 仕様には、使用できる 59 個の値がすべて記載されています。

注: 登録フォームとログインフォームの form 要素自体、および input、select、textarea 要素で、異なる name 値と id 値を使用すると、パスワードマネージャーの動作を改善できます。

ブラウザで安全なパスワードを提案する

最新のブラウザでは、ヒューリスティクスを使用して、パスワードマネージャーの UI を表示するタイミングを決定し、安全なパスワードを提案します。

パソコン版 Safari では、次のように処理されます。

デスクトップ版 Firefox のパスワードマネージャーのスクリーンショット。 — Safari でのパスワード候補フローの変更

（安全で一意のパスワードの候補は、Safari バージョン 12.0 以降で利用できます）。

ブラウザにパスワード生成機能が組み込まれているため、ユーザーとデベロッパーは「強力なパスワード」とは何かを理解する必要はありません。ブラウザはパスワードを安全に保存し、必要に応じて自動入力できるため、ユーザーがパスワードを覚えたり入力したりする必要はありません。ブラウザに組み込まれているパスワード生成ツールの利用をユーザーに促すことで、サイトで一意の強力なパスワードを使用する可能性が高まり、他の場所で不正使用される可能性のあるパスワードを再利用する可能性が低くなります。

ユーザーが誤って入力を省略しないようにする

メールアドレスフィールドとパスワードフィールドの両方に required 属性を追加します。最新のブラウザでは、不足しているデータに対して自動的にプロンプトを表示し、フォーカスを設定します。JavaScript は必要ありません。

データが不足している場合に表示される「このフィールドに入力してください」というプロンプトが表示されている、デスクトップ版 Firefox と Chrome for Android のスクリーンショット。 — デスクトップ版 Firefox（バージョン 76）と Android 版 Chrome（バージョン 83）で、データが不足している場合にプロンプトを表示し、フォーカスを合わせます。

指と親指向けに設計する

入力要素やボタンに関連するほぼすべてのデフォルトのブラウザサイズは、特にモバイルでは小さすぎます。一見当たり前のように思えますが、多くのサイトのログインフォームでよく見られる問題です。

入力とボタンが十分な大きさであることを確認する

入力フィールドとボタンのデフォルトのサイズとパディングは、デスクトップでは小さすぎ、モバイルではさらに小さすぎます。

パソコン版 Chrome と Chrome for Android のスタイル設定されていないフォームのスクリーンショット。

Android のアクセシビリティガイダンスによると、タッチスクリーンオブジェクトのターゲットサイズは 7 ～ 10 mm 程度にすることをおすすめします。Apple のインターフェースガイドラインでは 48x48 px、W3C では 44x44 CSS ピクセル以上を推奨しています。そのうえで、モバイルの場合は入力要素とボタンに 15 ピクセル程度、パソコンの場合は 10 ピクセル程度のパディングを追加します。実際のモバイルデバイスと実際の指または親指で試してみてください。各入力とボタンを快適にタップできる必要があります。

タップターゲットのサイズが適切ではない Lighthouse 監査を使用すると、サイズが小さすぎる入力要素を検出するプロセスを自動化できます。

親指を考慮したデザイン

「タップターゲット」を検索すると、人差し指の写真がたくさん表示されます。しかし、実際には多くの人が親指でスマートフォンを操作しています。親指は人差し指よりも大きく、制御の精度が低くなります。そのため、タップターゲットのサイズを適切に設定することが重要です。

テキストを十分に大きくする

サイズやパディングと同様に、入力要素とボタンのデフォルトのブラウザフォントサイズは、特にモバイルでは小さすぎます。

パソコン版と Android 版の Chrome でスタイル設定されていないフォームのスクリーンショット。 — パソコンとモバイルのデフォルトのスタイル: 入力テキストが小さすぎて、多くのユーザーが読み取れません。

プラットフォームによってブラウザでフォントサイズが異なるため、すべてのデバイスで適切に機能する特定のフォントサイズを指定することは困難です。一般的なウェブサイトをざっと調べてみると、パソコンでは 13 ～ 16 ピクセルのサイズが一般的です。この物理サイズに合わせると、モバイルテキストの最小サイズとして適切です。

そのため、モバイルではより大きなピクセルサイズを使用する必要があります。パソコン版 Chrome の 16px は非常に読みやすいですが、Android 版 Chrome の 16px テキストは、視力が良好な場合でも読みづらいです。メディアクエリを使用すると、ビューポートのサイズごとに異なるフォントピクセルサイズを設定できます。モバイルでは 20px が適切ですが、視覚障がいのある友人や同僚にテストしてもらうことをおすすめします。

Lighthouse の監査項目「ドキュメントで判読可能なフォントサイズが使用されていません」を使用すると、小さすぎるテキストを検出するプロセスを自動化できます。

入力の間に十分なスペースを設ける

入力がタップターゲットとして適切に機能するように、十分な余白を追加します。つまり、指の幅程度の余白をとることをおすすめします。

入力内容がはっきりと映っていることを確認します。

入力のデフォルトの境界線のスタイル設定がわかりにくい。Chrome for Android などの一部のプラットフォームでは、ほとんど目立ちません。

パディングに加えて、ボーダーを追加します。白い背景では、#ccc またはそれより暗い色を使用するのが一般的です。

Android 版 Chrome のスタイル設定されたフォームのスクリーンショット。 — 判読可能なテキスト、表示される入力境界線、適切なパディングと余白。

ブラウザの組み込み機能を使用して、無効な入力値を警告する

ブラウザには、type 属性を持つ入力に対して基本的なフォーム検証を行う機能が組み込まれています。無効な値を含むフォームを送信すると、ブラウザは警告を発し、問題のある入力にフォーカスを設定します。

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

:invalid CSS セレクタを使用して、無効なデータをハイライト表示できます。:not(:placeholder-shown) を使用すると、コンテンツのない入力が選択されなくなります。

input[type=email]:not(:placeholder-shown):invalid {
  color: red;
  outline-color: red;
}

無効な値を含む入力をハイライト表示するさまざまな方法を試してみましょう。

必要に応じて JavaScript を使用する

パスワードの表示を切り替える

ユーザーが入力したテキストを確認できるように、[パスワードを表示] 切り替えボタンを追加する必要があります。入力したテキストをユーザーが確認できないと、ユーザビリティが低下します。現在のところ、この操作を行う組み込みの方法はありませんが、実装する予定があります。代わりに JavaScript を使用する必要があります。

[パスワードを表示] の切り替えボタンと [パスワードを忘れた] リンクが表示された Google ログインフォーム。 — Google ログインフォーム: [**パスワードを表示**] 切り替えボタンと [**パスワードを忘れた**] リンクがあります。

次のコードは、テキストボタンを使用して [パスワードを表示] 機能を追加します。

HTML:

<section>
  <label for="password">Password</label>
  <button id="toggle-password" type="button" aria-label="Show password as plain text. Warning: this will display your password on the screen.">Show password</button>
  <input id="password" name="password" type="password" autocomplete="current-password" required>
</section>

ボタンをプレーンテキストのように見せるための CSS は次のとおりです。

button#toggle-password {
  background: none;
  border: none;
  cursor: pointer;
  /* Media query isn't shown here. */
  font-size: var(--mobile-font-size);
  font-weight: 300;
  padding: 0;
  /* Display at the top right of the container */
  position: absolute;
  top: 0;
  right: 0;
}

パスワードを表示する JavaScript は次のとおりです。

const passwordInput = document.getElementById('password');
const togglePasswordButton = document.getElementById('toggle-password');

togglePasswordButton.addEventListener('click', togglePassword);

function togglePassword() {
  if (passwordInput.type === 'password') {
    passwordInput.type = 'text';
    togglePasswordButton.textContent = 'Hide password';
    togglePasswordButton.setAttribute('aria-label',
      'Hide password.');
  } else {
    passwordInput.type = 'password';
    togglePasswordButton.textContent = 'Show password';
    togglePasswordButton.setAttribute('aria-label',
      'Show password as plain text. ' +
      'Warning: this will display your password on the screen.');
  }
}

最終的な結果は次のようになります。

Mac の Safari と iPhone 7 のログインフォームのスクリーンショット。パスワードを表示するテキスト「ボタン」が表示されています。 — Mac と iPhone 7 の Safari で、[**パスワードを表示**] テキストの「ボタン」があるログインフォーム。

パスワード入力を可能にする

aria-describedby を使用して、制約を記述する要素の ID を指定し、パスワードルールの概要を説明します。スクリーンリーダーは、ラベルテキスト、入力タイプ（パスワード）、説明を読み上げます。

<input type="password" aria-describedby="password-constraints" …>
<div id="password-constraints">Eight or more characters with a mix of letters, numbers and symbols.</div>

[パスワードを表示] 機能を追加する場合は、パスワードが表示されることを警告する aria-label を含める必要があります。そうでない場合、ユーザーが誤ってパスワードを公開する可能性があります。

<button id="toggle-password"
        aria-label="Show password as plain text.
                    Warning: this will display your password on the screen.">
  Show password
</button>

次の Glitch で、両方の ARIA 機能の動作を確認できます。

フォームのユーザー補助機能について詳しくは、ユーザー補助機能に対応したフォームを作成するをご覧ください。

リアルタイムと送信前に検証する

HTML フォーム要素と属性には基本的な検証機能が組み込まれていますが、ユーザーがデータを入力している間やフォームの送信を試みた際に、より堅牢な検証を行うには JavaScript も使用する必要があります。

ログインフォームの Codelab のステップ 5 では、Constraint Validation API（広くサポートされています）を使用して、組み込みのブラウザ UI を使用してカスタム検証を追加し、フォーカスを設定してプロンプトを表示します。

詳細: JavaScript を使用した複雑なリアルタイム検証

アナリティクスと RUM

「測定できないものは改善できない」という格言は、登録フォームやログインフォームに特に当てはまります。目標を設定し、成果を測定し、サイトを改善し、その繰り返しが必要です。

割引のユーザビリティテストは変更を試す際に役立ちますが、ユーザーが登録フォームとログインフォームをどのように使用しているかを本当に理解するには、実際のデータが必要です。

ページ分析: 登録ページとログインページのページビュー、直帰率、離脱数。
インタラクションアナリティクス: 目標到達プロセス（ユーザーがログインまたはログインフローを放棄する場所）とイベント（ユーザーがフォームを操作する際に行うアクション）
ウェブサイトのパフォーマンス: ユーザー中心の指標（登録フォームとログインフォームが何らかの理由で遅い場合は、その原因は何ですか？）。

また、A/B テストを実装して、登録とログインのさまざまなアプローチを試したり、段階的なロールアウトで一部のユーザーに対して変更を検証してからすべてのユーザーにリリースしたりすることも検討してください。

一般的なガイドライン

適切に設計された UI と UX により、ログインフォームの放棄を減らすことができます。

ユーザーがログイン画面を探す必要がないようにします。ログインフォームへのリンクをページ上部に配置します。リンクのテキストには、ログイン、アカウントを作成、登録など、わかりやすい言葉を使用します。
焦点を絞りましょう。登録フォームは、特典やその他のサイト機能でユーザーの注意をそらす場所ではありません。
登録の複雑さを最小限に抑えます。その他のユーザーデータ（住所やクレジットカード情報など）は、ユーザーがそのデータの提供に明確なメリットがあると認識している場合にのみ収集します。
ユーザーが登録フォームに進む前に、価値提案を明確にします。ログインすることでユーザーにどのようなメリットがあるかを伝えます。登録を完了するための具体的なインセンティブをユーザーに提示します。
メールアドレスを使用できないユーザーもいるため、可能であれば、メールアドレスではなく携帯電話番号でユーザーを識別できるようにします。
ユーザーがパスワードを簡単に再設定できるようにし、[パスワードをお忘れですか？] リンクを目立つようにします。
利用規約とプライバシーポリシーのドキュメントへのリンク: データの保護方法を最初からユーザーに明確にします。
登録ページとログインページに会社または組織のロゴと名前を追加し、言語、フォント、スタイルがサイトの他の部分と一致していることを確認します。フォームによっては、他のコンテンツと同じサイトに属しているように感じられません（特に URL が大きく異なる場合）。

学習を続ける

写真提供: Meghan Schiereck（Unsplash）。