このページは 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 を入力していない場合でも、[ログイン] ボタンを無効にしないでください。ユーザーがフォームの入力を見落として、（無効になっている）[Sign in] ボタンを繰り返しタップしてみると、動作しないことがあります。フォームの送信を無効にする必要がある場合は、少なくとも、無効なボタンをクリックしたときに不足している内容をユーザーに説明してください。

注意: フォーム内のボタンのデフォルトタイプは 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 と 8 では非表示になりますが、iPhone 11 では非表示になります。

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

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

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

これは 1 つの <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 のインターフェースガイドラインでは 48 x 48 ピクセルが推奨され、W3C では 44 x 44 CSS ピクセル以上が推奨されています。そのうえで、モバイルの場合は入力要素とボタンに 15 ピクセル程度、パソコンの場合は 10 ピクセル程度のパディングを追加します。実際のモバイルデバイスと実際の指または親指で試してみてください。各入力とボタンを快適にタップできる必要があります。

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

親指を考慮したデザイン

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

文字を十分な大きさにする

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

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

プラットフォームによってブラウザでフォントサイズが異なるため、どこでも適切に機能する特定のフォントサイズを指定することは困難です。人気ウェブサイトの簡単なアンケートによると、PC では 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>

両方の ARIA 機能の動作を、次の Glitch でご覧ください。

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

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

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

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

詳細: JavaScript を使用してより複雑なリアルタイム検証を行う

アナリティクスと RUM

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

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

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

また、登録とログインのさまざまな方法を試すために A/B テストを実装することもおすすめします。また、すべてのユーザーに変更をリリースする前に、段階的な公開によって一部のユーザーで変更を検証することもできます。

一般的なガイドライン

UI と UX を適切に設計することで、ログインフォームの放棄を削減できます。

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

学習を続ける

写真提供: Meghan Schiereck（Unsplash）。