Gmailの確認は本当にユーザーフレンドリーですか？
Gmailにアクセスしたいのですが、Web経由でログインしようとすると、「確認する」という警告が表示されます。携帯電話を紛失したり、電話が切れたり、ネットワークがダウンしたりした場合、コードを確認できず、Gmailにアクセスできません。
Gmailの確認は本当にユーザーフレンドリーですか？
私はこれを最初にコメントとして書きましたが、今日、私の妻がそれがいかに悪いかを示す別のユーザー事例があったことを思い出してください。
あなたの特定の質問に答えるために：全くそうではありません。実は、私は記事を書きました（スペイン語で、見ることができます here ）。タイトルの翻訳のみ：*使いやすさ、アクセシビリティ、およびセキュリティの障害...同時に。」.
この記事の例は、一般的なユーザーの事例を示しただけです。インターネットカフェで自分のアカウントにアクセスし、眼鏡を忘れてしまいました。そこから、すべての地獄が壊れました。その記事からの結論は「それは最高ではありませんが、悪くはありません」
今日、私はその意見を検討する必要があります。
別のユーザーケース...別の失敗
妻は、何ヶ月も使用しなかった古いGoogleアカウントでメールを確認する必要がありました。彼女はまた、新しいオフィスで新しいコンピュータを使用する必要がありました。
彼女は最も一般的なパスワードを試しましたが、役に立ちませんでした。それで、彼女はセキュリティの質問を求めました、そして、どういうわけかそれは間違っていました（当然のことながら、私の妻はすべてを忘れているが、それでもなおです）。
彼女はついに、今回はYahooから、ファイルに登録されている予備のメールアドレスにコードを送信するように求めました。
コードを入手したら、彼女はそれを使用しようとし、次のようなメッセージを受け取りました
「このログインを確認できませんでした。別の方法をお試しください」
したがって、彼女は最終的に電話で送信するように要求する必要がありました。このため、ファイルに登録していないため、電話を含める必要がありました。次に、デバイス画面間を移動する必要がありました(phone --> computer)実際にコードを取得するには、コードを入力して、15〜20分後に実際にアカウントにアクセスできるようにします。
私のユーザーのケースはどういうわけかEdge-ish（個人的には、あなたのメガネを忘れることは正確にエッジがきいていないと思いますが...）、私の妻のためのものは本当に一般的です。
その上、Googleのような会社が次のような一般的なケースをテストすると思うでしょう...別のコンピューターを使用して！。これはエッジケースではありません、これは現在のstate-of-the-artの定義全体であり、それで惨めに失敗する。 面白いのは2年前のプロセスで、ほとんど問題がなく、はるかに安全でした！
シュナイダーマンのインターフェイスデザインに関する8つのゴールデンルール
これは特定のユーザーケースに基づく意見にすぎないと考える人には、「 Shneiderman's Eight Golden Rules of Interface Design 」で始まる、これを測定する一般に受け入れられているヒューリスティックがあります。以下をお読みください：
これらのルールは、Ben Shneidermanによるテキスト「ユーザーインターフェイスの設計」から取得されました。 Shneidermanは、経験からヒューリスティックに導き出され、適切に洗練、拡張、および解釈された後、ほとんどのインタラクティブシステムに適用できるこの原則のコレクションを提案しました[9]。アプリケーションの使いやすさを向上させるには、適切に設計されたインターフェースを持つことが重要です。 Shneidermanの「インターフェイスデザインの8つのゴールデンルール」は、優れたインタラクションデザインのガイドです。
1一貫性を追求します。同様の状況では、一貫したアクションのシーケンスが必要です。プロンプト、メニュー、ヘルプ画面でも同じ用語を使用する必要があります。一貫したコマンドを使用する必要があります。
議論の余地があります。明らかに、デバイス間をジャンプする必要があることは、あなたが見つける最も一貫した経験ではありません。しかし、デバイス間で一貫していることを認めましょう。つまり、50/50です。
2頻繁なユーザーがショートカットを使用できるようにします。使用頻度が増えると、ユーザーのやり取りの数が減り、やり取りのペースが上がります。略語、ファンクションキー、隠しコマンド、およびマクロ機能は、上級ユーザーにとって非常に役立ちます。
失敗明らかに、デバイス間をジャンプする必要があると、ショートカットをまったく使用できなくなります。さらに、最も友好的なシナリオであっても、相互作用が増加します。これは客観的な尺度であるため、議論の余地はあまりありません。
3有益なフィードバックを提供します。オペレーターのアクションごとに、システムフィードバックが必要です。頻繁でマイナーなアクションの場合、反応は控えめになる可能性がありますが、まれでメジャーなアクションの場合、反応はより大きくなるはずです。
議論の余地があります。フィードバックは有益であると言えます。それをどうするかが少し矛盾していて、1つのデバイスでフィードバックがあり、別の上。しかし、まあ、それは完全な失敗ではないとしましょう。
4クロージャを生成するためのダイアログを設計します。アクションのシーケンスは、開始、中間、終了のグループに編成する必要があります。アクションのグループの完了時の有益なフィードバックは、オペレーターに達成の満足感、安心感、不測の事態の計画とオプションを心から捨てる合図、そして次のグループに備える方法が明確であることを示しますアクションの。
失敗。これが現実に近いものではないことに同意できますか？まったく逆です！
5単純なエラー処理を提供します。可能な限り、ユーザーが重大なエラーを発生させないようにシステムを設計します。エラーが発生した場合、システムはエラーを検出し、エラーを処理するためのシンプルでわかりやすいメカニズムを提供できる必要があります。
失敗。繰り返しますが、最も単純なアクションを実行する必要がある場合：a）別のデバイスを持っているまたはb）家に戻り、いつも使っていたのと同じデバイスを使用します単純な方法でエラーを処理できないことは明らかです。たとえば、携帯電話がなくて外出中の場合はどうなりますか？ 自分の情報にアクセスできません！使いやすさの定義！
6アクションの簡単な逆転を許可します。この機能は、ユーザーがエラーを元に戻すことができることを知っているため、不安を和らげます。したがって、見慣れないオプションの探索を促進します。可逆性の単位は、単一のアクション、データ入力、またはアクションの完全なグループです。
失敗。明らかに、デバイス間をジャンプする必要があることは文字通り不可能です。
7内部の制御の軌跡をサポートします。経験豊富なオペレーターは、システムを担当し、システムがアクションに応答するという感覚を強く望んでいます。ユーザーを応答者ではなくアクションの開始者にするようにシステムを設計します。
失敗。すべての最大の失敗：Googleはユーザーの制御を故意に拒否します。
8短期メモリ負荷を軽減します。短期メモリでの人間の情報処理の制限により、ディスプレイをシンプルに保ち、複数ページのディスプレイを統合する必要があります。ウィンドウの動きの頻度を減らし、コード、ニーモニック、およびアクションのシーケンスに十分なトレーニング時間を割り当てます。
議論の余地があります。個人的にそれは失敗だと思いますが、単純なアクションを実行するには、複数のデバイスとプロセス、そしてそれはまだ許容可能なUXであり（そして、私がこの受け入れに至った方法の手がかりは本当にありません）、おそらく、これを1つ通過させることができます。
要するに
問題は、Googleが常に非常に安全であると見なされることを懸念していたことです。 結局のところ、彼らは世界中のほとんど誰のデータも持っています！しかし、Googleには優れたUXチームがありますが、UXとユーザビリティは最強の側面ではありませんでしたGoogle（彼らのUXチームは素晴らしいので、理由はわかりません。おそらく政治とエゴですが、本当にわかりません）。
結論は次のとおりです：一般的なユーザーのケースが悪夢になる場合、答えはいいえ、それは本当に悪いです
これが表示される理由は、多要素認証がアクティブ化されたためであるという事実を理解する必要があります。
プロセスがあまりシームレスに見えないことについての懸念を理解しました。しかし、特に複数のデバイスが関係している場合、Googleやこれを行うための他のアプリケーションを実際に誤ることはできません。
最初のオプションは、リンクされたデバイスにアクセスするのと同じくらい簡単です。また、ユーザーが[〜＃〜] would [〜＃〜]代替手段、セキュリティ、または同期がない場合は文句を言うことに注意してください。
ポイントは、優れたUXは必ずしも1ステップのプロセスや完全に非侵入型のプロセスである必要はないということです。
これはユーザーフレンドリーですか？
学期の結果が記載されたメールを大学から急いで削除しない限り、yesです。