ユーザーができるだけ早くWebサイトを使用できるようにしたいので、できるだけ最小限のサインアップで、公開したい場合はプログレッシブプロファイリングを使用して後で情報を取得したいと考えています。
基本的に私の2つの目標は次のとおりです。
これは私がこれまでに思いついたものです:
とても簡単です:
これは、ユーザーの労力を最小限に抑えてWebサイトの使用を開始する最も簡単なサインアップであるように思えます。
これは簡略化できますか?他に試された真の最小限のサインアップモデルはありますか?
ユーザーがサインアップしてサイトを使用するためのハードルをできるだけ低くしたい。後でそれらの情報を取得できます(名など)。
Stripe.com(支払い処理業者)は、さらに「即時」のサインアッププロセスを提供します-それらを一緒にスキップすることができます。どのゲストも、サインアップ情報を入力する前に、ダッシュボードの使用を開始し、設定のカスタマイズ、模擬トランザクションのテスト、および顧客プロファイルの作成を開始できます。ユーザー名、パスワード、電子メールはありません。アカウントを作成する必要があるのは、実際にシステムを使用して実際の支払いを受け入れる場合のみです。
以前に使用した他のいくつかのサイトは、同様のフローを利用しています。ゲストユーザーが可能な限り多くのプラットフォームにアクセスできるようにし、Cookieを使用してセッション間で設定を保存してから、個人情報を要求します。開発者にとってはより多くの作業が必要ですが、潜在的なユーザーにとってははるかに高速で「見えない」プロセスです。
編集:
私はルミPに同意します。あなたの最初の目標は、単に訪問者をサインアップさせるだけではなく、サイトに戻って実際にサイトを使用させることです。サインアップは重要なステップですが、目標ではありません。基本的なフローは次のようになります。
(私はあなたが本当にどこにでもそれらを挿入することができるので、フローから導入/チュートリアルを削除しました-どんな複雑/敏感/センセーショナルな機能もコンテンツなどのコンテキストヘルプリンクを持つことができます)
私はあなたにいくつかの洞察を与えることができる図を描きました。
したがって、あなたの仕事は、フローを設計することです。これは、ユーザーを決定ポイントに導きます。サインアップを要求する前に、価値と優れた経験を身につけた人は、製品またはサービスとの関係を作り、 loss aversion 効果をもたらす可能性があります。それでも、それがまだ得られていない場合、ユーザーは2番目のチャンスがあります。
意思決定の瞬間は、いくつかのイベントに結び付けることができます。
OAuth
OAuth(facebook、Twitter、Gmail intergration))を使用すると、ユーザーのサインアップに使用したサービスからユーザーのメールアドレスを取得し、ユーザーが必要に応じて変更できるようにしてから、[保存]を押すことができます。
そうすることで、OAuthサービスプロバイダーがサービスの課金または停止を決定した場合でも、ユーザーアカウントがリンクされており、認証を受けることができる電子メールアドレスがまだあります。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
ブライアンの回答 に同意します。登録の最初のステップをスキップします。これがなぜ最も効果的であるかについての詳細な説明は次のとおりです。
目標の1つを「サインアップする」と定義しました。しかし、通常のホワイトハットビジネスとして、これは本当にあなたの目標ではありません。あなたの目標は、フィールドに「通常」の定義が何であれ、通常のユーザーになることです。使用されていないアカウントはあなたに利点を与えません。例外:1)マーケティング目的で使用する予定の有効な電子メールアドレスおよび関連のコレクションを構築している場合、これは不快なものから違法なものまでさまざまです。2)投資家を感動させ、「 100万人のユーザー向けのスライドがあります。しかし、彼の価値がある投資家は、アクティブユーザーと有料ユーザーの割合を尋ねます。だから、私はあなたがどちらの例外も気にしないと仮定し、典型的なフリーミアムモデルでは、あなたのゴールツリーのルートは:
非ユーザーはどのようにしてアクティブユーザーに変換しますか?ユーザーを3つのグループに分けましょう:decided-againstソリューションを使用して、decided-forそれ、そして未定。最初の2つについては何もできません。未決定のビジターをあなたのサイトに変換して、決定済みのものにしようとしています。ユーザーの観点から見ると、プロセスは次のようになります。
トライファーストソリューションでは、このプロセスは詳細でサポートされています。サインアップはステップ5で行われます。
サインアップファーストのソリューションでは、サイトはプロセスにあまり適合していません。しかし、ユーザーはユーザーが常に行うように行動します。つまり、プロセスに合わせてソフトウェアを曲げます。逆ではありません。したがって、彼らはまだ上記のプロセスに従います。今すぐサインアップはステップ2で行われ、ソフトウェアに対する賛成または反対の決定はステップ4で行われます。新しく決定されたユーザーはすべて、サービス/製品のアカウントを取得します。これは、ユーザーを決定するものではなく、後でサイトに戻ることもありません。
サインアップについて何かを調整して、決定を下すことができますか?いいえ、できません。上記の条件で非常に少ない労力でサインアップしても、ユーザーにコミットメントは生じません。必要な労力を増やすと、彼のコミットメントが増加しますが、ステップ2で終了するユーザーの割合も増加します。そのための数はありませんが、試用の障壁を減らすという業界の傾向(おそらく、質問を作成するため)終了する顧客の増加が不釣り合いに高いことを確認しているようです。
そして、最初に試してみる方法は、サイトに来る前に決心していたユーザーとの関係を損ないませんか?いいえ、ありません。彼らは積極的にサインアップしたいです。彼らがそうすることを止めることができる唯一の方法は、彼らがそれらが誤っていることを見つけ、あなたの解決策が彼らにとって良くない場合です。とにかくサインアップした後、それらの人々は非アクティブになっていただろう。
つまり、ユーザーにしたくないことを強制することはできません。彼らがアクティブなユーザー/顧客になりたくない場合は、サインアップしたかどうかに関係なく、アクティブになります。あなたと一緒にいることに決めた人のためにサインアップを維持し、他の人が最初に試してみましょう。
ここでは3つのステップを簡略化できます。
1-ホームページ自体に電子メールフォームを用意します。それは控えめですが、余分なクリックとステップを節約します
2-アプリを使用する前に、確認の電子メールをスキップすることを検討してください。代わりに使用を開始した後で確認してください。それでも、「後でアカウントに再度ログインできるようにするための」確認段階でパスワードを設定するように依頼することもできます。
3-常に「ウェブサイトの使用」にそれらを着陸させますが、必要に応じてチュートリアルを見つけるためのUIのオプションを提供します。
上記すべての場合、次のようになります。1-ホームページからサインアップします。 2-「ウェブサイトの使用」ページをすぐに表示します。 3-メールを確認し、後でパスワードを作成します。
これには、パスワード作成ステップが、最初の試行後にサイトを使い続けるのに十分なほどサイトに関心があるかどうかを追跡するための基本的な「アクティブ化」メトリックであるという素晴らしい利点があります。有用!
質問に答えてくれて許してください。
1
。ホームページから、「サインアップ」をクリックします(この時点で確認メールが送信されます)
それはあなたのメールアドレスを知る前にどのようにメールしますか?また、ユーザーがサイトについてまだ何も知らないのに、なぜ「サインアップ」したいのでしょうか。
2
。サインアップフォームで、電子メールアドレスを入力して[送信]をクリックするだけです
なぜこれが別のフォームでなければならないのですか?
3
。新しいページで、チュートリアルに進むか、すぐに始めるかを尋ねられます
なぜこれを尋ねる必要があるのですか?最初のチュートリアルから始めて、スキップリンクを提供することはできません(またはその逆-サイトが行うことから始めて、チュートリアルリンクを提供します)。
4
。チュートリアルを見るか、ウェブサイトの使用を開始します
チュートリアルが必要かどうかわからないときに、チュートリアルを見たい人はいますか?人々がサイトの使用を開始できるようにし、問題が発生した場合は支援してください。また、サイトを使用するためにチュートリアルが必要な場合は、サインアッププロセスよりも大きなUXの問題があります。
5
。後でメールにアクセスし、メールのリンクに移動してアカウントのパスワードを作成することにより、アカウントを確認できます。
私はこれで何も悪いことを考えることはできません。
Simplify。ユーザーがチュートリアルを参照してWebサイトを探索できるようにします。彼らが通常のユーザーのように感じ始めたら、サインアップする理由を伝えます。
このWebサイトの探索中に、ユーザーに関する情報を収集できます。サインアッププロセスは、カジュアルなconversation、つまり実際にはインタビューとして表示されます。これにより、サインアップ情報フィールドをサインアップボタンだけに置き換えることができます。
例、チュートリアル中:「ようこそ、誰と話してもいいですかFill in firstname。」
最善の解決策は、明らかに保存する前にサインアップしないことです。
しかし、サインアップが必要な場合、 [〜#〜] sqrl [〜#〜] は、基準に完全に適合する有望な新しいアイデアです。ただ、まだ実装もロックイン仕様もないため、フューチャーウェアです。これまでのところ。
Facebook/Twitterプロファイル統合の使用を検討しましたか?これは、私が見たWebサイト/アプリにサインアップする最も速い方法です。