サインアップフォームの[パスワード]フィールドを削除しますか
これを想像してみてください。あなたは製品にサインアップしていて、パスワードを除いてアカウント（名前、メールアドレスなど）を作成するときに同じ古い質問を受けます。
サインアップすると、自動生成されたパスワードを含むメールが送信されます。ログインすると、アカウントセクション内のパスワードを変更できるようになります。
それについてどう思いますか？それの否定的な側面は何ですか？
マイナス面は、うっかりプロセスを複雑にしたことです。
サインアップして自分の好みの安全なパスワードを使用すれば、それで完了です。
ただし、自動生成パスワードアプローチでは、電子メールを取得し、リンクをクリックして、電子メールに戻り、パスワード「G34-zaopwf792hj」をコピーする必要があります（再入力を試みないため）貼り付けます、プロファイルリンク、[パスワードの変更]オプションの順に探し、古いパスワードを再度貼り付け、実際に必要なパスワードを入力して保存し、実際のアプリに戻ります。
...そして、私がこれを電話でやろうとしているなら？...ああ！
これを行う方法を見つけて、ステップ数（たとえば、摩擦）を減らし、セキュリティを維持できる場合は、調査する価値があると思います。
やらないで
理由はいくつかあります。
ユーザーのコミュニケーションを向上させるのではなく悪化させる。パスワードフィールドのないサインアップフォームに直面したユーザーは、自分のアカウントが安全かどうか、なぜパスワードがないのか疑問に思うかもしれません。フィールドを削除すると、パスワードを介してアカウントにアクセスすることをユーザーに伝えることができなくなります。実際、あなたは反対のことを暗示しています（つまり、パスワードはありません）。
- これを修正するために、パスワードを電子メールで送信することをユーザーに通知することができますが、それは、最初からパスワードフィールドを表示することよりも悪いことです。
より多くのUX摩擦を作成します。パスワードフィールドを削除すると、ユーザーがサイトにアクセスする際の摩擦を減らすのに役立つと考えるかもしれません。しかし、シナリオを考えてみてください。
- シナリオ1：ユーザーがパスワードを設定したい。サインアップ時にそれを行うことができないため、アプリケーションを電子メールに切り替え、リンクをクリックし、別のタブに移動し、パスワードを設定して、新しいタブから続行するか、古いタブに切り替える必要があります。 => これは、サインアップ時の単純なパスワードの改善ではありません。
- シナリオ2：ユーザーはメールでサインアップし、サイトにアクセスします。これにより摩擦が減ると思うかもしれませんが、それを試してみてください...ユーザーがメールをチェックすると、パスワードの通知が表示されます。しかし、彼女はすでにあなたのサイトの閲覧を終えています！そのため、サイトを使用していない場合でも、クリックしてパスワードを設定する必要があるか、メールを無視した場合、次回サイトにアクセスしたときにメールを検索する必要があります。 => これは、サインアップ時の単純なパスワードの改善ではありません。
これは規約に違反しています。ユーザーは、パスワードを入力してサイトにサインアップするのに慣れています。パスワードフィールドを提示しないと、一般的な慣習に違反します。
- これは、椅子を使わずにユーザーを夕食のテーブルに案内するようなものです。後で座る時間になったときに椅子が持ち込まれることをユーザーに説明できますが、通常の動作をして、最初は椅子を用意することをお勧めします。
重要な質問は、メールアドレスを確認する必要があるかどうかです。
確認の目的でメールを送信するか、ウェルカムメッセージのみを送信します。
入力するフィールドを本当に削除したい場合は、名前、メールアドレス、パスワードから始めることができます。その後、後の段階で他の詳細を尋ねます。
この質問は言い換えることができます：ユーザーは最初のサインアップ時に自分のパスワードを選択できないようにする必要がありますか？最良のシナリオでは、変換率の高い合理化されたフォーム（単純なフォームのような人々）と、すべてが強力なパスワードを持つユーザーになります。これは、ユーザーが生成されたパスワードを使い続けることを前提としています。パスワードは覚えやすく安全なものでなければなりません。
これは思ったほど簡単ではありません。一般的なWordのパスワードは辞書攻撃やレインボー攻撃を受ける可能性があり、パスワードアルゴリズムが公開されても、ユーザーのデータの大部分を保護するためにできることはそれほど多くありません。安全になるのは、サインアップ後に手動でパスワードを変更した人だけです-プロセスをより複雑にしただけです。また、他の誰かがパスワードを忘れた場合は、パスワードを作成していない可能性がありますが、アカウントにアクセスするには、別のパスワード生成プロセスを実行する必要があります。
一方、自分のパスワードを選択させることもできます。プレーンテキストでは何も送信せず、ユーザーが忘れることに対する不満はサービスではなく自分自身に課せられます。それでも、クリーンなサインアップフォームを作成できます。ログインフォームには必然的にパスワードが必要になるため、外観は変わりません。私の現在のプロジェクトには、電子メールとパスワードのフィールドがあり、その後にログインと登録ボタンが続くログインフォームがあります。すべてのユーザーに1つの画面。騒ぎが少なく、摩擦が少ない。
プロセスを一種の「非同期」にすることができます。つまり、すぐにパスワードを変更する必要なしに、ユーザーにサインインしてログインさせます。このようにして、「サイクルを壊す」ことはありません。
セキュリティに関しては、ユーザーが電子メールで送信されたリンクをクリックするか、パスワードを変更するまで、制限された特権セットのみを許可できます。
これは、サインアップする対象、およびユーザーが戻ってくる可能性が高く、ログインにパスワードが必要かどうかに依存すると思います。
たとえば、私はかつてこの方法でユーザーに自動パスワードを送信するサインアッププロセスに取り組みました。これは、Webサイトが後で通信するためにユーザーの資格情報を収集する必要がある一方で、ユーザーがWebサイトに戻ることを選択したためです。
ただし、ほとんどの場合、ユーザーにその場でパスワードを作成するように依頼する方が良いと思います。ほとんどのユーザーは とにかくすべてに同じパスワード を使用するため、 typingこれは筋肉の記憶を伴う 、そして認知活動はほとんどありません。
TL; DR：パスワードの作成/入力に必要な認識作業はほとんどありませんが、可能な場合は摩擦を避けてください。
その慣れは、システムに慣れていないユーザーを混乱させ、イライラさせます。さらに、ログイン後にパスワードを適切なものに変更する必要があることを直感的に知らない多くの人々が想像できます。彼らは、あなたが送信したメールを忘れて、サービスを再び利用したいときに混乱から再び登録するかもしれません。
メールではパスワードを平文で送信する必要がありますが、これは悪い習慣です（特に、サイトに個人情報や財務/支払い情報が保存されている場合）
これが、多くのWebサイトがパスワードを忘れた場合のメール送信を中止し、代わりにパスワードをリセットするためのリンクをメールで送信するようになった理由です。 （これの別の理由は、彼らがあなたのパスワードをプレーンテキストとして保存しないので、彼らはとにかくあなたにそれを送ることができないということです）。
電子メールでパスワードを受信すると、最初は一部のシナリオではユーザーエクスペリエンスが向上したように感じるかもしれませんが、サイトのセキュリティが低いと、肯定的なUXが短命になる可能性があります。
メールを待つ必要があります。それは流れを壊し、メールボックスに行き、メールをチェックします。メールを待つこともあります。不安！