it-swarm-ja.com

アカウントを作成したくない顧客のために、より良いユーザーアカウント作成エクスペリエンスを作成する方法

最近のオンラインアカウントでは、信頼と個人情報のセキュリティが非常に重要な問題になっているため、購入や情報の要求時にアカウントの作成(つまり、個人情報の提供)を望まない人も珍しくありません。

したがって、ユーザーが強制されている場合のほとんどは、ユーザーの要件ではなくビジネスまたは技術によるものと思われます。

したがって、問題は、ユーザーにサインアップまたはアカウントの作成を強制するときに、よりスムーズなユーザーエクスペリエンスを作成する設計パターンまたは手法は何ですか?これらの手法が実際に倫理的な設計慣行である場合のボーナスポイント!

57
Michael Lai

更新:回答を拡張し、いくつかの例を追加しました。フィードバックを得た場合、回答の品質をさらに向上させる可能性があります

あなたが尋ねたことは決してないだろうと思ったが、ここにいくつかの注意事項があります:

1。ユーザーはアカウントを作成する必要さえありますか?なぜですか?

多くの製品マネージャー/デザイナーはこの重要な質問を自問自答できません。それは、そこにあるすべてのデジタル製品がユーザーを特定する必要がある最大のトレンドの1つになりましたが、ユーザーがアカウントを作成すると、より多くのことを達成できるのは事実です。それは、直感的なコースではなく、意識的な決定でなければなりません。全員にアカウントの作成を強制することにより、オーソリティベットをしていることになります。

Login Walls

これはnngroupのWebサイトでLogin Walls Stop Users in their Tracksと呼ばれる非常に優れた記事です。そのような壁。

2。現在のタスクの関連情報のみを尋ねる

ユーザーがアカウントを作成しているとき、ユーザーは何かを念頭に置いており、製品/タスクを使用する必要があります。この要件は、ユーザーが求めていることを単に中断するだけであり、ユーザーの数を維持することが重要です最小限の入力。

LinkedIn Sign Up

Linkedinを宣伝するつもりはありませんが、ほとんどの人がプラットフォームを知っているので、彼らの事例を検討してください。結局、私たち-ユーザー-は私たちのプロファイルに多くの情報を入力しますが、linkedinが登録フェーズでそれらすべてを要求したと想像できますか?

そして、そう信じています。リリース時にそのような間違いを記録したことを私が知っている最大のプラットフォームは、Google +-RIPでした。社会的な側面、専門家、関心事などを反映するために、非常に多くの形をとらなければなりませんでした。開始プロセスを通過するのに20分。

3。適切なタイミングで適切な情報を求める

生涯洗濯を一度に行う必要があると想像してください。それほど楽しいのではなく、週単位で行うことを好みます。ユーザー入力は、はるかに小さいスケールでの類似のケースです-誇張を考えると、それは顕微鏡スケールのようなものです。だが!同じ効果があります。

製品を試す前に登録時に住所を尋ねるのではなく、チェックアウト時にそれを尋ねるか、製品を使用する前または製品の最後にユーザーが登録するほうが重要です。

Create Account After Checkout

PS:データベースの設計に使用される考え方がフォームの設計と同じである場合、これはフルスタック開発者の手によくある間違いです。

4。ユーザー入力を簡略化する

いくつかの例にアプローチするには非常に多くの方法があるので、これでできる限りクリエイティブにしてください。

4.1。シングルサインオン、ソーシャルログイン、ワンクリック登録 Social Login

4.2。ユーザーに代わってフォームに記入し、可能な場合はユーザーが修正できるようにする

サインアップのためのFacebookのデフォルトの生年月日の値について疑問に思ったことはありますか? Facebook Birthdate

日と月は明らかに今日を表していますが、なぜ1993なのでしょうか。おそらく今年の最も一般的なサインアップは1993年に生まれたユーザーですか?

私たちの多くは、IPアドレスから国を推測できることを知っていると思いますが、Michael.lai @ some-email.comが名Michaelと姓Laiを暗示する他に何を推測できるでしょうか。

Autofill

これは、許容範囲がわずかに強化されたエクスペリエンスでどのように発生するかの例です。このケースは100%の時間では適用されません。問題は、メールで使用されているパターンを調査でき、ユーザーのx%が名を使用していることが判明したかどうかです。 [email protected]次に、フォームが常に機能しない場合でも、フォームの自動入力でその情報を使用することができます。

この例では、ルールを破って、なんとかしてまだワークアウトできることを証明するつもりです。モバイルデバイスでは、中央のボタンをクリックするだけで、姓と名の間で値を交換できます。バックスペースを4回押す必要があります。最終的には、ユーザーがすべてを手動で入力する必要があることをほとんど考えずに5タップする必要があります。

これをモバイルアプリで使用します。Webフォームは、ユーザーが入力すると役に立たなくなる可能性があるオートフィルを既に提供しています。

免責事項:この例は数分以内に作成されたものであり、検証されていません。テストせずに製品にそのまま使用しないでください。これは、アプローチとそのような問題についての考え方に関するものです。

4.3。あなたが求めているフィールドに質問してください、それは相互作用パターンを反映しています、私は完全な誕生日を尋ねる必要がありますか?または、ユーザーが13歳以上であることを知っていることだけに関心がありますか?違いは、日付フィールドとチェックボックスです。ユーザーの時間と不満がどれだけあるかはご存知でしょう。

4.4。フィールドのグループ化とシーケンスは、ユーザーのメンタルモデルを反映しています。

4.5(正当な理由がない限り)パスワードの複雑さを誇張しないでください

4.6 @vlaz作成:完全な誕生日を尋ねる必要がありますか?

「おそらくそれはある種の統計的異常ですが、その情報を要求する多くのサービスは1月1日に生まれた不釣り合いな量の人々を引き付けます。」

ありがとう@vlaz

リストは続きます。

45
UX Labs

興味深い質問です。これに答えるには、ユーザーにとって何がイライラするのかを理解してから、代替の方法をいくつか提供する必要があると思います。

また、ユーザーがアカウントを作成する必要がない場合は、作成しないでください。

長形式

ユーザーは、さまざまなinputフィールドに大量の情報を入力するのが面倒だと感じるかもしれません。特に、ほとんどの情報が使用されない場合。絶対に必要な情報のみを収集し、最も効率的な方法で収集してください。ユーザーが多くのショートカットを取ることを許可します。これらのショートカットを含めるのは時間がかかり、非常に煩わしいかもしれませんが、UEを大幅に改善します。たとえば、住所フィールドに入力する必要がある場合、ユーザーに完全な住所、都市、州、国、郵便番号などを入力させる代わりに、ユーザーが住所を入力してフォームに自動的に検索し、情報を自動的に。また、メールの一般的なドメイン自動入力(@gmail.com@hotmail.com、65歳以上? @aol.com)。

パスワード、パスワード、パスワード

これは大きな問題です。誰もパスワードが好きではなく、誰もパスワードを思い出すことができません。彼らの承認評価は文字通り0%です。ただし、残念ながら、ユーザーを認証する方法が必要です。したがって、できる限りこれを簡略化してください。極端な要件(7.5文字(文字の0.5を入力する方法を理解する必要があります)、大文字、小文字、数字、連続した数字は使用できない、中国語の文字を含める必要があるなど)を入れないでください。これらは非常に迷惑ですユーザーにとって、多くの人はそれを正しく得る前に何度もそれを台無しにするでしょう。また、これはセキュリティのベストプラクティスでもありません。

別のサービス(Google、Facebookなど)でログインするオプションをユーザーに許可することは、適切なオプションです。

さらに、サインアップすると、自動的にサインインする必要があります。無数のWebサイトがこの愚かなことを行ってサインアップし、再度サインインするためにメール、ユーザー名、パスワードの再入力を要求されます。

最後に、ユーザーが何かを台無しにした場合、すべてをクリアして、ユーザーにすべての情報を再入力させないでください(ehemクライアント側の検証)。

検証

多くのWebサイトでは、何らかの形式のテキストまたは電子メールでの確認が必要になります。多くの場合、電子メールが遅延し、ユーザーは長時間待機します。確認前にユーザーが行っていたことを続行できるようにします。メール/テキストを確認する最後のステップとして、ユーザーが受信するまでの時間を確保します。

メールのスパム

シンプル:しないでください。ユーザーがあなたの製品を購入したい場合、彼らはあなたのサイトに行き、それを購入します、あなたは彼らに一定のリマインダーを送信する必要はありません"[RANDOM ITEM THE USER DOESN'T WANT] 50% OFF LIMITED TIME"。割引に関するメールをユーザーに送信する場合は、ユーザーにそれを希望することを伝えます。アイテムページまたは何か他のサブスクライブボタンがあります。

情報を共有しないでください

Facebookになりません。

53
JBis

あなたのユースケースについて私は何も知らないので、私は推測して申し訳ありませんが、私はそれを言う人になります:強制的にアカウントを作成しないでください。しないでください。ユーザーはいつアカウントを作成する必要があるかを理解できます。彼らがアカウントなしであなたのサイトを使うことを期待するなら、あなたはサイトが何をするかについて彼らを混乱させたか、それはおそらく可能です。

その強い意見は述べました、本質的にアカウントのように機能するいくつかのオプションがありますが、彼らがアカウントを作成したようにユーザーに感じません。インタラクション後、一意のリンクまたはコードをメールで送信できます(たとえば、「確認」メール内)。そのリンクまたはコードを使用して、将来的に関連情報(出荷情報など)にアクセスできます。あなたができるもう1つのことは、実際に目にしたことはありませんが、「情報を取得する」ページを提供することです。このページでは、電子メールアドレスを入力すると、リンク/コードが再送信されます。基本的に、これは、ユーザーがサイトにアクセスするたびにパスワードリセットメールを介してログインするようなものです。

上記の戦術とアカウント作成の境界はどこにありますか?あなたが彼らに関する情報を収集して保存したり、彼らの経験をパーソナライズしたりしない限り、私はこれを倫理的であると考えます。ユーザーが「アカウントにサインアップ」していない場合、何が収集され、自分のメールアドレスに関連付けられるかについて、プライバシーはある程度期待されていると思います。

32
usul

シングル・サインオン

SSOサービス を多用します。

できるだけ多くのプラットフォームのサポートを追加します。これは時間がかかり、サポートする数を増やすと互換性の問題が増加しますが、ユーザーが1つのタイプのシングルサインオンアカウントを持つ可能性が高いため、より多くのプラットフォーム(Android、iOS、Windows、Linux)をサポートしているように見えます。彼らが定期的に使用すること。

デフォルトでパスワードを生成する

私が見たもう1つの習慣は、必要に応じてパスワードを変更するオプションをユーザーに提供しながら、ユーザーのパスワードを生成することです。ユーザーが戻ってきたい場合は、書き留めるか変更します。もしそうでなければ、それは彼らを悩ませることさえないでしょう。あなたは彼らの電子メールを持っていて、彼らがパスワードのリセットを取得したい場合、ほとんどの状況で彼らの電子メール/電話にアクセスするのと同じくらい簡単ですので、パスワードが正しく生成されて送信される限り、セキュリティの実際の損失はありません。 HTTPSの。

ユーザー名を要求しない

最後に、ユーザー名をメールで知らせないでください。1つで十分です。

これらすべてをフォローする場合は、購入フォームで姓、名などを尋ねるだけです。これにより、アカウントの作成がほぼ透過的に行われ、ユーザーが契約条件に同意してcreateをクリックするだけで、煩わしさがなくなります。ユーザーが別のサイトのパスワードを再利用する傾向がないため、ユーザーが自分のパスワードを作成する必要がない場合、アカウントはより安全に作成されると主張することもできます。

26
David Kamer

オンラインでの購入について説明するとき、アカウントを作成せずにチェックアウトできるようにするのが最善です。彼らはまだ彼らの配達のためにたくさんの詳細を記入しなければなりません彼らがアカウントを作成したいなら最後に彼らに尋ねてください彼らが彼らの注文をより簡単にチェックすることができるように。

これを行うと、ユーザーにメリットがあるときに適切なタイミングでそれを尋ねます。

12
Martyn

ソーシャルサインアップを使用する

あなたは正しい新しいアカウントを作成するにはかなりの労力が必要であり、 調査対象者の86%がそれによって煩わしい と報告しています。ただし、ソーシャルサインアップ により、コンバージョン率が約52%増加することがわかっています

その理由を説明することは難しくありません。 ソーシャルサインアップに必要なのはワンクリックであり、あなたはにいます。使用する電子メールとパスワードを決定する必要がある従来の方法と比較して、最後に使用したパスワードを思い出し、新しいパスワードの作成を強制する可能性のあるパスワードルールに対処します。パスワードを思い出し、保存し、覚えるには、多くの認知的負荷が必要です。

ソーシャルサインアップを使用する非常に良い例は、 Pinterest です。

enter image description here

FacebookまたはGoogleにすでにログインしている場合は、ここをクリックする必要はありません。登録は事実上無摩擦です。さらに、 67%のユーザーは、ユーザー名やパスワードの作成を強制しないため、Webサイトに戻る可能性が高くなりますソーシャルサインアップにより、ユーザーエンゲージメントも向上します

enter image description here

最も人気のあるソーシャルログインオプションはFacebookとGoogleです。さらに、業種別の最も人気のある ソーシャルサインアップオプションの概要を示す包括的な調査があります

結論

ユーザー登録の苦痛を軽減するために提案されている他の方法の中で、有望な結果が示されているため、ソーシャルサインアップを検討する必要があります。サインアップに必要な作業が大幅に少なくなり、ユーザーエンゲージメントまたはリピーターが増加します。

6

イーサリアムブロックチェーンに基づいた全く新しいアプローチがあります。

これは「ユニバーサルログイン」と呼ばれます。基本的な考え方は、鍵ペアを作成し、その公開鍵からのメッセージを受け入れる契約をEthereum Blockchainにデプロイすることです。

ここでの目標は、イーサリアムエコシステムで最高のオンボーディングエクスペリエンスを実現することではなく、インターネット上のどこでも最高のログインを実現することです。まず、現在実行中のコードには次の利点があります。

  • どこでもパスワードを入力したり覚えたりする必要はありません
  • 複数のデバイスでの即時ログイン
  • 余分なものをダウンロードまたはインストールする必要はありません
  • 攻撃または漏えいする可能性のあるプライベートデータを持つ単一のサーバーはありません(ただし、ブロックチェーンで共有するパブリックデータに注意してください)
  • ユーザーは、1つのアプリで作成したアカウントを取得し、それを使用して別のアプリにログインできます。
  • アプリがオフラインになっても、ユーザーは引き続き自分のデータにアクセスできます
  • ユーザーが管理している

欠点は、ユーザーのアカウントを展開する必要があるコントラクトであるため、ユーザーを作成すること自体にコストがかかることです。

詳細はこちら: https://medium.com/@avsa/universal-logins-first-demo-1dc8b17a8de7

5
Blindripper

アカウントのないパターン

ユーザーにアカウントを作成させることなく、リッチなユーザーエクスペリエンスを作成できます。 3つの顕著な例:PUBG Mobile、Imgur、Microsoft Office。

ゲストアカウント:PUBG Mobileはゲストアカウントを提供しています。ユーザーはグローバルに一意の識別子で識別され、完全なゲームプレイ体験を進めることができます。アカウントはオプトインであり、マルチデバイス同期とクラウドバックアップのロックを解除することで、より優れたエクスペリエンスを提供します。ユーザーがPUBG Mobileに十分な時間をかけてこれらの機能を必要とする場合、アカウントが必要になる可能性があります(強制されているのではなく)。アカウントなしでアプリ内購入ができるかどうかわかりません。個人的な逸話:PUBGではアカウントなしで簡単にプレイを開始できるため、Fortnite(アカウントが必要)ではなくPUBG Mobileを試しました。

使い捨てアカウント:Imgurは匿名のアップロードを許可します。ブラウザセッションが終了すると編集できないと思います。追加のコミュニティ機能により、アカウントの作成を選択したユーザーが利用できるようになります(使用量の増加に伴い、アカウントの必要性に徐々に移行しているようですが、確実に知るには十分に使用していません)。

データファイル:Microsoft Officeは、データを操作するためのツールを提供しますが、ユーザーのコンピューターにデータを保存します。 Microsoft 365バージョンのExcelには、アカウントを作成する代わりに、同期やその他のクラウド機能が追加されています。多くのアプリケーションは、ドキュメントをユーザーのコンピューターではなくユーザーのDropboxアカウントに保存することにより、このアプローチを実装しています。

マッチメイキング:注目すべき例は知らないが、WebRTCチャットアプリはあまり一般的でない例を提供している。つまり、ユーザーがサイトにアクセスしてワンタイムトークンを生成し、そのトークンをチャットを開始する他の誰か。トークンは、1回の使用を超えて持続する場合と持続しない場合があります。

上記が、アカウントなしで人々にあなたのアプリを使わせることができるかもしれないいくつかの方法を考えるのを助けることを願っていますこれらの例が示すように、ユーザーがあなたに(または永久に)アカウントを要求するまで、アカウントの作成を延期することが可能です。

3
Michael Hogan

前提として、企業はユーザーがアカウントを作成することを絶対に望んでいます。たとえば、個人情報などを保持します。

重要な情報を収集する方法です

パッシブ登録を使用すると、ユーザーはアカウントを作成することなく、購入手続きの一部としてデータを収集できます。購入の最後に、ユーザーが任意に提供した情報に基づいて作成されたアカウントが必要かどうかをユーザーに尋ねることができます。

ユーザーがアカウントの作成を選択した場合:強制登録せずにビジネスニーズを満たしている

アカウントを作成しないことを選択した場合:おそらくGDPRに違反し、ユーザーはとにかく強制登録を受けていなかったはずです。

3
colmcq

仮定:
これはeコマースのショッピングサイトに関するものです。
SaaS製品通常は、有意義な作業を開始する前にアカウントを必要とします。

誤解を捨てる

最初に、この議論の最大の誤解(ここだけでなく、e-commとユーザビリティ業界全体)を取り除きましょう:

セキュリティは問題ではありません

考えてみてください。アカウントを作成するかどうかに関係なく、どういうわけか私からの支払いを回収することを許可します。これはトランザクション全体で最大のセキュリティリスクであり、回避策はありません。 Paypalや他の同様のサードパーティハンドラーは、このリスクを大幅に軽減しようとしましたが、どういうわけかそのサービスに接続する必要があります。

アカウントの飽和が問題です

ユーザーがさらに別のアカウントを作成する必要に直面したとき、彼らはすぐに、頭の中ですでに乱闘している他のすべてのアカウントについて考えます。ほとんどの人はパスワードマネージャーを使用しないため、購入を完了するためだけに別のアカウントを山に追加することは、面倒で、煩わしく、時には圧倒されます。

アカウント作成をオプションにする

これは、より健康的なチェックアウトファネルへの第一歩です。アカウントの作成がどれほど簡単(または安全)であっても、気にしたくない人もいます。そして、あなたはそれらを必要としません。発送と請求に必要なすべての情報を入力してチェックアウトを進め、それ以上は要求しないでください。

ユーザーにチェックアウトの終了で参加させます

リアリティグラスを装着する:ユーザーは、チェックアウト時にアカウントに必要なほぼすべてのものを提供しました。ほとんどの場合、欠けているのはパスワード(またはソーシャルアカウント接続)だけです。

リピート訪問者(簡単なリピート注文)と取引ショッパー(販売通知)の利点と、必要なものがほぼすでにあるという事実を説明すると、ほとんどの顧客は、最後のフィールドを入力して喜んでいます。

置く Create my accountボタンとパスワードフィールドがチェックアウトの最後にあります。以前にオプトアウトした人がどれだけ多く入っているかに驚かれることでしょう。

ソーシャルサインオンを提供する

O-authのすべてが数年前に登場したとき、それがビジネスをどのように変えるかを理解した人はほとんどいませんでした。セキュリティの影響がありました。重要なアカウントの詳細を、それらを保護することに重点を置いた組織に保管しました。そして、それは主に価値の小道具でした。

しかし、時間の経過とともにユーザーリサーチを開始したときの最大の利点は、ユーザーはどこでも1つのサインインについて考えたいということでした。真実は、Facebookアカウントを使用してe-commサイトにサインインすることは、ほとんどの場合、特定のサイト用のスコープ付きアカウントを作成するよりも安全性が低いことです。しかし、ユーザーはその問題を理解したり気にしたりしませんでした-覚えるアカウントを減らしたいだけでした!

ソーシャルサインオンを提供することは、長年にわたって要件となっています。誰もがそれを望んでいるわけではありませんが、ほとんどの人が望んでいます。これをチェックアウトのサインアッププロセスに追加すると、多くの新しいアカウントが作成されます。

2
plainclothes