モバイルアプリでのサインイン、サインアップ、ゲストフォームへのアクセスを、煩わしさを最小限に抑える
大学のクラスでは、実際のクライアント（自治体）用のモバイルデバイス用のアプリケーションを作成します。アプリは、上記の自治体の住民が道路の損傷、券売機の問題などに関する苦情を提出することを可能にします。
実装時に、サインアップ/インフォームのデザインに関する問題に遭遇しました。クライアントの要件に従って、アプリを使用するために少なくともメールアドレスを入力することは必須です。これにより、クライアントはユーザーに連絡を取り、さらなる問い合わせや感謝状を送ることができます。したがって、実装するシナリオは3つあります。
- 理想的には、ユーザーは少なくともメールアドレスとパスワードを含むアカウントを作成（->登録）して、後で苦情のステータスを確認します
- すでにアカウントをお持ちの場合は、上記の資格情報でログインできます
- アカウントを作成する手間をかけずに苦情を申し立てるには、メールアドレスのみが必須である半匿名オプションがあります
以下は私のグループと私がこれまでに思いついたものですが、できるだけ快適なエクスペリエンスを実現したいので、まだ結果に満足していません（理想的には、サインアップする必要がないことが理想的ですが、しかし、それはまったく別のお茶です）。
サインアップボタンをタップすると、同じ2つの入力フィールドを含む登録フォームが開きます。他の個人データ（住所、名前など）の入力はオプションであるため、アプリ内設定内で目立つ場所にフォームを配置することにしました。アプリは基本的に、いずれにしてもオプションが多すぎる単一目的のアプリであり、見つけるのはそれほど難しくありません。
質問： 3つのシナリオを実装するより良い方法を考えられますか？また、どのフィールドが必須であるかをどのように伝えることができますか（サインアップまたは-in：メールとパスワード、guest：メール）
ログインフォームをandにサインインするための多目的フォームとして使用することを考えましたが、これにより混乱が生じすぎます。
（これは「宿題をしてください」という種類の質問ではありません。ユーザーエクスペリエンスを改善することに本当に興味があります。UXはクラスの目的でさえありません）
デフォルトのアクションを提供し、そこからユーザーの設定を更新します。
必要最小限の情報は電子メールなので、残りの苦情/懸念フォームにインラインで入力してもらいます。ユーザーは電子メールを入力し、苦情を入力して送信を押すだけです。早くて簡単。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
パスワードを入力する仕組みを簡単に追加できます。ユーザーの電子メールがユーザー名であると仮定しましょう（多くの場所でこれが行われているため、ここでは簡単に説明しますが、ここではそれが当てはまると仮定します）。ユーザーに自分の電子メール/ユーザー名をすばやく入力して、パスワードを入力できるようにします。新しいフィールドはページをリロードする必要がなく、フォームの他の部分と簡単にインラインで表示できます。パスワードのない人には邪魔になりませんが、パスワードを持っている人にはすぐに追加できます。
最後に、アカウント作成のより複雑なプロセスを実行する明確な方法を提供します。これにはダイアログボックス、またはページからのナビゲーションが必要であると想定して、視覚的に区別できるボタンにします。また、理想的にはアカウントを作成してもらいたいので、その方法を視覚的に明確にすると、ユーザーのサインアップが促されます。
理想的には、ユーザーは少なくともメールアドレスとパスワードを含むアカウントを作成（->登録）して、後で苦情のステータスを確認します
これは推奨されるメカニズムですが、最も一般的ですか？本当にユーザーの好みに応えたい場合は、どのそれら優先メソッドを知っているか確認してください。上記の例では、電子メールを入力するだけで済むようにしたいと思います。私は個人的にはこのWebサイトをあまり使用しないつもりです（子供たちが私の芝生を降りないだけの場合を除きます）。その場合、長いサインアッププロセスを行いたくありません。
ただし、ビジネス上の決定がユーザーの好みより優先される場合があります。自治体reallyが登録の長いプロセスを経ることを好む場合は、フォームを再調整して、匿名メソッドをより隠したログインに焦点を当てます。
これはあなたがすでに持っているものに沿って非常に何かに落ちるでしょう。それは、オプションの注文をレイアウトする最良の方法をどのように決定するかにかかっています。
これにより、ユーザーは優先するログイン方法にすぐにアクセスでき、新しいアカウントの作成方法が明確になり、フォームに電子メールを入力するだけで済みます。
補足：匿名でない場合は、「匿名」と呼ばないでください。あなたの電子メールを提供することは匿名ではありません。
ある意味で、これはオンラインでの購入方法とよく似ています。
ストア、またはこの場合は自治体は、ユーザーがアカウントを作成した場合に優先します。
この場合、自治体はユーザーがアカウントを作成することを好むと主張しますが、苦情は反動的であり、通常は匿名で行われることが好ましいため、おそらくそうではありません。
苦情が行われるいずれの方法でも、電子メールアドレスが必要です。ログインの唯一の本当の利点は、苦情が提出された後にそのステータスを確認することです。
また、オンラインストアと同様に、苦情/注文のステータスへのリンクをユーザーに送信するか、更新をメールで送信することを検討できます。これにより、匿名を希望する場合でも、ステータス/パッケージの最新情報を入手できます。 -配達。
ログインは完全にオプションであり、いずれにしてもメールアドレスが必要なので、最も簡単な最初のステップは、匿名またはログオンのステップをスキップして、メールアドレスを含む苦情フォームを表示することです。
苦情の作成中に、ユーザーがログインを希望する場合は許可する必要がありますが、ユーザーがすでに入力した情報は保存されます。そのため、メールはメールフィールドに送信され、ログイン後も苦情が持続します。
さらに、ログに記録されずに苦情が出されたからといって、必ずしもアカウントがないことを意味するわけではないので、入力された電子メールが既存のアカウントと一致する場合、そのユーザーがログインするときに、その苦情をそのアカウントに属するものとして扱うことを検討してくださいユーザー。
アカウントが作成される前に行われた苦情への同上。既に苦情を申し立てているメールアドレスのアカウントを作成した場合、それらの苦情を新しいアカウントに属するものとして扱うことを検討してください。
すでに書かれているコメントのほとんどには同意しますが、あなたに役立つように、もう少し追加したいと思います。
「絶対に必要になるまでユーザーにログインを要求するのを遅らせる」ことを提案するすばらしい記事がいくつかあります（参照： http://www.sitepoint.com/improving-apps-onboarding-ux/ ）。 iTunesストア、AirBnB、Quoraなどと同様に、ユーザーがログインする前に、アプリケーションがユーザーにどのような価値を提供できるかを示し、どうしても必要なときにだけログインできるようにする方法を考えてみてください。あなたの場合、これは、たとえば、解決された提出の結果の表示、提出自体（公開されている場合）、または少なくとも（すでに提案されているように）苦情の作成などです。
ログインフォーム自体に関して、いくつかの提案を次に示します。
- 信頼できるサードパーティ（OpenID、Google、Facebookなど）でログインしますか？この道を進みたくない理由はいくつかありますが、多くのユーザーにとって便利です。
- 正常に登録する前にユーザー名を必要としない-彼らは後でそれを行うことができます（それが必要な場合でも）
- ユーザーがパスワードを繰り返すのではなく、パスワードのマスクを解除できるようにする
- 人間を煩わせる通常のキャプチャではなく、逆キャプチャを使用してロボットを停止する
（ソース： http://www.smashingmagazine.com/2011/05/05/innovative-techniques-to-simplify-signups-and-logins/ ）
最後に、登録とログイン後に何が優れたユーザーエクスペリエンスになるかについて注目すべき研究があります。心理学では「ゴールグラデーション効果」と呼ばれ、すでに完了した目標をユーザーに提供すると、ユーザーはすでに勢いを増しており、タスクを完了する可能性が高くなります。これは、「復活目標-グラデーション仮説」を発表したキベッツ、ウルミンスキー、鄭による2006年の研究に基づいており、「2度スタンプされた10スペースのコーヒーカードは、8スタンプよりも速くスタンプされます。 」 （詳細をご覧ください： http://coglode.com/gems/goal-gradient-effect ）。
あなたのケースでは、タスクは1種類しかないようですが、より多くの送信を完了したユーザーに対して視覚的な「報酬」を検討することができます（たとえば、5つの苦情を送信したユーザーは「ゴールド」ユーザーです）。これはプロジェクトの範囲をはるかに超える可能性がありますが、さらに構築したい場合に検討するのに役立つ原則です。