登録フォームのベスト プラクティス

ユーザーが簡単に登録、ログイン、アカウントの詳細を管理できるようにします。

Sam Dutton

ユーザーがサイトにログインする必要がある場合は、登録フォームを適切に設計することが重要です。これは、接続状態が悪い人、モバイル デバイスを使用している人、急いでいる人、ストレスを感じている人に特に当てはまります。登録フォームのデザインに問題があると直帰率が高くなります。 ユーザーが直帰するたびに、登録機会を失うだけでなく、ユーザーが不満を抱くことにもなりかねません。

すべてのベスト プラクティスを取り入れた、非常にシンプルな登録フォームの例を次に示します。

チェックリスト

• 可能であればログインは避ける。
• アカウントの作成方法をわかりやすく説明します。
• アカウント情報へのアクセス方法を明確に示す。
• フォーム内の不要な部分を切り取ります。
• セッションの長さを考慮する。
• パスワード マネージャーがパスワードを安全に提案、保存できるようにする。
• 不正使用されたパスワードを許可しない。
• パスワードの貼り付けを許可する。
• パスワードを書式なしテキストで保存または送信しないでください。
• パスワードの更新は強制しない。
• パスワードの変更や再設定を簡単に行えるようにする。
• 連携ログインを有効にする。
• アカウントの切り替えを簡単に行えるようにする。
• 多要素認証の提供を検討する。
• ユーザー名に注意する。
• ラボだけでなく、現場でもテストします。
• さまざまなブラウザ、デバイス、プラットフォームでテストできます。

可能であればログインを避ける

登録フォームを実装し、ユーザーにサイトでアカウントの作成を求める前に、本当に必要なかどうかを検討してください。可能な限り、ログインによって機能を制限しないでください。

最適な登録フォームは、登録フォームを使用しないことです。

ユーザーにアカウントの作成を依頼することで、ユーザーとユーザーが実現しようとしていることを区別します。 個人データについてあなたを信頼するようユーザーに求めています。保存するすべてのパスワードやデータ項目にはプライバシーとセキュリティの「データ負債」が伴い、サイトにとってのコストと責任となります。

ユーザーにアカウントの作成を求める主な理由がナビゲーション セッションやブラウジング セッションの間で情報を保存することである場合は、代わりにクライアントサイド ストレージの使用を検討してください。ショッピング サイトでは、ショッピング カートが放棄される主な理由として、購入のためにユーザーにアカウントを作成させることが挙げられています。「ログインせずに決済」をデフォルトに設定してください。

ログインをわかりやすくする

ページの右上にある [ログイン] ボタンや [ログイン] ボタンなどを使用して、サイトでアカウントを作成する方法が明確にわかるようにします。あいまいなアイコンやあいまいな表現（例: 「参加しよう！」、「ぜひご参加ください」）。ナビゲーション メニューの中のログイン情報を非表示にしないでください。ユーザビリティのエキスパートである Steve Krug は、ウェブサイトのユーザビリティに対するこのアプローチをまとめました。Don't make me?ウェブチームの他のメンバーを説得する必要がある場合は、分析を使用して、さまざまな選択肢の影響を示します。

Google などの ID プロバイダを介して登録するユーザーと、メールアドレスとパスワードを使用して登録するユーザーのアカウントをリンクしてください。これは、ID プロバイダのプロファイル データからユーザーのメールアドレスにアクセスでき、2 つのアカウントを照合できる場合に簡単に行えます。以下のコードは、Google ログイン ユーザーのメールデータにアクセスする方法を示しています。

// auth2 is initialized with gapi.auth2.init()
if (auth2.isSignedIn.get()) {
  var profile = auth2.currentUser.get().getBasicProfile();
  console.log(`Email: ${profile.getEmail()}`);
}

アカウントの詳細へのアクセス方法をわかりやすくする

ユーザーがログインしたら、アカウントの詳細情報にアクセスする方法を明確にします。特に、パスワードを変更または再設定する方法をわかりやすく説明します。

不要なフォームを切り取る

登録フローでは、複雑さを最小限に抑え、ユーザーが集中できるようにしてください。不要なものを整理できます。 今は気が散り、誘惑に満ちている時間ではありません。

お申し込みの際は、できる限り少なくいただくようお願いします。必要な場合にのみ、追加のユーザーデータ（名前や住所など）を収集します。また、ユーザーがそのデータを提供することで明らかなメリットを得られた場合にのみ収集します。通信して保存するすべてのデータ項目に費用と法的責任が発生することを覚えておいてください。

ユーザーが正しい連絡先情報を確実に取得するためだけに、入力を重複してはいけません。この場合、フォームの入力が遅くなり、フォームのフィールドに自動入力されたとしても意味がありません。代わりに、ユーザーが連絡先情報を入力し終えたらユーザーに確認コードを送信し、ユーザーからの返信があったらアカウントの作成を続行します。これは一般的な登録パターンで、ユーザーは使い慣れています。

ユーザーが新しいデバイスやブラウザにログインするたびにコードを送信することで、パスワードなしのログインを検討できます。Slack や Medium などのサイトでは、このバージョンを使用している。

これにはフェデレーション ログインと同様に、ユーザーのパスワードを管理する必要がないという利点があります。

セッションの長さを考慮する

ユーザー ID に対してどのようなアプローチを取るにしても、セッションの長さについて慎重に判断する必要があります。つまり、ユーザーのログイン継続時間と、ユーザーをログアウトさせる原因を慎重に判断する必要があります。

ユーザーがモバイルとパソコンのどちらを使用しているか、パソコンで共有しているか、共有デバイスを使用しているかを考慮してください。

パスワード マネージャーがパスワードを安全に提案、保存できるようにする

サードパーティや組み込みのブラウザのパスワード マネージャーでパスワードを提案して保存できるようにすることで、ユーザーがパスワードの選択、記憶、入力を行わなくても済むようにします。パスワード マネージャーは最新のブラウザで適切に機能し、デバイス、プラットフォーム固有のウェブアプリ、新しいデバイス間でアカウントを同期します。

そのため、登録フォームを正しくコーディングすること、特に正しいオートコンプリート値を使用することが非常に重要です。登録フォームでは、新しいパスワードに autocomplete="new-password" を使用し、可能な限り他のフォーム フィールド（autocomplete="email" や autocomplete="tel" など）に正しいオートコンプリート値を追加します。また、登録フォームとログイン フォームで、form 要素自体だけでなく、input、select、textarea 要素でも、異なる name と id の値を使用して、パスワード マネージャーをサポートすることもできます。

また、適切な type 属性を使用してモバイルで適切なキーボードを提供し、ブラウザで基本的な組み込み検証を有効にする必要もあります。詳しくは、お支払いと住所フォームに関するおすすめの方法をご覧ください。

ユーザーが安全なパスワードを入力できるようにする

パスワード マネージャーによるパスワードの提案を有効にすることをおすすめします。ブラウザやサードパーティのブラウザ マネージャーが提案する安全なパスワードを受け入れるようユーザーに促してください。

ただし、多くのユーザーが自分のパスワードを入力したいので、パスワードの安全度に関するルールを実装する必要があります。米国国立標準技術研究所では、安全でないパスワードを回避する方法が説明されています。

不正使用されたパスワードを許可しない

パスワードにどのルールを選択したとしても、セキュリティ侵害で漏洩したパスワードは許可しないでください。

ユーザーがパスワードを入力したら、そのパスワードがすでに不正使用されていないことを確認する必要があります。Have I Been Pwned というサイトでパスワード チェック用の API が提供されています。また、サービスとして実行することもできます。

Google のパスワード マネージャーでは、既存のパスワードが不正使用されたかどうかを確認することもできます。

ユーザーが提示したパスワードを拒否した場合は、その理由を具体的に提示します。 ユーザーが登録フォームを送信した後、サーバーからの応答を待たずに、問題をインラインで表示し、その修正方法を説明します。

パスワードの貼り付けを禁止しない

一部のサイトでは、パスワード入力にテキストを貼り付けることは許可されていません。

パスワードの貼り付けを禁止すると、ユーザーに不快な思いをさせ、記憶に残るパスワードが助長されます（したがって侵害されやすい可能性があります）。また、英国国家サイバー セキュリティ センターなどの組織によると、実際にセキュリティが低下する可能性があります。ユーザーは、パスワードを貼り付けようとした後には貼り付けが許可されていないことに気付きます。そのため、パスワードの貼り付けを無効にしても、クリップボードの脆弱性は回避されません。

書式なしテキストでパスワードを保存、送信しない

パスワードには必ずソルトとハッシュを付けます。独自のハッシュ アルゴリズムを考案しようとしないでください。

パスワードを強制的に更新しない

ユーザーに勝手なパスワードの更新を強制しないでください。

パスワードの更新を強制すると、IT 部門にとってコストがかかる可能性があり、ユーザーにとって煩わしいものになります。また、セキュリティに大きな影響を及ぼすこともありません。また、記憶に残る安全でないパスワードの使用や、パスワードを物理的に記録しておくことが奨励される傾向があります。

パスワードを強制的に更新するのではなく、通常とは異なるアカウント アクティビティを監視してユーザーに警告する必要があります。 可能であれば、データ侵害によって不正使用されたパスワードも監視する必要があります。

また、ユーザーがアカウントのログイン履歴にアクセスできるようにして、いつどこでログインが行われたかを示す必要があります。

パスワードの変更や再設定を簡単に行えるようにする

アカウントのパスワードを更新する場所と方法をユーザーに明示します。サイトによっては驚くほど難しいことがあります

もちろん、ユーザーがパスワードを忘れた場合に簡単にリセットできるようにすることも重要です。Open Web Application Security Project は、パスワードを紛失した場合の対処方法に関する詳細なガイダンスを提供しています。

ビジネスとユーザーの安全を守るため、パスワードが不正使用されていることに気付いたユーザーがパスワードを変更できるようにすることは特に重要です。これを簡単に行うには、パスワード管理ページにリダイレクトする /.well-known/change-password URL をサイトに追加します。これにより、パスワード マネージャーはサイトのパスワードの変更ページにユーザーを直接誘導できます。この機能は現在 Safari と Chrome に実装されており、他のブラウザにも実装される予定です。パスワード変更用のよく知られた URL を追加して、ユーザーが簡単にパスワードを変更できるように支援するでは、この実装方法について説明しています。

また、ユーザーがアカウントの削除を希望している場合は、その操作を簡単に行えるようにする必要もあります。

サードパーティの ID プロバイダを介したログインを提供する

ウェブサイトへのログインには、メールアドレスとパスワードの登録フォームを使用することがよくあります。ただし、ユーザーがサードパーティの ID プロバイダ（フェデレーション ログインとも呼ばれます）を介してログインできるようにする必要があります。

この方法には、いくつかの利点があります。連携ログインを使用してアカウントを作成したユーザーの場合、パスワードを要求、通信、保存する必要はありません。

フェデレーション ログインから、メールアドレスなどの確認済みの追加のプロフィール情報にアクセスできる場合もあります。この場合、ユーザーはデータを入力する必要がなく、デベロッパー自身で検証を行う必要もありません。フェデレーション ログインは、ユーザーが新しいデバイスを入手する際にも非常に簡単になります。

登録オプションにフェデレーション ログインを追加する方法については、Google ログインをウェブアプリに統合するをご覧ください。その他多くの ID プラットフォームを利用できます。

アカウントの切り替えが簡単に

多くのユーザーがデバイスを共有し、同じブラウザを使用してアカウントを切り替えています。ユーザーがフェデレーション ログインにアクセスするかどうかにかかわらず、アカウントの切り替えは簡単に行う必要があります。

多要素認証の提供を検討する

多要素認証とは、ユーザーが複数の方法で認証を行うようにすることです。たとえば、ユーザーにパスワードの設定を求めるだけでなく、メールまたは SMS テキスト メッセージで送信されるワンタイム パスコード、またはアプリベースのワンタイム コード、セキュリティ キー、指紋認証センサーを使用して確認を適用することもできます。SMS OTP のベスト プラクティスと WebAuthn による強力な認証の有効化では、多要素認証の実装方法を説明しています。

サイトで個人情報や機密情報を扱う場合は、必ず多要素認証を提供（または適用）する必要があります。

ユーザー名に注意する

必要な場合以外（または必要なとき）は、ユーザー名を強要しないでください。登録とログインに、メールアドレス（または電話番号）とパスワードのみ、または必要に応じて連携ログインを使用できるようにします。ユーザー名の選択や記憶を強要しないでください。

サイトでユーザー名が必要な場合は、合理的なルールを課したり、ユーザーによるユーザー名の更新を妨げたりしないでください。バックエンドでは、ユーザー名などの個人データに基づく識別子ではなく、ユーザー アカウントごとに一意の ID を生成する必要があります。

また、ユーザー名には必ず autocomplete="username" を使用します。

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

ユーザーが最もよく使用するプラットフォームで登録フォームをテストします。フォーム要素の機能は異なる場合があります。また、ビューポートのサイズが異なると、レイアウトの問題が発生する可能性があります。BrowserStack では、さまざまなデバイスとブラウザでオープンソース プロジェクトの無料テストを実施できます。

分析とリアルユーザー モニタリングを実装する

ユーザーが登録フォームでどのように操作するかを理解するには、ラボデータだけでなくフィールド データとフィールド データが必要です。アナリティクスと Real User Monitoring（RUM）により、登録ページの読み込みに要する時間、ユーザーが操作した（またはしない）UI コンポーネント、ユーザーが登録を完了するまでの時間など、実際のユーザー エクスペリエンスに関するデータが提供されます。

• ページ分析: 登録フローにおける各ページのページビュー数、直帰率、離脱数。
• インタラクション分析: ゴール ファネルとイベントでは、ユーザーが登録フローを放棄した場所や、ボタンやリンクなど、登録ページのコンポーネントをクリックするユーザーの割合を把握できます。
• ウェブサイトのパフォーマンス: ユーザー中心の指標から、登録フローの読み込みが遅いか、視覚的に不安定かがわかります。

小さな変化が、登録フォームの入力率に大きな違いをもたらすことがあります。分析と RUM を使用することで、変更の最適化と優先順位付けを行い、ローカルテストでは特定できない問題がないかサイトを監視できます。

さらに詳しく

• ログイン フォームに関するおすすめの方法
• お支払いと住所フォームに関するおすすめの方法
• 便利なフォームの作成
• モバイル フォームのデザインに関するおすすめの方法
• より優れたフォーム コントロール
• 使いやすいフォームを作成する
• Credential Management API を使用した登録フローの合理化
• WebOTP API を使用してウェブ上で電話番号を確認する

写真撮影: @ecowlierprincess（Unsplash）