ログイン機能はどの製品でも基本的な機能であり、ユーザーは使い慣れていますが、プロダクトマネージャーにとってはユーザーがプロダクトの世界への扉を開ける「鍵」であり、しっかりと設計する必要があります。
ユーザーの観点から見ると、ログインは 1 回限りの機能のようなものであり、多くのアプリは携帯電話に一度ログインすると、次に携帯電話を変更するまでログイン ページが表示されません。
ユーザーにとってログイン機能は「普通」ですが、プロダクトマネージャーはそうは思っていません。
1. 同じ錠前でも、玄関ドアに取り付ける人もいれば、部屋のドアに取り付ける人もいます。
現在、ログイン機能の配置ロジックにはフロントログインとポストログインの 2 つの設計が主流です。
事前ログインとは、ユーザーがアプリケーションを開くときに、アプリケーションは最初にユーザーにログインを要求し、ログインが成功した後にのみユーザーがリソースにアクセスできることを意味します。
このようなロジックは、玄関ドアに鍵を取り付けるのと同じで、家に入るには、まず玄関ドアの鍵を開ける必要があります。代表的なアプリケーションとしては、WeChat、Alipayなどが挙げられます。
ログイン後とは、ユーザーがアプリを開いたときに、アプリの一部のリソースにアクセスできることを意味します。ユーザーがアカウント権限を必要とする特定のリソースにアクセスする場合、ユーザーはログインする必要があります。
このようなロジックは、部屋のドアに鍵を取り付けるのと同じで、家には自由に入ることができますが、部屋に入りたい場合は、まず部屋の鍵を解除する必要があります。代表的なアプリケーションとしては、Douyin、Taobao、JD.com などが挙げられます。
ログインが前か後ろかは主に「リソース」に依存します。
WeChat、Alipayなど、アプリケーションのリソースが基本的に「プライベートリソース」の場合、事前ログインが必要です。アクセスされるリソースは基本的にソーシャルネットワーキング、チャット、支払いなどのプライベート情報であるため、事前ログインが必要です。リビングにテレビやソファ、冷蔵庫があるのと同じように、玄関ドアにも鍵をかけたほうがいいでしょう。
アプリケーションのリソースのほとんどが「パブリック リソース」に属している場合、Douyin、淘宝網、JD.com など、ログイン後にアクセスできます。アクセスされるリソースは、短いビデオ、商品などです。これらは、パブリックにアクセスされます。注文やコレクションを確認したい場合は、それがあなたの「プライベート リソース」に関係する場合にのみログインするよう求められます。ロックを取得できないのは本当ですか?
次に、ロックが解除されると、キーが割り当てられます。
従来のアカウントパスワードログインに比べ、現在ではアプリケーションのログイン方法は認証コードログインと第三者認証ログインが主流となっており、登録の概念が薄れています。
通常、ログイン時にアカウントが存在しない場合、システムは自動的に新しいアカウントを登録しますが、この登録プロセスはユーザーには影響を与えません。これは、鍵を開けようと思ったら鍵がなかったときのようなもので、これまでは別の場所に鍵を取りに行き、走って戻って鍵を開けるという方法でしたが、今では鍵を手に入れることができます。ロックを直接見つけてロックを解除します。
モバイル認証コードは、ほとんどのプラットフォームで優先されるログイン方法になっています。
一部のアプリケーションでは、アカウントのパスワードによるログイン設計がまだ残っており、ユーザーが初めて携帯電話の認証コードを使用してログインすると、新しく登録されたアカウントにパスワードがないという問題が発生します。一般に、次の 3 つの解決策があります。
1. 設定にパスワードを設定するためのエントリを追加します。アカウントにパスワードがない場合はそのエントリが表示されます。ユーザーがすでにパスワードを設定している場合は、そのエントリをパスワード変更用のエントリに変更できます。
2. 登録プロセスを調整し、アカウント登録時にパスワードを設定する機能を追加します。
3. アカウントのパスワードを使用してログインする場合、判断と処理がより複雑になります。
最初に行うことは、ログイン時の確認です。
その場合、非ログイン状態でパスワードを設定する処理も追加する必要があります。
SMS 認証コードを受信するまでの数秒の待ち時間を嫌い、サードパーティの認証ログインを選択するユーザーもいます。
認証ログインはサードパーティアプリケーションにジャンプし、ユーザーが認証に同意するためにクリックすると、認証が成功すると、サードパーティアプリケーションによって割り当てられた「ユーザーID」が取得され、システムは取得したIDを確認します。システム内のユーザー ID を使用して、バインドされたアカウントがあるかどうかを確認します。アカウントをバインドした場合、ユーザーは以前にこの ID でのログインを許可されていないことになるため、新しいアカウントを作成して ID をバインドできます。
この方法では、携帯電話の認証コードよりも多くの問題が発生します。アカウントはサードパーティのユーザー ID しか取得できません。今回はパスワードがないだけでなく、携帯電話番号さえも取得できません。ユーザーが次回ログインする際に携帯電話の認証コードに変更すると、その際に別のアカウントを登録することになり、2つのアカウントのデータが分離されてしまい、ユーザーにとっては一種のトラブルとなることは間違いありません。
したがって、サードパーティ認証によるログインのみをサポートするプラットフォームを除き、アカウントが携帯電話番号にバインドされていない場合、通常、サードパーティ認証によるログインの成功にはバインドが必要になります。
もちろん、新規に登録したアカウントの場合は、携帯電話番号を紐付けた後にパスワードを設定するようユーザーに求めることもできますが、この操作はユーザーにとって煩雑すぎるため、このリンクは一般的に破棄されます。
3. ロックでロックを解除する
世界には歴史が残した問題と呼ばれる、解決が最も難しい問題の一つがあります。
製品の形成は反復の結果であり、さまざまな段階でさまざまな形式になりますが、これらの形式は常に互換性があるとは限りません。おそらく、製品のログインは、ある段階では主に携帯電話の認証コードに基づいて行われ、ある段階では主にサードパーティの認証されたログインに基づいて行われるようになります。異なるログイン方法が別のアカウントとして登録される ある段階で 2 つの方法を統合するときに問題が発見される すでにデータを保持しているサードパーティの承認されたログイン アカウントを携帯電話の認証コードにバインドする必要があるすでにデータがあるログイン アカウントです。競合しています。
これは、1 つの鍵でしか施錠できないドアのようなものです。このとき、あなたは 2 つの鍵を手に持っており、両方の鍵をロックするつもりですが、この時点で競合が発生します。現時点では「ロックで解除する」しかありませんが、深い理論ではありませんので、これらのロックを使用してください。
製品の観点から、ユーザーは、サードパーティのアカウントをこの携帯電話番号にバインドしないこと、または 2 つのアカウントを別々に使用することを選択できます。サードパーティのアカウントをこの携帯電話番号にバインドする必要がある場合、システムは次のことを行うことができます。いずれかのアカウントをキャンセルし、1 つのアカウントのみを保持するようお願いするだけです。
ユーザーは、ログイン時にサードパーティ認証を使用してログインした可能性があり、携帯電話番号をバインドする必要があり、その結果、携帯電話番号もアカウントに登録されました。
また、既に携帯電話番号がバインドされているアカウントにサードパーティのアカウントをバインドしたり、既にサードパーティにバインドされているアカウントに携帯電話番号をバインドして、アカウントの競合を見つけることも可能です。アカウントは 1 つだけ予約されており、予約されたアカウントは携帯電話番号とサードパーティのアカウントに同時にバインドできます。
なぜこのような「極端な」設計になっているのかというと、主な理由は両方のアカウントにデータがあり、どちらか一方を退会せずに強制的に2つのアカウントのデータを統合すると、一部のデータが競合してしまうからです。
例えば、2つのアカウントを統合したい場合、注文などのデータは統合できますが、アバターやニックネームなどの情報の場合、1つのアカウントに同時に2つの情報を持つことはできず、1つの情報のみを持つことができます。では、どのアカウントを保持すればよいでしょうか?
おそらく、マージできるデータはマージでき、マージできないデータはユーザーがいずれかのアカウントを保持することを選択できると考えているかもしれません。これは理論的には実現可能ですが、アカウントに関連する機能を開発するたびに、どのデータをマージできるかを考慮する必要があります。マージのコスト、つまりマージのためにどのデータを破棄する必要があるかは高すぎます。また、ユーザーをアカウントの 1 つからログアウトさせるよりもはるかに経済的ではありません。
したがって、ユーザーにとっての通常のログイン機能は、実はプロダクトマネージャーにとって、ユーザーにプロダクトの世界への扉を開く「鍵」となるのです。