使いやすさのガイドライン
ジェイコブのニールセンヒューリスティックに準拠しているかどうかを確認するために、いくつかのWebサイトを評価することになっています...しかし、ヒューリスティックを理解するのに問題があります。誰か説明してもらえますか？
これらは、ユーザーインターフェイス設計の一般的な10の原則です。これらは、特定のユーザビリティガイドラインよりも経験則に基づいているため、「ヒューリスティック」と呼ばれます。
- システムステータスの可視性システムは、適切なフィードバックを適切な時間内に通すことで、常にユーザーに何が起こっているかを通知する必要があります。
- システムと現実世界の一致システムは、システム指向の用語ではなく、ユーザーが使い慣れた単語、フレーズ、および概念でユーザーの言語を話す必要があります。実際の規則に従って、情報が自然で論理的な順序で表示されるようにします。
- ユーザー制御と自由ユーザーは誤ってシステム機能を選択することが多く、拡張ダイアログを経由せずに不要な状態を残すために明確にマークされた「非常口」が必要になります。元に戻すとやり直しをサポートします。
- 一貫性と標準ユーザーは、異なる単語、状況、またはアクションが同じことを意味するかどうか疑問に思う必要はありません。プラットフォームの規則に従います。
- エラー防止最初から問題が発生しないようにする慎重な設計は、適切なエラーメッセージよりも優れています。エラーが発生しやすい状態を解消するか、それらを確認して、アクションを実行する前に確認オプションをユーザーに提示します。
- リコールではなく認識オブジェクト、アクション、オプションを表示して、ユーザーのメモリ負荷を最小限に抑えます。ユーザーは、会話のある部分から別の部分への情報を覚えておく必要はありません。システムの使用手順は、適切な場合はいつでも見えるようにするか、簡単に検索できるようにする必要があります。
- 柔軟性と使用効率アクセラレータ-初心者ユーザーには見えません-は、システムが経験の浅いユーザーと経験豊富なユーザーの両方に対応できるように、エキスパートユーザーのやり取りをスピードアップすることがよくあります。ユーザーが頻繁なアクションを調整できるようにします。
- 美的でミニマリストなデザインダイアログには、無関係またはまれにしか必要とされない情報を含めないでください。対話における追加の情報単位はすべて、関連する情報単位と競合し、それらの相対的な可視性を低下させます。
- ユーザーがエラーを認識、診断、および回復できるように支援するエラーメッセージはプレーンコード（コードなし）で表現し、問題を正確に示し、建設的に解決策を提案する必要があります。
- ヘルプとドキュメントドキュメントなしでシステムを使用できる方が良い場合でも、ヘルプとドキュメントの提供が必要になる場合があります。そのような情報はすべて、検索が簡単で、ユーザーのタスクに焦点を当て、実行する具体的な手順を列挙し、大きすぎないようにする必要があります。
- システムステータスの可視性-ユーザーは常に現在何が起こっているかを理解する必要があります。彼女はシステムのどこにいますか（たとえば、ナビゲーションメニューの右側のタブを強調表示します）？システムは何をしていますか（ページの読み込み時にアニメーションを読み込むなど）？エラーがある場合-何が悪いのですか（たとえば、ユーザーが間違ったパスワードを入力した場合、パスワードフィールドの下の「間違ったパスワード」メッセージ）
- システムと現実の世界の一致-サイトでは、ターゲットユーザーが理解できるラベルと用語を使用する必要があります（例：マスマーケットのeコマースサイト、 「光学写真装置」の代わりにカメラのセクションを「カメラ」と呼びます）。
- ユーザーコントロールと自由度-ユーザーは簡単にミスを修正したり、アクションを変更したりできる必要があります。つまり、特に理由がない限り、ユーザーが行うすべての操作を元に戻すことができます（たとえば、Officeスイートアプリの[元に戻す]ボタン）。
- 一貫性と標準-システムは同じものに同じ単語を使用する必要があります（たとえば、一部の場所ではユーザーのアカウントを「プロファイル」と呼ばず、ユーザーファイル」など）。また、誰もがオブジェクトを説明するために使用している特定の用語がある場合、システムはそれも使用する必要があります（たとえば、ワールドワイドウェブを説明するために、「ネット」の代わりに「ウェブ」という用語を使用します）。
- エラー防止-システムは、ユーザーが犯しがちな間違いを防止する必要があります（たとえば、Gmailで、電子メールに「添付」という単語を書いた場合）ファイルを添付しないと、ファイルを添付するかどうかを尋ねるメッセージが表示されます）。
- リコールではなく認識-システムはユーザーに、記憶に頼るのではなく、アクションを完了するために必要なすべての情報を表示する必要があります（例：カスタマーサービスフォームで、ユーザーにトランザクションIDを入力してもらう場合は、最近のトランザクションとそのIDのリストを表示します）。
- 柔軟性と使用効率-エキスパートユーザーがより迅速にアクションを実行できるようにする必要があります（ショートカット、ホットキー、マクロコマンドなど）。
- 美的でミニマリストなデザイン-システムは、メッセージを伝えるために、テキストやその他のデザイン要素を最小限にとどめる必要があります。そして、すべてが視覚的にも魅力的でなければなりません。 AppleのWebサイト は、この良い例と考えられています。
- ユーザーがエラーを認識、診断、および回復するのを支援します-エラーメッセージはユーザーが簡単に読んで理解できるようにし、修正方法を指示する必要がありますこれ（たとえば、「エラー1052」と書かずに、ユーザーが自分で解決策を検索できるようにしてください。代わりに「見つかりませんでした。設定で携帯電話のGPSをオンにしてください」と書いてください）。
- ヘルプとドキュメント-どのシステムにも、ユーザー向けに書かれたシンプルで検索可能な「マニュアル」が必要です（つまり、ユーザーが必要とするものに焦点を当て、エンジニアが開発しました）。 Microsoftのサポートセンター はこれでうまく機能すると思います。
心配しないで！ UXキャリアもヒューリスティック評価から始めました。できます！
Nielsenのヒューリスティックは、始めたばかりの場合は少し抽象的です。 チェックリスト あなたは友達ですか。
ヨセフがあなたにいくつかの方向性を与えられていることを理解していますが、別の角度からそれを扱うことをもたらしましょう。それはそれの別の見通しを得るのに役立つかもしれません。
JNヒューリスティックスと比較して、より広範なレベルのヒューリスティック評価の背景を説明します。あなたが青空の思考から始めて、これらのヒューリスティックスを今のところ残していないので、私はこれが気分を良くします。
いくつかの基本ルールに基づいてサイトを評価する場合、ヒューリスティックスを測定基準のセットとして見て、どのようにそれを実行しますか？使いやすさの基準、情報デザインの規範、インタラクションデザインの規範、コンテンツデザイン、ビジュアルデザインなど、より広い領域をターゲットにします。これらのトピックの下にいくつかの5つのポインターを準備し、それをJNヒューリスティックスへのマッピングを開始してください。
したがって、ここでの主題は、システムステータスの可視性、一貫性と標準、エラーの防止、認識ではなく、エラー、ヘルプ、ドキュメントからの回復、診断、および文書化です（これらはすべて、使いやすさの標準です）。システムと実世界、ユーザーコントロールと自由度、ヘルプとドキュメント、柔軟性（情報デザイン）、ユーザーコントロールと自由度、エラーの診断と回復、システムステータス（相互作用デザイン）のマッチング。このような ...
広い目標から取り組むのではなく、機械的に行うだけなので、これらの10個のポインタを1つずつマッピングするのではなく、別の視点から見てください。
ヒューリスティックな基準を評価するとき、私は常に決まった答えで批判します。
規格は使用されていますか？
それはどれだけうまく適用されていますか？
通常、標準を使用することを意図している可能性があるが、実際には他の何かによって影響を受けることを示すことができます（言葉遣いが少なく、アプリケーションに一貫性がない）
最も簡単な方法は、ある範囲のスプレッドシートを使用して未加工の回答をキャプチャし、それをある種のレポート/正式な成果物でサポートテキスト付きの要約グラフに生成することです。