ユーザーが手間をかけずに登録、ログイン、アカウントの詳細の管理を行えるようにします。
ユーザーがサイトにログインする必要がある場合は、適切な登録フォームの設計が重要です。これは、接続が不安定な場合、モバイルを使用している場合、急いでいる場合、ストレスを感じている場合に特に当てはまります。登録フォームの設計が不適切だと、直帰率が高くなります。バウンスは、見込み顧客の獲得機会を逃すだけでなく、不満を抱えたユーザーを失う可能性もあります。
以下に、すべてのベスト プラクティスを適用した非常にシンプルな登録フォームの例を示します。
チェックリスト
- 可能であればログインは避けてください。
- アカウントの作成方法を明確にします。
- アカウントの詳細にアクセスする方法が明確にわかるようにする。
- フォームの煩雑さを解消する。
- セッションの長さを検討する。
- パスワード マネージャーがパスワードを安全に提案して保存できるようにする。
- 不正使用されたパスワードを許可しない。
- パスワードの貼り付けを許可する。
- パスワードを平文で保存または送信しないでください。
- パスワードの強制更新は行わない。
- パスワードの変更や再設定を簡単にする。
- 連携ログインを有効にします。
- アカウントの切り替えを簡単にする。
- 多要素認証の提供を検討する。
- ユーザー名には注意してください。
- ラボだけでなく、現場でもテストする。
- さまざまなブラウザ、デバイス、プラットフォームでテストする。
可能であればログインしない
登録フォームを実装してユーザーにサイト上でアカウントを作成するよう求める前に、本当に必要なかどうかを検討してください。可能な限り、ログイン後に機能を制限することは避けてください。
最適な登録フォームは、登録フォームがないことです。
アカウントを作成するようユーザーに求めると、ユーザーが達成しようとしている目標の邪魔になります。ユーザーにお願いをしており、個人データを信頼していただくようお願いしています。保存するパスワードやデータアイテムには、プライバシーとセキュリティに関する「データ債務」が伴い、サイトの費用と責任になります。
ユーザーにアカウントの作成を求める主な理由が、ナビゲーションやブラウジング セッション間で情報を保存することである場合は、代わりにクライアントサイド ストレージの使用を検討してください。ショッピング サイトの場合、購入のためにユーザーにアカウントの作成を強制することは、ショッピング カートの放棄の主な原因として挙げられます。ゲスト購入をデフォルトにする必要があります。
ログインを明確にする
ページの右上に [ログイン] ボタンや [ログイン] ボタンを配置するなど、サイトでアカウントを作成する方法を明確にします。曖昧なアイコンやあいまいな文言(「参加する」、「] を表示し、ログインをナビゲーション メニューに隠さないでください。ユーザビリティの専門家である Steve Krug は、ウェブサイトのユーザビリティに対するこのアプローチを「Don't make me think!(考えさせないで!)」と要約しています。ウェブチームの他の人に説得する必要がある場合は、アナリティクスを使用して、さまざまなオプションの影響を示します。
Google などの 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 では、さまざまなデバイスとブラウザでオープンソース プロジェクトの無料テストが可能です。
分析とリアルユーザー モニタリングを実装する
ユーザーが登録フォームをどのように使用しているかを把握するには、フィールドデータとラボデータが必要です。アナリティクスとリアルユーザー モニタリング(RUM)では、ユーザーの実際の操作に関するデータ(登録ページの読み込み時間、ユーザーが操作した(または操作しなかった)UI コンポーネント、ユーザーが登録を完了するまでの時間など)が提供されます。
- ページ分析: 登録フローの各ページのページビュー、直帰率、離脱数。
- インタラクション アナリティクス: 目標到達プロセスとイベントにより、ユーザーが登録フローを放棄した場所と、登録ページのボタン、リンク、その他のコンポーネントをクリックしたユーザーの割合を確認できます。
- ウェブサイトのパフォーマンス: ユーザー中心の指標を使用すると、登録フローの読み込みが遅いかどうか、視覚的に不安定かどうかを確認できます。
小さな変更が、登録フォームの完了率に大きな影響を与えることがあります。アナリティクスと RUM を使用すると、変更を最適化して優先順位を付け、ローカル テストでは検出されない問題がないかサイトをモニタリングできます。
学習を続ける
- ログイン フォームのベスト プラクティス
- お支払いフォームと住所フォームに関するベスト プラクティス
- 最適なフォームの作成
- モバイル フォーム設計のベスト プラクティス
- より高度なフォーム コントロール
- ユーザー補助に対応したフォームを作成する
- Credential Management API を使用した登録フローの効率化
- WebOTP API を使用してウェブ上で電話番号を確認する
写真提供: @ecowarriorprincess(Unsplash)